Portable Vs Retargetable Assemblies

As we have been discussing that Portable Class Libraries allow us to target the same assembly for multiple platforms. Hence the name "portable" as they can be ported to the platforms and frameworks specified at design time. And as we have discussed before, that this sharing can be called Assembly Portability. Although you can create a portable library which is also retargetable but being portable is not the same as being retargetable. We can just use this manifest from one of our previous discussions about portable libraries. You can see that it is referencing a few retargetable libraries.

Are you wondering what actually is being retargetable? Basically portable Class Libraries is a recent introduction to developer's toolkit but retargetability has been there for a long time. As we have discussed in one of our previous posts that the assemblies in profile folder are just there for reference. They are to make sure that only certain features and types are used from them based on the automatic profile selection by the Visual Studio IDE. [The selected profile is part of the definition of portable class library project. You can easily find this in the project definition].

The actual runtime assemblies [e.g. System.dll] wouldn't be used from the profile. They would be used directly from the host framework. So if your portable library has Silverlight 4 as one of the target framework then it would be using the System assembly as provided by Silverlight 4 runtime. Portable Library Developers at Microsoft has made sure that there are no runtime surprises when your portable assembly is loaded by the host framework by only supporting the features provided by all of the selected target frameworks. That is exactly what Retargetability is. For an assembly, being retargetable means that the actual assembly will be used as provided at runtime. Let's see the manifest of a retargetable assembly [System.dll] from Profile1 using ILDASM.

Now you might be wondering if we can create a retargetable library. Actually you can do it. You can provide flags when you are developing your assembly. These flags are used from AssemblyNameFlags enumeration available in System.Reflection.

http://msdn.microsoft.com/en-us/library/system.reflection.assemblynameflags.aspx

The combination of these flags can be accessed through Flags property of your required assembly.

http://msdn.microsoft.com/en-us/library/system.reflection.assemblyname.flags.aspx

Just because you can do this, it doesn't necessarily mean you should. There doesn't seem to be any reason why we would be needing a custom retargetable library. This is from the documentation of the member of the enumeration from MSDN.

"Specifies that the assembly can be retargeted at runtime to an assembly from a different publisher. This value supports the .NET Framework infrastructure and is not intended to be used directly from your code."
This member is also available for your Portable Class Library project. Remember the special icon that shows the Portable Library support in msdn?

To see how this works, let's create a simple portable class library project, named MyPortableLibrary.

Let's build the project and see the manifest in ILDASM tool. This is definitely not a retargetable library.

Now let's add the flag in the assembly info file for the project as follows:

Now let's build the project again and see the updated manifest. You can notice that the assembly is now marked as retargetable.