Отслеживание зависимостей DLL для переноса нативной C ++ DLL в .NET - PullRequest
5 голосов
/ 19 апреля 2009

У меня есть C ++ DLL (без кода), которую я хочу предоставить приложениям .NET.

После обдумывания всех имеющихся у меня / известных мне опций (COM, P / Invoke, SWIG и т. Д.) Я пишу библиотеку классов .NET (на C ++ / CLI). Теперь результирующая DLL (библиотека классов) также требует исходной DLL и ее зависимостей. Моя проблема заключается в автоматическом отслеживании таких вещей, чтобы приложениям, использующим оболочку, не приходилось отслеживать другие (нативные) библиотеки DLL (особенно, если исходные библиотеки DLL развивают новую зависимость).

Чтобы быть более точным (и есть что-то конкретное для обсуждения), я пытаюсь обернуть cmr, поэтому я пишу MR, библиотеку классов (которая, естественно, зависит от cmr). cmr зависит от PNL, OpenCV и других. Когда я попытался добавить ссылку на MR в (C #) проекте, Visual Studio (2005 SP1) просто скопировал MR.DLL, оставив все зависимости позади, и затем пожаловался (выбросив FileNotFoundException о пропущенных модулях). Копирование cmr, PNL и т. Д. В каталог bin вручную решило проблему.

Без лишних слов, мой вопрос таков: есть ли способ для приложений .NET добавить ссылку только на одну DLL, и все просто работает ?

Я искал через Google и SO, но безрезультатно ...

EDIT : mergebin кажется наиболее близким к тому, что я ищу, но он может объединить .NET DLL только с одной встроенной DLL. Жаль, что нельзя объединять нативные библиотеки DLL.

Ответы [ 4 ]

6 голосов
/ 19 апреля 2009

Вы можете взглянуть на mergebin , инструмент, позволяющий объединять неуправляемые и управляемые библиотеки DLL в одну сборку. System.Data.SQLite использует этот подход.

3 голосов
/ 08 мая 2009

У меня сейчас очень похожая проблема.

Еще один большой шаг, который я выполнил, - скопировать Native .DLL в выходной каталог с помощью предварительно созданного шага в проекте C ++ / CLI и добавить параметр компоновщика

/ASSEMBLYLINKRESOURCE:"$(OutDir)\Native.dll"

Это записывает в результирующую сборку, что существует файл "Native.dll", который принадлежит сборке. Теперь все проекты, ссылающиеся на этот проект / сборку, также будут копировать Native.dll! (Это также должно войти в GAC, если вы поместите свою сборку туда - я этого не проверял).

Хорошо, вам все еще нужно добавить все зависящие от native.dll файлы. Я также не знаю, найдена ли собственная DLL во время выполнения, если вы загружаете сборку с помощью Assembly.LoadFrom () по совершенно другому пути (это то, что я должен решить для своей проблемы, потому что наша сборка оболочки C ++ / CLI требуется разработчику Visual Studio).

Надеюсь, это немного поможет вам в вашей проблеме.

EDIT:

Дальнейшие исследования показали, что Wrapper .DLL всегда находит нативный .DLL ... это хорошо. Плохо то, что Visual Studio Designer копирует необходимые сборки во временный каталог (где-то внутри пользовательского каталога) при открытии формы. Когда он копирует сборки, он игнорирует связанные ресурсы и, таким образом, собственный .DLL!

0 голосов
/ 19 апреля 2009

Ну, вы можете просто добавить команды для автоматического копирования необходимых DLL в правильный выходной каталог, как часть процесса Build. Это делается в Visual Studio путем перехода к свойствам проекта.

Проект -> Свойства MyProjectName ... -> События сборки

Добавьте команды для копирования нужных файлов в $ (TargetPath), и все готово.

Другой вариант - просто установить текущий рабочий каталог вашего проекта (когда вы запускаете его только из Visual Studio) в каталог, в котором находятся все необходимые DLL. Вам все равно придется вручную копировать файлы при внешнем выполнении программы, но это немного облегчит разработку.

0 голосов
/ 19 апреля 2009

Похоже, у вас есть две конкретные проблемы:

  1. Как скопировать dll собственного кода перед началом сборки
  2. Как динамически определить зависимости собственного кода, которые необходимо скопировать в случае их изменения.

Для 1) вы можете использовать шаг предварительной сборки в своем проекте C # для вызова пользовательской утилиты для копирования правильных файлов.

Похоже, 2) уже был ответ здесь на переполнение стека .

...