Classic ASP and multiple versions of comvisible .net classes

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Wayne Sepega - 10 Apr 2006 13:58 GMT

I have a class assembly that I have made visible via com. I've strong named
it, put it in the GAC, and registered it with RegAsm, and have successfully
called it from ASP and a VBScript file. I then incremented the version # of
the assembly and made a slight code change. The ASP and VBScript call the
new version of the object. I need to figure out how to force the VBScript
and ASP to call the old version, or rather a specific version of the
assembly. I've seen in the help and google results that you can define a
policy in a manifest or in your config file for the calling application, but
I don't have a calling application. I also may need each ASP file to be able
to call a specific version, not necessarily the same version for every ASP
file.

Any ideas?

Thanks
Wayne

Reply to this Message

Dmytro Lapshyn [MVP] - 10 Apr 2006 15:36 GMT

Hi Wayne,

There's a COM trick known as version-dependent ProgIDs. The idea is that
every version of the COM object has its own ProgID with the version number
specified:

Example.ProgID.1.0

In hope that .NET supports this convention, try appending the version number
after putting an additional dot trailing the usual ProgID you use. This
might work. However, you should be very careful to ensure the old and new
versions of the COM-visible DLL don't intersect in terms of IIDs, ClassIDs,
Type Library IDs, etc. Otherwise, the DLL Hell is guaranteed.

>I have a class assembly that I have made visible via com. I've strong named
>it, put it in the GAC, and registered it with RegAsm, and have successfully
[quoted text clipped - 12 lines]
> Thanks
> Wayne

Reply to this Message

Wayne Sepega - 10 Apr 2006 19:50 GMT

Just want to make sure I understand you correctly, this is what I have for
my class declaration:

[Guid("A5A814B3-4A08-468d-A387-047059AB9D14")]
[ComVisible(true)]
[ProgId("ComTest.Numbers")]
public class Numbers : INumbers
{
}

So what you are suggesting is to add .1.0 to ComTest.Numbers, this way it
keeps the name unique.

Believe I fully understand that part. Now for the DLL Hell comment. In the
example above your suggesting that I need to change the GUID with each new
version of the Assembly? Also with this guid:
[assembly: Guid("9c832876-953f-4382-a441-a243d657a28b")]? and any other guid
I might have, say one for the INumbers interface?

Thanks
Wayne

> Hi Wayne,
>
[quoted text clipped - 26 lines]
>> Thanks
>> Wayne

Reply to this Message

Dmytro Lapshyn [MVP] - 11 Apr 2006 07:15 GMT

Hi Wayne,

> So what you are suggesting is to add .1.0 to ComTest.Numbers, this way it
> keeps the name unique.
>
> Believe I fully understand that part.

Hmmm. I'd expect the IDE or runtime to create version-dependent ProgIDs for
you. It's unlikely you have to add "1.0" manually.

> Now for the DLL Hell comment. In the example above your suggesting that I
> need to change the GUID with each new version of the Assembly? Also with
> this guid:
> [assembly: Guid("9c832876-953f-4382-a441-a243d657a28b")]? and any other
> guid I might have, say one for the INumbers interface?

Yes, you are absolutely right. It's actually good you define all GUIDs
explicitly - otherwise you might end up figuring out those the IDE generates
silently for you (e.g. Type Library ID).

> Just want to make sure I understand you correctly, this is what I have for
> my class declaration:
[quoted text clipped - 48 lines]
>>> Thanks
>>> Wayne

Reply to this Message

Dmytro Lapshyn [MVP] - 11 Apr 2006 07:42 GMT

You may find the following article of interest as well:

http://www.simple-talk.com/2005/03/09/com-server-registration/

Reply to this Message

Classic ASP and multiple versions of comvisible .net classes

Free Magazines