Как C # может использовать устаревшую DLL просто без регистрации (regsvr32) - PullRequest
Новая
       32

Как C # может использовать устаревшую DLL просто без регистрации (regsvr32)

6 голосов
/ 13 января 2012

Положение
Я запускаю систему сборки, которая выполняет много сборок для многих проектов. Чтобы одна сборка не влияла на другую, мы привязываем пользователя сборки только к его рабочему пространству. Сборки запускаются как непривилегированные пользователи, которые имеют только возможность записи в рабочую область.

Вызов
Во время нашей новой сборки нам нужно использовать устаревшую 3-х стороннюю DLL, которая предоставляет свой интерфейс через COM. Команда разработчиков хочет зарегистрировать сборку (regsrv32.exe), но наш режим безопасности сборки блокирует это действие. Если мы ослабим этот режим, то 3-я библиотека DLL будет влиять на другие сборки, и если у меня будет две сборки, для которых нужны две разные версии, у меня может быть неправильная сборка сборки против неправильной версии (вполне реальная возможность).

Вопрос
Есть ли другие варианты, кроме регистрации, для обработки устаревших библиотек DLL, которые предоставляют свой интерфейс через COM?

Спасибо за помощь

Peter

Ответы [ 5 ]

9 голосов
/ 18 января 2012

Мой оригинальный ответ на аналогичный вопрос см .: Сервер сборки TFS и ссылки на COM - это работает?

Хороший способ компилировать код .NET, который ссылается на компоненты COM безCOM-компоненты, регистрируемые на сервере сборки, должны использовать элемент справки COMFileReference в ваших файлах проекта / сборки вместо COMReference.Элемент COMFileReference выглядит следующим образом: 

<ItemGroup>
  <COMFileReference Include="MyComLibrary.dll">
    <EmbedInteropTypes>True</EmbedInteropTypes>
  </COMFileReference>
</ItemGroup>

Поскольку Visual Studio не поддерживает конструктор для COMFileReference, необходимо отредактировать файл проекта / сборки вручную.

Во время сборки MSBuild извлекает информацию библиотеки типов из библиотеки DLL COM и создает сборку взаимодействия, которая может быть автономной или встроенной в вызывающую сборку .NET.

Каждый элемент COMFileReferenceтакже может иметь атрибут WrapperTool, но по умолчанию мне показалось, что он работает нормально.Атрибут EmbedInteropTypes не задокументирован как применимый к COMFileReference, но, похоже, он работает как задумано.

См. https://docs.microsoft.com/en-ca/visualstudio/msbuild/common-msbuild-project-items#comfilereference для получения дополнительной информации.Этот элемент MSBuild доступен с .NET 3.5.

Жаль, что никто не знает ничего об этой технике, которая мне кажется проще, чем альтернативы.Это на самом деле не удивительно, так как я мог найти только одну ссылку на него онлайн.Я сам обнаружил эту технику, покопавшись в файле MSBuild Microsoft.Common.targets.

2 голосов
/ 13 января 2012

Пошаговое руководство по COM без регистрации здесь:

http://msdn.microsoft.com/en-us/library/ms973913.aspx

И мучительная деталь тут: http://msdn.microsoft.com/en-us/library/aa376414 (корень этого документа на самом деле здесь: http://msdn.microsoft.com/en-us/library/dd408052)

Кроме того, для сборки в целом, вы должны иметь возможность использовать Tlbimp или tlbexp для создания файла TLB, который вы можете использовать для сборки, предполагая, что точка регистрации состоит в том, чтобы просто иметь возможность успешно компилировать, а не запускать определенные тесты.

1 голос
/ 14 января 2012

Спасибо за помощь.

Мы перешли с раннего связывания на позднее связывание, потому что нам никогда не требовалась DLL во время компиляции. Это выдвинуло требование регистрации с сервера сборки на сервер тестирования интеграции (где мы выполняем установщик, который обрабатывает регистрацию). Мы стараемся сохранить систему сборки в чистоте и иметь легко сбрасываемые системы интеграции.

Еще раз спасибо Питер

1 голос
/ 13 января 2012

Инструменты установки, такие как Installshield, могут извлекать интерфейсы COM из библиотек DLL и добавлять их в реестр. Он также может использовать процесс саморегистрации DLL (что, как мне кажется, и делает regsvr), но это не лучший метод установки Microsoft .

1 голос
/ 13 января 2012

в .NET COM обычно выполняется через Interop для регистрации .DLL в .NET, они называются сборками, и это можно сделать несколькими способами: путем добавления ссылок через VS IDE на уровне проекта или написания кода, который загружает и выгружает сборку .. с помощью файла .Config, в котором есть ссылка на сборку, а также использование этой ссылки в проекте ... GAC.

  • Если у вас есть доступ к сторонним .DLL, вы можете GAC их и ссылаться на них в своем проекте
  • Вы можете добавить использование в заголовок файла .cs, а также добавить ссылку на проект, щелкнув правой кнопкой мыши ссылку -> Добавить ссылку ...
  • Вы также можете выполнить вышеуказанный шаг, а также установить копию local = true в свойствах для этого DLL. Я надеюсь, что это дает вам некоторые идеи. Имейте в виду, что .NET сборки являются Управляемым кодом, так что Есть несколько способов использования этих сторонних .DLL с использованием других методов в C #, таких как LoadFromAssembly и т. д.
...