Как вы управляете сгенерированным кодом в Visual Studio - в частности, создание DLL из .idls

Question

Я пытаюсь добавить сгенерированный проект сборки COM-взаимодействия к своему решению, и единственное решение, которое я могу придумать, кажется действительно неприятным.

Я создал проект .net dll, удалил из него все файлы .cs и затем создал следующее событие после сборки:

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

По сути, я сначала создаю пустую DLL, а затем перезаписываю ее реальной DLL взаимодействия. И здесь нет управления зависимостями - оно создается каждый раз.

Есть ли лучший способ сделать это?

Answer 1

Компиляцию MIDL можно выполнить, сделав проект COM-взаимодействия управляемым проектом C ++ (вместо проекта C #), а затем добавив idl и h в проект как обычные исходные файлы.

Answer 2

Вы можете преодолеть проблему зависимости, используя задачи MSBuild напрямую, а не пакетный файл PostBuild, который хорошо согласуется с системой зависимостей MSBuild.

Однако, почему вы генерируете файл вручную из idl? Когда мне нужно COM-взаимодействие, я просто импортирую его и помещаю сгенерированную сборку (* .Interop.dll) в систему управления версиями. Таким образом, у вас всегда есть нужная версия, и она уже готова к использованию, и Visual Studio может найти библиотеку взаимодействия до первой сборки, то есть Intellisense с самого начала.

Теперь некоторые люди не хотели бы регистрировать двоичный файл, с которым я обычно согласен, но хорошо, если он работает ...:)

Конечно, мой метод не будет работать, если построение COM-сервера является частью построения решения. В этом случае просто попытайтесь поместить генерацию в сценарий MSBuild, чтобы избавиться от зависимости, если Visual Studio не принимает ссылку на внутренний проект, отличный от .NET-COM.