5

I need to deploy multiple versions of the same C# .NET project. The project output is a COM interop assembly to be used in a native application. The problem I'm having is that I have to deploy several versions of this assembly side-by-side but whatever I do doesn't seem to create different versions. Instead the versions override eachother.

I've tried changing the assembly GUID, tried changing the assembly version numbers, tried regenerating the assembly strong name key, tried changing the assembly title and description. I'd rather not have to change the GUID's or names for individual types in the assembly for versioning purposes.

How do I ensure these versions do not override eachother and that I can see and deploy them side-by-side?

Thanks in advance!

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices;

namespace InteropTest
{
    [Guid("...")]
    [ClassInterface(ClassInterfaceType.AutoDual)]
    public class Test
    {
        public Test()
        {
        }

        public string Version
        {
            get
            {
                return "1.0";
            }
        }
    }
}
Bent Rasmussen
  • 5,538
  • 9
  • 44
  • 63

2 Answers2

6

I'd rather not have to change the GUID's or names for individual types in the assembly for versioning purposes.

But that exactly what you have to do to prevent COM types from interfering with each other. The [Guid] is used to select the registry key in HKLM\Software\Classes\CLSID where the COM class is registered. Two distinct versions with the same Guid will overwrite each others keys. Otherwise known as DLL Hell. Changing the public interface requires a new Guid to ensure that clients that use the old one don't die with impossible to diagnose misbehavior. A rock-hard COM requirement.

Omitting the [Guid] attribute is very possible, you now leave it up to the CLR to generate one for you. Now the assembly attributes start to play a role, the guid value is auto-generated by a slick algorithm that includes the assembly name and the version as well as the set of methods on the interface and their arguments. Thus ensuring that any changes automagically produce a different guid. And, as expected and required, a different [AssemblyVersion] will generate a different [Guid].

Another approach, which is what I assumed you meant with 'side-by-side', is to not register the assembly but rely on a manifest instead. It must be embedded in the client program, you use the <clrClass> element to declare your [ComVisible] class. Versioning now becomes a deployment detail. The MSDN how-to is here. Keep in mind that it has to be embedded in the client program, not your [ComVisible] assembly. That tends to be a problem.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
2

Try late binding to the interop assembly in your native application if you can. I'd also advise against auto generating the interface using AutoDual and instead explicitly generating your own read this for more info. You can troubleshoot the problem by opening regedit and searching for the Guid and the ProgId to see which versions of the assembly have been registered.

burnside
  • 2,551
  • 23
  • 20