Создание управляемой оболочки для 32-битной и 64-битной неуправляемой DLL

Question

Мы создаем оболочку C # вокруг неуправляемой DLL. Неуправляемая DLL поставляется в 32- и 64-битной версиях. Мы храним управляемую оболочку в своем собственном проекте, чтобы ее можно было создать как отдельный компонент и повторно использовать в разных решениях.

Однако это приводит к некоторым проблемам. Поскольку неуправляемая DLL имеет одинаковое имя как для 32-битной, так и для 64-битной версий, у нас возникают проблемы при перемещении правильной неуправляемой DLL в выходной каталог (bin). Если конфигурация сборки x86, мы хотим скопировать 32-битную версию, а с x64 - 64-битную. С одной архитектурой процессора это легко сделать. Мы просто включаем неуправляемую DLL в наш проект и устанавливаем для файла значение local для true. Но так как мы должны нацелить оба, это более сложно.

Мы нашли эту ссылку Ориентация как на 32-битную, так и на 64-битную версию Visual Studio в одном и том же решении / проекте , но, похоже, это указывает на некоторые библиотеки DLL, которые уже существуют на компьютере. Мы хотим, чтобы правильная версия DLL была скопирована в выходной каталог (bin).

Любые советы или методы, как решить эту проблему, приветствуются.

Answer 1

Я только что прошел через ту же проблему с оболочкой .Net для библиотеки FreeImage. Я создал две конфигурации сборки: одну для x86 и одну для x64 для проекта, который ссылается на управляемую оболочку. Я добавил разделы условного копирования msbuild в цель AfterBuild файла проекта следующим образом:

  <Target Name="AfterBuild">
    <Copy Condition="'$(Platform)' == 'X86'" SourceFiles="$(MSBuildProjectDirectory)\Resources\x86\FreeImage.dll" DestinationFolder="$(TargetDir)" />
    <Copy Condition="'$(Platform)' == 'X64'" SourceFiles="$(MSBuildProjectDirectory)\Resources\x64\FreeImage.dll" DestinationFolder="$(TargetDir)" />
  </Target>

Answer 2

Мы постоянно занимаемся этим с нашими проектами.

У нас есть неуправляемая DLL-библиотека C ++, имеющая 32- и 64-разрядные версии, и проект C #, использующий P / Invoke для вызова неуправляемой DLL.

Для C ++ DLL это целевой путь:

$ (PlatformName) \ $ (ConfigurationName) \ $ Имя_целевого_объекта)

Таким образом, сборка 32-разрядной версии будет идти в Win32 \ Release, а сборка 64-разрядной отладки - в x64 \ Debug.

В проекте C # мы удаляем конфигурацию «Любой ЦП» и заменяем ее новой конфигурацией «x86» и конфигурацией «x64». Его выходные каталоги аналогичны неуправляемым DLL-библиотекам C ++, за исключением того, что компилятор .NET использует «x86», тогда как C ++ использует «Win32» для обозначения исполняемого файла 32-разрядной архитектуры.

На этапе после сборки для проекта C # мы копируем соответствующую неуправляемую DLL в целевой каталог для исполняемого файла C #. Поскольку каждая архитектура и каждая конфигурация проекта C # имеют отдельный выходной каталог, нет проблем с определением, какая архитектура неуправляемой DLL находится в каком выходном каталоге; они всегда совпадают.

Чтобы еще больше упростить это, я предлагаю вам исследовать создание многофайловой сборки (http://msdn.microsoft.com/en-us/library/226t7yxe.aspx), чтобы ваша неуправляемая DLL и ее оболочка C # могли одновременно находиться в одной сборке .NET, что избавляет вас от необходимости копировать ее вокруг. на все.

Answer 3

Еще одним вариантом будет создание новой конфигурации в Visual Studio помимо Debug и Release .... возможно, Debug32 и Debug64 и т. Д. Одним из параметров конфигурации является архитектура процессора.

Затем в событиях посткомпиляции вашего Проекта вы можете сделать старомодный оператор if / else, используя макрос имени платформы в качестве условия ...

Или, если вы использовали Имя платформы в качестве подкаталога в своем решении, где хранилась неуправляемая DLL, вы можете скопировать из каталога, используя имя платформы, в каталог bin.

Answer 4

Возможно, вы захотите использовать что-то вроде MSBuild для управления вашими сборками в этом случае. Тогда у вас может быть флаг компиляции, который вы используете для 32- или 64-битной компиляции. Делая это, это также позволит вам контролировать, какой DLL вы нажимаете. Это звучит как ваш лучший вариант. Если вам не нравится msbuild, вы также можете использовать nant.

Answer 5

Если вы настроите свою конфигурацию на две платформы, одну для 32-битной и 64-битной версий.Затем вы устанавливаете ссылку для каждой из платформ на правильную версию dll, после чего все, что вам нужно сделать, это установить локальный флаг копирования в свойствах ссылок, и vsts все это обработает за вас.Без суеты, без суеты.