.NET Client crasch when replacing COM registered .

Question

We have an old C/C++ .dll that is COM registered. Our customers have both native- and .NET clients that use this .dll.

We have built a new .NET .dll to replace the old one, i.e. their COM interface is identical. We would like to replace the old .dll without our customer need to recompile or do anyting to their clients.

For native clients it works fine to simply unregister the old .dll and register the new one (with regasm). It also works for some .NET clients. However, in those cases the both the client and the new .dll is compiled with the same .NET version it throws the exception below.

In other words, this works:

.dll is .NET 3.5 -> client is .NET 4.0
.dll is .NET 4.0 -> client is .NET 3.5
.dll is any .NET -> Client is native

This throws the exeption below:

.dll is .NET 4.0 -> client is .NET 4.0
.dll is .NET 3.5 -> client is .NET 3.5

[A]BARAPIXLib.barcom5 cannot be cast to [B]BARAPIXLib.barcom5.

Type A originates from 'BARAPIXLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' in the context 'LoadFrom' at location C:\arkiv\S_BTW\BTW\BARAPIXWebService\Barapix\bin\BARAPIXLib.dll'.

Type B originates from 'BartrackTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' in the context 'Default' at location 'C:\arkiv\Bartrack\BartrackTest\x86\Src\BartrackTest\bin\x86\Release\BartrackTest.exe'."}

Any ideas would be appreciated.

Answer 1

This might be because in the case where you are using the same version of .net framework, the instance returned to the client is not longer a COM wrapper but a pure .Net object, so when you try to cast it to a COM interface it fails. There is a similar question here. The solution involves using Primary Interop Assembly.

Answer 2

Try unregistering any previous version and check that the dll is in the same folder as the executable. Also try looking at where it is you are loading the dll from. I think that you are loading it manualy so look at the address you are referencing the wrong dll.