BamlLocalizer throws exception reading BAML streams in .NET Core

[ericcdub]

• .NET Core Version: 6.0
• Win 10 22H2

• Does the bug reproduce also in WPF for .NET Framework 4.8?: No

  Problem description: I migrated a .NET Framework 4.8 class library to .NET 6.0 using the .NET upgrade assistant. The library uses BamlLocalizer to extract BAML streams from .NET Framework Assemblies which use WPF. After the update, the library can't read BAML streams in .NET 6 assemblies any more as BamlLocalizer throws a FileNotFoundException.

  Actual behavior: a FileNotFoundException upon instantiation of BamlLocalizer:

  at System.Reflection.RuntimeAssembly.InternalLoad(ObjectHandleOnStack assemblyName, ObjectHandleOnStack requestingAssembly, StackCrawlMarkHandle stackMark, Boolean throwOnFileNotFound, ObjectHandleOnStack assemblyLoadContext, ObjectHandleOnStack retAssembly)
  at System.Reflection.RuntimeAssembly.InternalLoad(AssemblyName assemblyName, RuntimeAssembly requestingAssembly, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, AssemblyLoadContext assemblyLoadContext) in /_/src/coreclr/System.Private.CoreLib/src/System/Reflection/RuntimeAssembly.cs:line 347
  at System.Reflection.Assembly.Load(String assemblyString) in /_/src/coreclr/System.Private.CoreLib/src/System/Reflection/Assembly.CoreCLR.cs:line 21
  at System.Windows.Markup.BamlReader.ReadAssemblyInfoRecord()
  at System.Windows.Markup.BamlReader.ReadNextRecord()
  at System.Windows.Markup.BamlReader.Read()
  at MS.Internal.Globalization.BamlResourceDeserializer.LoadBamlImp(Stream bamlSteam)
  at System.Windows.Markup.Localizer.BamlLocalizer..ctor(Stream source, BamlLocalizabilityResolver resolver, TextReader comments)

  Expected behavior: BamlLocalizer instantiates correctly and I am able to extract a BamlLocalizationDictionary from the BamlLocalizer instance.

  Minimal repro: Create a .NET 6 project which loads an assembly containing BAML steams, and supply one of those streams when instantiating BamlLocalizer. An exception will be thrown.

I have read elsewhere that the LocBaml utility doesn't work either when upgraded to .NET 6 https://tomaskohl.com/code/2020-06-24/localizing-wpf-app-on-net-core/ and there is an open issue here to port it to .NET core here https://github.com/microsoft/WPF-Samples/issues/85 but it would be good to hear this from the horse's mouth as it were.

[lindexi]

Reference: https://github.com/dotnet/wpf/issues/1480 https://github.com/dotnet/wpf/issues/6477

[ericcdub]

In the end, I managed to extract BAML from an assembly by calling AssemblyLoadContext.EnterContextualReflection(myAssembly);

This will cause the runtime to use the assembly's own load context as the reflection-only context, meaning BamlLocalizer will try to load the assembly into that same context. I'm not sure if this would have unintended side effects, but so far so good.

It would also tally with what I read here.

[Kuldeep-MS]

@ericcdub - Can you please attach the repro for the issue?

[ericcdub]

@ericcdub - Can you please attach the repro for the issue?

Hi @Kuldeep-MS

The issue reproduces when using the LocBaml tool as described in this help page https://learn.microsoft.com/en-us/dotnet/desktop/wpf/advanced/how-to-localize-an-application.

LocBaml uses BinaryLocalizer in ResourceGenerator.GenerateBamlStream, but is not AssemblyLoadContext-aware so it throws the same exception

The LocBaml project is still targeting .NET Framework, so either create a new .NET project and copy the source in or else use the .NET Upgrade assistant to migrate it.

Let me know if you need any more info.

Thanks

[harshit7962]

This issue is actually blocked on unavailability of several methods from ModuleBuilder and AssemblyBuilder which prevents us to create methods that can actually emit the correct target assemblies.

[h3xds1nz]

@harshit7962 As I've done it here, you do not need to generate dynamic assembly / module at all, just build it directly via metadata builder, after all it's just a resource assembly.

The original code used dynamic assemblies (RunAndSave) just because in 2005 there simply were no other options, however MetadataBuilder and whole System.Reflection.Metadata with the methods required to make this work was available earlier than WPF was even ported open source so this could have been done years ago.

So imho issue-type-tracking-external is not the correct label here. Since the issue is in Xaml/Baml readers/parsers not being assembly-context aware and requiring everything to be done in the Default context to work properly.