Hi,
I'm having a bad experience with C# and interop and I hope some one can
share a little light on my dilemma.
We have a third party VB6 com object that our C# 2005 app is utilising. We
are early binding so the application is using interop. Every thing is working
fine until the third party updates the com object to a new version and then
our app crashes. The com objects GUID is the same as binary compatible in VB
option was selected and no methods signatures were changed. If I open the C#
solution and simply recompile and then update the client’s
interop.vb6comaddon.dll with the new one then the app will work.
I thought that registering a new version of the VB6 com object should not
cause our c# app to stop working.
What’s crazy is that I a created a small test VB.NET application using
interop to access the same vb6 com object and this app was fine with the VB6
com update. So then I created the same small test app but with C# and it
still crashes when the VB6 com is updated. Why would VB.NET and C# behave
differently?
Is this expected behaviour?
What do I need to do to make my C# app work when the com is updated?
Anyone with an idea?
Kind regards
Paul Lance
Christian Fröschlin - 15 Feb 2007 09:22 GMT
> our app crashes. The com objects GUID is the same as binary compatible in VB
> option was selected and no methods signatures were changed.
You should be aware that VB6 may not warn you about API changes
which allow to keep backwards binary compatibility (such as adding
a new public member). But then it will silently increase the minor
type library version, which may cause a problem in some scenarios.
Though I wouldn't expect different behavior from VB.NET and C#.
You could also try to "diff" the IL export (ildasm) of the
old and new interop assemblies to check what changed.