Multiple versions of DLLs loaded into memory

[Srikanth Tammana]

Hi,
We have an application which runs as Excel add-in and recently we have
released newer version with higher assembly version.
So, they work fine if either of them are registered at a given point of
time. But I want to have both of them registered so user can launch either
of them for need. When I have both versions registered, I am getting Type
conflicts as both version of DLLs loaded into default domain when we start
excel process (As my application is an excel-addin with two different prog
ids for each version they are getting loaded into memory)
Is there any solution to solve this problem? I tried to create config file
with binding redirect and it still does not work.

<dependentAssembly>
<assemblyIdentity name="My Assembly" publicKeyToken="eb52b3e8c479af58"
culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-9.9.9.9" newVersion="3.5.2.0"/>
</dependentAssembly>

I think it worked once when I created the config file for Excel.Exe with
above information. But it will give problem when I run older version of
application as the config file always routes to newer version. So only way
is to update the config file appropriately which I am not interested in.
Can anyone suggest me a solutin for this problem?
Thanks in advance.

 

[Peter Duniho]

Hi,
We have an application which runs as Excel add-in and recently we have
released newer version with higher assembly version.
So, they work fine if either of them are registered at a given point of
time. But I want to have both of them registered so user can launch
either of them for need.

For what need? Of course, there will always be exceptions. But as a
general rule, there should be no good reason to need to keep the older
version around.

If there _is_ a good reason to keep the older version around, then
there's also likely a good argument for creating versioned types. That
is, instead of keeping the older version of the library around, include
all of the exact code from the older version as their original types in
the new version, and make all the new code in the new version exist in
new types (e.g. "MyType" in the first version, "MyType2" in the second,
etc.)

The latter approach is quite "hacky" IMHO, not elegant at all. But by
making the versioning issue explicit in your own DLLs interface, it
would avoid the problem in using the DLL as an add-in. Of course, a
variation on this approach would be to still allow both versions of the
DLL, and have only the new types in the new version of the DLL, but
still with no conflicting types with the old version.

I don't know what the architecture is for managed add-ins in Excel, but
I suppose yet another variation on the above theme would be to have just
an initializer type in your new DLL version (e.g. a factory), and then
have that DLL create a new AppDomain for actually using the main types
within.

Still not completely seamless, but then I'm not sure there will be a
completely seamless solution. At some point, if there is the
possibility of both DLLs being loaded into Excel at the same time, you
need _some_ way to distinguish between the two for whatever code in
Excel is using them.

Pete