When referencing assemblies in MCML we can provide a weak or strong reference.
Weak:
xmlns:cor=”MSCorLib/System”
Strong:
xmlns:x=”res://Assembly,Version=1.0. 0.0,Culture=neutral,PublicKeyToken=af4c3f16c336eb1d!SampleView.mcml”
When referring to code or markup that is located in an external assembly we need to provide a strong reference. Have you ever wondered why you need to? Wouldn’t it be nice if you could always use a weak reference – even if you are referring to resources located in external assemblies? Some developers like to have a separate assembly with their views, view related code and graphics. However, if you do so, you will always have to provide your external assemblies full name (incl. version, culture, public key) and take care of your external assembly’s full name (increment version, delayed signing, etc).
You may write some markup like this:

This piece of MCML code won’t actually work as expected since the presentation layer will not load the specified MCML resource from our external assembly because we did not provide a strong reference. I am not sure why Microsoft designed it like this, but I guess because we should specifically “select” the necessary assembly since the GAC could contain several versions of an assembly – the presentation layer doesn’t support mind reading yet so we need to make clear which assembly we want to be loaded.

This is how the SDK explains when to use which syntax:
MCML supports both types of syntax to refer to resources and assemblies.A weak assembly reference can be replaced with a strong assembly reference, and the application will continue to work as expected. However, the reverse is not always true. Use strong and weak assembly references as follows:
-
When referring to resources within an assembly that is currently loaded, including your application assembly, you can use a weak or strong assembly reference.
-
When referring to resources that are within the same assembly as the code or markup, it is recommended you use weak assembly references for readability purposes.
-
When referring to resources in an assembly that is outside of the assembly that is currently loaded, use a strong reference.
-
When referring to code or markup that is located in an external assembly, use strong assembly names and ensure that those external assemblies are installed into the GAC.
The SDK states that you can use weak references for any assembly loaded. So this means, I can refer to any assembly loaded into my applications domain using a weak reference! The .NET Framework provides a class named “AppDomain” which allows us to interact with the application domain(s) – we will use it to manually load our assemblies and make them available to our MCML code.

If you give this technic a try, you will see weak referenced external assemblies will in fact be available to your MCML code! Manually loading required assemblies works but brings some new problems on the table. We will have to take care that we load the desired assemblies before loading our MCML code. Also would we have to take care, that we don’t forget to extend this section when referencing new/additional assemblies.
So how could we help the presentation layer to automatically locate and load necessary assemblies?
When developing WMCPL applications, we’re in the wonderful world of .NET! If we refer to an assembly using a weak reference in our MCML code, the presentation layer will “ask” the under laying .NET environment to load the required assembly. The .NET environment will then try to find it in several locations:
- Application location: Since the extensibility platform host (ehexthost.exe) is loading and hosting our application, the physical location that will be checked is %windir%\ehome
- Global Assembly Cache: When the .NET environment couldn’t find the assembly in the application location, it will look into the GAC
Usually assemblies are installed to the GAC. However, because we’re using a weak reference, no assembly will be loaded since we’re not referring to a specific assembly – even if there is an assembly in the GAC matching the provided assembly name.
If the environment fails to locate the requested assembly, we get the chance to locate and load it on our own. To do so, we need to handle the AppDomains AssemblyResolve event.

The AssemblyResolve event will be fired, if the referenced assembly could not be located. This can happen if the requested assembly is not available on the target machine or because of a weak reference in our MCML code that doesn’t contain the necessary information to identify the assembly exactly.
So, we just attach an event handler and when the event gets fired, we will try to determine which assembly the environment was trying to load and get the first assembly from the GAC by matching the assembly name and/or comparing the assembly version.
I’ve created a sample project including a handy little class that will help you to get started named “AssemblyResolver”.

Calling MakeCustomAssembliesWellknown once will make sure that the required assembly will be loaded from the GAC – even if you’re using weak references in your MCML code. Fyi, this initial version of AssemblyResolver will try to locate the required assembly in the GAC and load the first assembly that’s found – you may extend the class to get the latest version of the assembly.

I hope this helps to understand the Media Center platform a bit more – even if you don’t plan to use the AssemblyResolver. Feel free to leave your feedback on my blog or just contact me directly.
Download sample project