For the last couple of months, I’ve been working a lot on something quite different from my Windows Development expertise: writing .NET Core micro-services with React and Typescript front-end, running on Docker containers in Kubernetes, hosted on Microsoft Azure!
The thing is that the more I worked with React and Typescript, the more I was enjoying it — to the point that made me think on how I could use my new skills on this blog!
I recently moved to a new machine and while attempting to debug a UWP app in the Windows 10 Mobile emulator, I came across the following error message:
I couldn’t find any information on this 0x800705AA error, but I eventually tracked this to be caused by the fact Hyper-V was using the machine GPU with RemoteFX!
The easiest way to fix this I found was to just disable RemoteFX; to do so, follow these steps:
open Hyper-V Manager (just press Win+R, type virtmgmt.msc and hit Enter)
on the left pane, right-click the machine name and then click “Hyper-V Settings”
on the tree, select “Physical GPUs”
untick “Use this GPU with RemoteFX” and click OK
After disabling RemoveFX, remove any Windows 10 Mobile emulator from the “Virtual Machines” list (Visual Studio will re-create these) and just deploy from Visual Studio again and you should now be able to launch the emulator!
Coming from all the development related pains in Silverlight and Windows Phone platforms, I knew how strong-named assemblies were a real problem, hence why I wrote that post and said that developers should stop strong-naming their assemblies.
With time, that post somehow became the “canonical answer” for questions in the line of “should I strong-name my assemblies?“.
This would make a good blog post title. There is a lot of confusion in the community on why or why not assemblies should have strong names in 2018! This is still very often cited as the canonical answer all over the place: https://t.co/RblHqL4h48
Coming to more recent times, I had the chance to revisit this topic while discussing what to do over a strong-naming related issue on the Windows Community Toolkit.
After the discussion and a few quick checks to confirm the information passed, the consensus was to go ahead and strong-name the toolkit assemblies.
Since that moment, I must admit that I changed my mind and I’m now advocating that you should strong-name your assemblies!
Silverlight and Windows Phone are dead
For much that hurts me to say this(!), Silverlight and Windows Phone are dead platforms and thus, the reasoning to not strong-name an assembly as they could become unusable in these platforms, is no longer valid.
Modern frameworks can ignore strong-name information
While Windows 10 UWP and Xamarin completely ignore any strong-name information in the referenced assemblies, .NET Core has mechanisms to automatically redirect all references.
In fact, .NET Core enforces all their assemblies to be strong-named (they even have a document describing this requirement).
NuGet does help by automatically creating binding redirections when you add packages to your project!
The GAC is still very well alive
Yes, against what I thought to be true, Windows 10 still has a GAC that supports side-by-side assemblies for the full .NET Framework!
The GAC requires strong-named assemblies, so there is still a real use case for those in modern days.
I’m taking a leap of faith that all currently supported frameworks and all future ones will provide mechanisms to ignore strong-name info in assemblies, or just allow to use redirections.
If that proves true, then yes: you should strong-name your assemblies as that will allow more people to use them.
To those still skeptical of strong-naming their assemblies, I propose a compromise solution: do strong-name your assemblies, but only increment the assembly version for major releases! Json.NET has been using this approach to avoid binding redirects since 2014, and as far as I can tell, with relative success!
As a final note to open-source library developers, I strongly recommend that the strong-name key file gets check-in to the project repository so that anyone can easily clone the project and compile a version of the library that works with anyone else’s binaries!
On my earlier post I wrote about “Building a dispatcher agnostic view-model”; that was just laying the ground for this follow up post, where I am going to show how we can extend that knowledge to use view-models shared between separate windows on different UI threads!
Nice, but wouldn't it be easier just to override the add & remove of the PropertyChanged event and capture the Dispatcher there? That way all you need is a base viewmodel, no other changes on the view or properties of the viewmodel!