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!
The BaseViewModel is just a basic implementation of the INotifyPropertyChanged interface with a helper method that will raise the PropertyChanged event - all quite standard for any MVVM based application!
Now let us say that in the view we have a TextBox control, and that the Text property is binded to the MainViewModel.Result property.
Given this, you will probably notice a problem with the MainViewModel.RetrieveData method: after awaiting the call to GetDataFromSomeWebsite method, most likely we will not be on the UI thread due to the .ConfigureAwait(false) (if you dont know what ConfigureAwait is, please read this post). So, when we set the Result property on the next line which in turn will notify the UI that the property value has changed, that will cause an exception!
To fix it, we can use CoreApplication.MainView.Dispatcher to retrieve a CoreDispatcher instance that will then allow us to execute code in the UI thread.
With some minor changes, the MainViewModel.RetrieveData method now looks something like this:
For small view-models this approach is perfectly fine, but for bigger ones where multiple developers are working on, you might end up losing track of which properties you need to update in the UI thread and the ones you do not.
Wouldn’t it be great if you just didn’t have to worry about this?
To make our view-models completely oblivious of what is the current thread, we will need to make some changes to their base view-model!
The easiest way will be to capture the CoreDispatcher at start, and on the OnPropertyChanged method (or whatever you called your PropertyChanged event raising helper method), check if we need to dispatch the call or just raise the property regularly.
I have taken a break from UWP development, and for the last couple of weeks I have been working mostly on WPF projects.
You know, that “old” XAML technology that started back when Windows XP was still a thing!
The interesting bit is that all my previous experience developing for Windows Phone did give me a lot of knowledge on how to write performant non-blocking code - and I am still learning something new every day!
These are some of my personal coding tips to help keep your app as responsive as possible!
var total =await Task.Run(()=>MyLongRunningOperation());
ResulTextBlock.Text = total.ToString();
On the above code sample, we wrapped the call to MyLongRunningOperation method with a Task.Run that will force it to execute on a new separate thread, and then awaited for it to complete.
Note: Libraries should not lie about what they are doing! The UI thread is the only one that needs the asynchronous API, so it should be up to the end developer to decide when to use this, not 3rd party libraries ones!
Avoid using task.Result or task.Wait()
If use task.Result or call task.Wait() you will be blocking the current thread until that task completes, which is not ideal especially if the thread is the main UI thread!
A particular situation I see people doing this is for constructors; here’s an example:
_initialValue =GetInitialValueTask().Wait();// don't do this!
return _initialValue *2;
// other code...
The whole point of the .NET asynchronous model is to use the async and await keywords!
To avoid this issue, one could write the code like this:
_initialValueTask =GetInitialValueTask();// store the async task
// other code...
Instead of blocking the thread like we did before, we just store the asynchronous task and when we need it, we ensure we access it from an async method so we can await on it!
Use task.ConfigureAwait(false) whenever possible
Developers should assume that the await keyword will make any call return to calling thread.