Using Retargetable assemblies for portability

While doing research with Assemblies and files that build the architecture of .NET, there are a lot of hidden secrets that you can apply on which might not be known to you. Retargetable assemblies are not new to the system. It is present from way back to the inception of .NET, but never been seriously used until we practically found a way to deal with it in multiple platforms with Portable libraries introduced lately.

In the beginning of .NET, people accepted it because of its portability in multiple environments. .NET assemblies runs just by XCopy without registering and storing its metadata outside. It is also worth notifying that there is a special location where all the assemblies stored and can be called either by its name or by the target framework it is associated with. When you sign an assembly, the assembly will associate with a Public Token which uniquely identifies the version of the assembly. As time progresses, there are increased number of .NET framework released and everytime you want to use the newer utilities, you need to compile all the assemblies again and again even though you might not be using the new benefits it comes with. Or otherwise, you need your client to install multiple versions of .NET framework to exist.

.NET provides a solution to the problem by providing a small flag to the assemblies.

Let us create a class library and open AssemblyInfo. Let us add a new flag to the assembly and make it Retargetable.

[assembly:AssemblyFlags(AssemblyNameFlags.Retargetable)]

If you compile the assembly with this flag, the assembly will be Retargetable, which means it will automatically check the environment and associate the assemblies present on the GAC.

For instance, say your Assembly refers to mscorlib.dll and System.dll. Now you might have built the assembly with .NET 2.0 but the client where it is installed does not have .NET 2.0 but have .NET 4.0. Microsoft already have released a version of System.dll and mscorlib.dll for 4.0. If you specify the flag, the existing newer version of assemblies would automatically be referenced and thereby you wont be seeing the FileNotFound exception.

After you compile, if you check the metadata of the produced assembly, you will see :

mscorlib, Version=2.0.5.0, Culture=neutral,
PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes

The Retargetable=Yes extra key will ensure that based on the environment, it automatically can reference older/newer version of the assembly with which it is build. The CLR can only resolve the assembly on the Target framework ignoring the Version and PublicKeyToken of the assembly when Retargetable is turned on.

I hope you like my post. Write your comments.

Abhishek Sur

Abhishek Sur is a Microsoft MVP since year 2011. He is an architect in the .NET platform. He has profound theoretical insight and years of hands on experience in different .NET products and languages. He leads the Microsoft User Group in Kolkata named KolkataGeeks, and regularly organizes events and seminars in various places for spreading .NET awareness. He is associated with the Microsoft Insider list on WPF and C#, and is in constant touch with product group teams. He blogs at http://www.abhisheksur.com His Book : Visual Studio 2012 and .NET 4.5 Expert Development Cookbook. Follow Abhishek at Twitter : @abhi2434

One Comment to “Using Retargetable assemblies for portability”

Comments are closed.