For far to long, Strong-Named Assemblies have been a huge rock in the shoe of 3rd party library developers, but people: it’s 2016, so why are you still using it?

How it all started…

The year was 2002 (or so I believe!), Microsoft had just released the .NET Framework, and one of the main enterprise focused features was the ability to sign an assembly with a strong-name.

Back then, Strong-Named Assemblies had some great advantages, as indicated in this MSDN article:

You want to enable your assemblies to be referenced by strong-named assemblies, or you want to give friend access to your assemblies from other strong-named assemblies.

An app needs access to different versions of the same assembly. This means you need different versions of an assembly to load side by side in the same app domain without conflict. For example, if different extensions of an API exist in assemblies that have the same simple name, strong-naming provides a unique identity for each version of the assembly.

You do not want to negatively affect performance of apps using your assembly, so you want the assembly to be domain neutral. This requires strong-naming because a domain-neutral assembly must be installed in the global assembly cache.

When you want to centralize servicing for your app by applying publisher policy, which means the assembly must be installed in the global assembly cache.

So strong-named assemblies are uniquely identified, which is a good thing, until it starts to work against you…

Let’s look at a real example: a few years back, JSON.net was actually a strongly-signed assembly. Now let’s assume we have a project that depends on “LibraryA” and “LibraryB”, and each of these require a different version of JSON.net.

If you build the project as it currently is, there will be a conflict as you can only have a single version of JSON.net on the output folder, but the libraries require different versions…

To fix this issue, .NET provided a mechanism called Assembly Binding Redirection to ensure that only one specific assembly would be used, regardless of the required version.

In comes Silverlight and Windows Phone

Unfortunately, neither Silverlight nor Windows Phone support Assembly Binding Redirection… and that is where the true problems started.

If you are an open-source developer and you want the identity benefits of a strong-named assembly, consider checking in the private key associated with an assembly into your source control system.

Obviously, for this to work you would have to build your own versions of your project dependencies… and let’s be honest here: that will eventually be more of a problem that a solution.

A few years ago, I personally felt this pain while developing a Windows Phone app, and so I went to the Windows Phone Developers UserVoice website and requested the support for Assembly Binding Redirection on Windows Phone… almost a year after the request, I got an update indicating it was “on the backlog”, and seems it has stayed like that till now…

If it is such a bad thing, why are people still doing it?

Developers seem to have the wrong notion that they should strong-name their assemblies as a security feature, but this could not be further away from the truth!

Granted, that does provide a basic insurance that an assembly hasn’t been tampered/altered, but in any case one can always use binding redirection (when available) to bypass the whole thing, so that is just a lame excuse to not buy a proper Code Signing Certificate and apply Authenticode to the assembly (which will prevent tampering AND impersonation, the right way!).

What about the Universal Windows Platform?

Unfortunately, as far as I know there is no support for Assembly Binding Redirection in UWP…

Assuming we are on a background thread when the DoStuff() method is invoked, we will retrieve a CoreDispatcher instance from the CoreWindow.CoreDispatcher property, call and await for the execution of dispatcher.RunAsync() method, which in turn will invoke the UpdateUI() method on the main thread, and then code execution will continue in the background thread by invoking the DoOtherStuff() method.

As it is right now, we know that DoOtherStuff will only execute after the UpdateUI() method finishes, but now let’s assume that we replace the UpdateUI() synchronous method with an asynchronous version of it, called UpdateUIAsync():

In this new version of the code, you’ll notice that the DoOtherStuff() method will eventually run before the UpdateUIAsync() has finished, which might not be what you intended to in the first place when you await’ed for the dispatcher.RunAsync() method!

The fact that we’ve added the async/await keywords to the callback doesn’t ensure that the caller will await for it to execute!

There are a few ways suspend the background thread execution until the foreground thread signals for it to continue, and using a [TaskCompletionSource](https://msdn.microsoft.com/en-us/library/dd449174(v=vs.110).aspx) is one of the easiest:

In this version of the code, once the execution returns from await’ing the dispatcher.RunAsync() call, the background thread will carry on execution, but will then await for the taskCompletionSource.Task to finish, which will only happen after the taskCompletionSource.SetResult(true) call that we make in the main thread!

As you can see above, we create a new MainViewModel instance, set it as the page DataContext property, and then we have the three click event handlers, one for each of the buttons on the view.

We’ve also added a MainPage.ViewModel property to expose the current MainViewModel instance to the compiled bindings (we can’t use the DataContext property as its type is object and compiled bindings require strong-typed properties to work).

This is what you’ll get if you run the app and tap the buttons in succession:

As you can see, the 2nd TextBlock (the one using compiled bindings) never gets the text cleared when we tap the “Destroy CurrentTimeViewModel” button!

The expected behavior is the one shown in the 1st TextBlock: if the binding value is null or unavailable, the TextBlock.Text property will set to the Binding.FallbackValue (which is null by default).

So after checking the documentation for compiled bindings, one can say without that compiled bindings are ignoring the fallback value when its value is null, and that is quite a nasty bug in the compiled bindings!

This bug has already been reported to Microsoft but as we don’t know when it will get fixed, all we can do right now is be aware of the whole issue and make sure to test our apps thoroughly to ensure we don’t end up with these problems after migrating to compiled bindings!

I built a small test app and after a couple of minutes debugging it I noticed a MissingMetadataException getting raised; the culprit was found: .NET Native!

If you’re working with Universal Windows Apps (UWP) and don’t know what .NET Native is, I strongly advise you to start by reading the following excellent articles written by Morgan Brown, “a Software Development Engineer on the .NET Native team”:

Here’s the situation right now: when you build a UWP app, the compiler will do some “smart stuff” with your code (let’s skip the technicals here!), squeezing every little bit it can to make sure the compiled result will perform better and faster!

But there is a catch: if your code uses any type of dynamic coding features such as reflection or serialization, you might need to instruct the compiler that certain types in your application will be used as such, in order to avoid the exceptions like the MissingMetadataException you see above.

To avoid such problems, you can add specially built rd.xml files to your project - once again, check the articles above for more information on this subject!

The MultiBindingBehavior works by using the AssociateObject property value to reflect and dynamically create a binding expression, so what I needed was to ensure that it would be able to reflect any object passed to this property.

With this requirement in mind, I created a new Cimbalino.Toolkit.rd.xml file, set its Build Action to Embedded Resource, and set the content to the following:

Aaand… this didn’t work! I started getting a build error message stating that it couldn’t find any AssociatedObject property in the Cimbalino.Toolkit.Behaviors.MultiBindingBehavior.

Granted, the property does not exist directly in this class, but rather in the Behavior<T> base class, so I guess one say that .NET Native compilation completely forgot a completely basic feature of .NET and most object oriented languages: Class Inheritance!

Taking this into account, I made a couple of changes in the file and here’s what in the end made it work:

When working with Universal Windows Apps, make sure to build the app in Release mode and test it thoroughly!

Keep an eye out on the build warnings for any problems with your rd.xml files.

If you’re working with MVVM or have Model representation classes, it might make sense to put these in a separate assembly, or at least in a separate namespace from the rest of the code - this will allow you to easily target these files in a rd.xml for .NET Native optimization exclusion.

Do notice that while the Interaction class in the XAML Behaviors now performs the proper attach/detach pattern, the same can’t be said for the Behaviors SDK Extension for non-UWP apps, so I strongly advise you to keep using the MonitoredInteraction class for those projects!

One final note: if you actually want to use the XAML Behaviours, you will have to actually manually add the NuGet package to your project… this is due to the new Transitive Dependencies feature of NuGet 3.x, and as far as I know, there is no way of going around this extra step!

Since the very first versions of the .NET Framework, developers had the System.Globalization namespace “containing classes that define culture-related information, including language, country/region, calendars in use, format patterns for dates, currency, and numbers, and sort order for strings.”

One of the most useful classes in this namespace is the CultureInfo class!

To demonstrate the usage of this class, take a look at this really simple console app code:

As you can see from the above results, the CurrentCulture and CurrentUICulture property values are inferred respectively from Regional Settings and Display Language; the Location however, doesn’t seem to have any effect over these two properties.

This feature allowed any app to show data using the proper currency, date, and number formats, even if the app itself wasn’t localized for those cultures!

But then came WinRT with the Windows.Globalization namespace as a replacement, and that apparently affected the way the CultureInfo class behaved…

To show the differences, I’ve created a blank Windows 8 app, and set the following code in the MainView.xaml.cs file:

As you can see here, both the CurrentCulture and CurrentUICulture property values are now based on the selected Display Language!

In my personal opinion, this change of behavior is wrong for various reasons, but mostly because it breaks the expected known behavior of the CultureInfo class properties.

Right now you might be thinking that the impact of this change is really small, but it might actually be bigger than expect due to a specific feature: Cortana!

As of today, Cortana is still only available in a few locations, and as such, most users have “faked” their location in order to get Cortana active on their devices, but maintained the Regional Settings matching their real location!

Retrieving the “proper” CurrentCulture

One could use the Windows API GetUserDefaultLocaleName to retrieve the Regional Settings, but this only works on full Windows 10, so it’s not a “universal” way of doing it!

However, I’ve found that if you create a DateTimeFormatter instance with “US” as language, you can retrieve the culture name from the DateTimeFormatter.ResolvedLanguage property!

As you can see above, the button is binded to the Page2ViewModel.DelayedGoBackCommand. Also, we will be using an EventTriggerBehavior to monitor the Page2ViewModel.GoBack event, and when it gets raised, we will use the CallMethodAction to invoke the Page2.Frame.GoBack method.

Now here’s the catch: while behaviors have a way of being notified when they are to be detached, that never happens!! Not when you leave the page, not when the page gets unloaded, and not even when garbage collection runs.

As such, when we navigate back from page 2, Page2ViewModel.GoBack event will still hold a reference to the EventTriggerBehavior, leading to a memory leak!

But things get even worse in this example: everytime we navigate to page 2, we will subscribe over and over again the GoBack event, so multiple invocations will eventually occur - definitely not what we wanted!

Introducing the MonitoredInteraction class

The MonitoredInteraction was built as a direct replacement of the Microsoft.Xaml.Interactivity.Interaction, and will monitor the attached object Loaded and Unloaded events and call for the attachment and detachment of all behaviors it contains!