Using Retargetable assemblies for portability

By | September 10, 2013

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.


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=, 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.

One thought on “Using Retargetable assemblies for portability

  1. Pingback: How to add Caller Info Attributes to an Environments that doesn’t support it | Daily .NET Tips

Comments are closed.