WPF baml out of sync after flipping assembly signing on/off

[professor-k]

It happens when you have WPF project, build it, and then change SignAssembly to opposite. Resulting binaries will have embedded baml that references to previous state of assembly, so running it will result in crash.

Steps to reproduce

1. Extract WpfSign.zip. It's basic WPF hello world, with rudimentary exception display. Also it has it has strong name key file.
2. Run msbuild WpfSign.csproj
3. Run WpfSign.exe, it will show Hello World! window.
4. Edit WpfSign.csproj, change SignAssembly to true
5. Run msbuild WpfSign.csproj once again
6. Run WpfSign.exe

Expected behavior

Hello World! again.

Actual behavior

We've got exception:

System.Windows.Markup.XamlParseException
  HResult=0x80131501
  Message=Could not load file or assembly 'WpfSign, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
  Source=PresentationFramework
  StackTrace:
   at System.Windows.Markup.WpfXamlLoader.Load(XamlReader xamlReader, IXamlObjectWriterFactory writerFactory, Boolean skipJournaledProperties, Object rootObject, XamlObjectWriterSettings settings, Uri baseUri)
   at System.Windows.Markup.WpfXamlLoader.LoadBaml(XamlReader xamlReader, Boolean skipJournaledProperties, Object rootObject, XamlAccessLevel accessLevel, Uri baseUri)
   at System.Windows.Markup.XamlReader.LoadBaml(Stream stream, ParserContext parserContext, Object parent, Boolean closeStream)
   at System.Windows.Application.LoadBamlStreamWithSyncInfo(Stream stream, ParserContext pc)
   at System.Windows.Application.LoadComponent(Uri resourceLocator, Boolean bSkipJournaledProperties)
   at System.Windows.Application.DoStartup()
   at System.Windows.Application.<.ctor>b__1_0(Object unused)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
   at System.Windows.Threading.DispatcherOperation.InvokeImpl()
   at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at MS.Internal.CulturePreservingExecutionContext.Run(CulturePreservingExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Windows.Threading.DispatcherOperation.Invoke()
   at System.Windows.Threading.Dispatcher.ProcessQueue()
   at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
   at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
   at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
   at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
   at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
   at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
   at System.Windows.Application.RunDispatcher(Object ignore)
   at System.Windows.Application.RunInternal(Window window)
   at System.Windows.Application.Run(Window window)
   at System.Windows.Application.Run()
   at WpfSign.App.Main()

Inner Exception 1:
FileLoadException: Could not load file or assembly 'WpfSign, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Environment data

Microsoft (R) Build Engine version 15.7.180.61344 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

15.7.180.61344

OS info:
Microsoft Windows 10
Version 1803 (OS Build 17134.165)

[Hujerek]

Is this issue somehow/somewhere closed or do we have some solution for it?

[professor-k]

Just tested. It still reproduces as of .net 4.8.1 and msbuild 17.7.2. Yes, there is simple workaround: just wiping out bin/obj takes care of it. I discovered it hard way when our production builds (signed) run after develop builds (not signed) on the same build agent would crash. As same sources built on different agents, or even on same agent, but in different order would behave differently, it was extremely hard to figure out. And that's the reason why I bothered to log it. As for our case, I added piece of code that wipes bins/objs on every build, and that solved this issue (and probably some others similar too).

[Hujerek]

Thanks, but it doesn't solve our problem.
We are using PackageReference mode for Nugets and our Nuget for signing. When the assembly is signed by using that Nuget, the BAML references aren't signed correctly. WPF assemblies contain BAML files as embedded resources (binary XAMLs) whose references are not correctly generated. As the result, that assembly cannot be loaded and following exception is raised: System.Windows.Markup.XamlParseException: 'Could not load file or assembly...

We temporarily changed the signing process of the assembly to be directly signed by .snk (not using that Nuget) to ensure the assembly is correctly signed. That works.