eocrawford
commented
1 year ago Types with the Microsoft.VisualBasic.Activities namespace are currently added to UiPath.Workflow.dll (see files under src\UiPath.Workflow\Microsoft\VisualBasic\Activities.)
Reflection-loading of VisualBasic.Activities types from System.Activities.dll (src\UiPath.Workflow.Runtime\UiPath.Workflow.Runtime.csproj) could still succeed if UIPath.Workflow.dll (src\UiPath.Workflow\UiPath.Workflow.csproj) contained TypeForwardedTo attributes redirecting relevant types to System.Activities, e.g.:
[assembly: System.Runtime.CompilerServices.TypeForwardedTo(typeof(type))]
Creating these entries is not currently possible because src\UiPath.Workflow\UiPath.Workflow.csproj depends on UiPath.Workflow.Runtime.csproj.
@dmetzgar, what if we were to move the types from UIPath.Workflow.dll to System.Activities.dll and use type forwarding to ensure any apps deployed with previous versions of CoreWF would still work?
Elaborating on namespace – dll mapping issue: As you know , Workflow XAML created by WWF from net48 versions, maintains a list of namespaces and its corresponding assembly information. The same is accessed by WWF/CoreWF during XAML deserialization to find the implementation via reflection. But the lib has changed the assembly containing VisualBasic.Activities resulting into processing error."System.Xaml.XamlObjectWriterException : Cannot set unknown member {clr-namespace:Microsoft.VisualBasic.Activities; assembly=System.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35}”
We would need a type forwading configuration from system.activities to UiPath.Workflow dll