How do you manage generated code in Visual Studio - in particular, creating DLLs from .idls.

Question

I'm trying to add a generated COM interop assembly project to my solution, and the only solution I could come up with feels really nasty.

I created a .net dll project, removed all .cs files from it and then created the following post-build event:

call "$(DevEnvDir)..\tools\vsvars32.bat"
midl.exe $(ProjectDir)relative-path-to-my-idl\MyComName.idl /tlb MyComName.tlb
tlbimp.exe /keyfile:path-to-my-key\k.snk MyComName.tlb

Essentially, I first create an empty DLL, then overwrite it with a real interop DLL. And there's no dependency management here - it's created every time.

Is there a better way to do this?

Answer 1

You can overcome the dependency problem by using MSBuild tasks directly instead of a PostBuild batch file, which line up nicely with the MSBuild dependency system.

However, why are you generating the file manually from an idl? When I need COM interop, I just import it and put the generated assembly (*.Interop.dll) into version control. This way, you always have the version you need and it's already ready to use, and Visual Studio can find the interop DLL before the first build, i.e. Intellisense is there right from the beginning.

Now some people won't like to check in a binary file, which I typically agree with, but well, if it works... :)

Of course, my method won't work if building the COM server is part of building the solution. In this case, just try to put the generation into the MSBuild script to get rid of the dependency thing, unless Visual Studio accepts a reference to a solution-internal non-.NET-COM project.

Answer 2

The MIDL compilation can be handled by making the COM interop project a managed C++ project (instead of a C# project) then adding the idl and h to the project as regular source files.