views:

52

answers:

2

So when visual studio build the interop dll it gets 4.0.0.0.

The TypeLib version is 4.0

But the actuall DLL version is 4.0.1.112

Is there anyway I can get visual studio to automatically build the interop DLL to assume the actuall DLL version?

Could I alternatively get the interop DLL to use the version stamp from my app.

I just need to keep the interop DLL current with the app so the installer doesn't leave old interops behind.

I really don't want to do tlbimp manually, but I guess when I get to the point of automating the installer, I could automate that step.

+1  A: 

I don't believe this is possible. Visual Studio will prefer the TypeLib version when building the the interop DLL. I think you're only recourse is to use a hand crafted DLL with tlbimp and taking advantage of the /asmversion switch

JaredPar
+2  A: 

Well, it did consider the DLL version. A type library can only have a major and a minor version number. You'll need to bump your DLL version to, say, 4.1.x.x

This is otherwise appropriate behavior. One hard rule of COM is that you must change the GUIDs if you make a change to a publicly visible interface. Not doing so causes the worst kind of DLL Hell, the kind that crashes the client app without any good way to diagnose the reason.

That's no longer a revision change, that's a non-so-minor version change. The clients of the COM server have to be rebuilt. If you didn't actually change a public interface then having a type library version of 4.0 is still quite appropriate. It didn't change.

Hans Passant
Thanks. That's kind of what I was thinking.We are trying to keep the file versioning sync'd across assemblies so that you can know if something got mismatched. We are looking at this because we had exactly the type of crashing you described.
Joel Barsotti