Hi,
When running ProStartPageConfig in the ArcGIS Pro Add-In Samples (https://github.com/Esri/arcgis-pro-sdk-community-samples/) in ArcGIS Pro 3.6 with the Add-In Manager option "Load add-ins side by side" checked it crashes with the following unhandled exception:
System.Windows.Markup.XamlParseException: ''Add value to collection of type 'Microsoft.Xaml.Behaviors.BehaviorCollection' threw an exception.' Line number '212' and line position '14'.'
Inner Exception
''Add value to collection of type 'Microsoft.Xaml.Behaviors.BehaviorCollection' threw an exception.' Line number '212' and line position '14'.'
Any idea how this can be fixed?
Thanks,
Markus
Solved! Go to Solution.
I see the problem. This add-in is including Microsoft.Xaml.Behaviors.dll in its installation folder. When the add-in loads, this causes the assembly to be loaded into the add-in's separate AssemblyLoadContext instead of using the host application's copy.
This creates a type identity mismatch: when the add-in's behaviors try to register with the host's behavior collections, .NET sees them as incompatible types even though they're identical. The host's collection expects behaviors from the assembly loaded in the default context, but the add-in is providing behaviors from a different assembly instance in its isolated context.
The solution is to remove Microsoft.Xaml.Behaviors.dll from the add-in's installation folder so it uses the host's shared copy instead. The add-in archive can be updated by adding a .zip extension and then opening it in Explorer. A bit of a pain if you rebuild it. I'll investigate what we can do going forward.
A quick workaround is to comment out the source of the problem: lines 211->213 in ProStartPageSample.xaml in the UI folder of the solution.
Still looking into a fix, but this will get you running (Pro doesn't crash anymore)
Thanks for a quick response and workaround. But I guess the workaround affects some functionality? But it worries me that the underlying problem might affect other functionality in add-ins, so looking forward to a fix and a better understanding of the issue.
I see the problem. This add-in is including Microsoft.Xaml.Behaviors.dll in its installation folder. When the add-in loads, this causes the assembly to be loaded into the add-in's separate AssemblyLoadContext instead of using the host application's copy.
This creates a type identity mismatch: when the add-in's behaviors try to register with the host's behavior collections, .NET sees them as incompatible types even though they're identical. The host's collection expects behaviors from the assembly loaded in the default context, but the add-in is providing behaviors from a different assembly instance in its isolated context.
The solution is to remove Microsoft.Xaml.Behaviors.dll from the add-in's installation folder so it uses the host's shared copy instead. The add-in archive can be updated by adding a .zip extension and then opening it in Explorer. A bit of a pain if you rebuild it. I'll investigate what we can do going forward.
Thanks @vanesch,
that solved the problem.
Instead of manually removing the Microsoft.Xaml.Behaviors.dll from the .esriAddinX, I added the following to the package reference in .csproj file, which prevents it from being included:
<PackageReference Include="Microsoft.Xaml.Behaviors.Wpf" Version="1.1.135">
<ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>
@mahj thank for catching that and implementing the suggested fix!
Note that we updated the sample to remove the Nuget package altogether and instead have a reference to the Microsoft.Xaml.Behaviors.Wpf DLL in the Pro/bin directory. That reference has "copy local" set to "No" as expected.