Incompatibility (namespace , dll pair) with existing xaml due to refactoring

[Akshay296]

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

[eocrawford]

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?