Incompatibility (namespace , dll pair) with existing xaml due to refactoring
Akshay296 opened this issue · comments
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
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?