Share via

Side-by-side Assemblies

  • Article

Recently I’ve been researching into Isolated Applications and Side-by-side Assemblies [1] for one of my customers. I thought I’d share a few evidently little-known rules and gotchas around this technology. I actually have a lot of these, and I’m still collecting them, so I’ll start with just a few here and I’ll post some more in the future. I also plan to write an MSDN article on the subject so I’ll post the link to that in due course.

First, Side-by-Side (SxS) with native COM components. So, on Windows XP, I seem to have to give my assemblies a multi-segment name (I’d be interested to know if anyone has experience to the contrary). The assembly name is what appears in the name attribute of your assembly manifest file’s assemblyIdentity definition element, e.g.:

<assemblyIdentity

          type = "win32"

          name = "myCOMServer"

          version = "1.0.0.0"

          processorArchitecture = "x86" />

So, although this will work fine on Windows Server 2003 with a dll called myCOMServer.dll, on Windows XP you have to change the assembly name to myCOMServer.XXX (or some such multi-segment name). There’s no need to make any change to the dll’s name. By the way, changing the assembly name means: changing the name of the assembly manifest file to myCOMServer.XXX.manifest; and changing the name attribute of the assemblyIdentity element in both the def (assembly manifest) and the ref (application manifest).

Another one is that, although the processorAchitecture attribute of the assemblyIdentity element is documented as not required [2] [3], if you use it in one of the def or the ref, you have to use it in the other.

Now for SxS with managed COM components. This first one is obvious if you come at it with a CLR mindset, but if you come at it fresh from SxS with native COM then it may be less obvious. With SxS native, the assembly name you put in your manifest files is independent from the name of your dll. With SxS managed, the assembly name you put in your manifest files must be the name of your .NET assembly and therefore the name of your dll (there are issues with multi-part assemblies which I’ll defer to a later post).

By no means obvious is the fact that for Windows XP it is mandatory to embed the assembly manifest into the assembly as a Win32 resource file (by the way this is currently optional for Windows Server 2003, but please don't rely on it always being so - SP2 may cause Win2K3 to behave like XP in this regard). To do this, first create a resource file to reference your assembly manifest. Here’s an example of myAssembly.rc which looks like:

#include <windows.h>

1 RT_MANIFEST myAssembly.manifest

This will compile into myAssembly.res when run through the resource compiler. So create a build script to build the resource and then embed it as a Win32 resource into your assembly. Something like:

rc myAssembly.rc

csc /t:library /out:myAssembly.dll /win32res:myAssembly.res AssemblyInfo.cs Class1.cs

[1] https://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/isolated_applications_and_side_by_side_assemblies_start_page.asp

[2] https://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/application_manifests.asp

[3] https://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/assembly_manifests.asp

Comments

  • Anonymous
    February 04, 2005
    Thanks for the post! I've struggled with this for soooo long, with no results. All I've tried to do is put together a simple COM app that would use specific versions of a .NET assembly, and simply can't make it work as advertised on MSDN.

    I'll be watching future posts as you deliver more nuggets. Making it work for real would be a big deal where I work.
  • Anonymous
    February 04, 2005
    (by the way this is optional for Windows Server 2003).

    This is a bug. We will like change it back to the XP behavior later.