Разрабатывая как 32-битные, так и 64-битные процессоры, как мне структурировать мой проект для автоматической ссылки на нужные библиотеки?

Question

Я сейчас нахожусь в ситуации, когда у меня есть как 32-битные, так и 64-битные машины-разработчики, работающие над моим проектом на c #. Я должен сослаться на пару DLL, которые имеют 32-битную и 64-битную версию. Очевидно, что 32-битные машины должны ссылаться на 32-битную DLL, а 64-битные машины - 64-битную DLL. Проблема, с которой я сталкиваюсь, заключается в том, что каждый раз, когда разработчик проверяет какой-то код, он также проверяет свои ссылки на dll, поэтому, когда кто-то на другой стороне тянет их код, он не собирается, и ему приходится вручную обновлять свои ссылки обратно. к тому, что они должны быть. Затем они регистрируются, и другие разработчики должны вручную исправить свои ссылки и т. Д. И т. Д. До тошноты.

Не думаю, что это новая проблема, но я впервые столкнулся с ней. Существует ли распространенная практика, когда проект автоматически ссылается на правильную DLL для ЦП? Или, возможно, способ иметь 32-битный и 64-битный проект, каждый с правильными ссылками, и способ (возможно, инструмент командной строки или какой-то внешний, который можно связать в сборку) связать их вместе, чтобы при появлении новых элементов добавлен или удален один, другой тоже будет обновляться?

Другой вариант - заставить каждого разработчика использовать одну и ту же виртуализированную среду разработки. Если я пойду по этому пути, могу ли я виртуализировать 64-битную систему на 32-битном оборудовании или мне придется пойти другим путем и виртуализировать 32-битную. Это будет продукт SaaS, поэтому мне нужно развернуть только для одного процессора, и я бы предпочел, чтобы он был 64-битным.

Answer 1

Здесь вы найдете пример того, как изменить ссылку на сборку в соответствии с вашей целевой платформой:

http://www.ryangerard.net/post/8768828095/how-to-change-visual-studio-assembly-references

(Вы должны изменить файлы .csproj вручную). И не забывайте, что на 32-битных машинах выберите «x86» в качестве целевой платформы, в то время как на 64-битных машинах выберите «x64»).

Answer 2

У меня похожая проблема, но мое решение немного другое. У меня просто все разработчики разрабатывают с помощью библиотек x86.

Итак, код фактически идентичен на всех машинах. Затем, во время выполнения (и для тестирования), я использую приложение запуска, которое будет проверять ОС и перемещаться по DLL, чтобы во время выполнения использовались надлежащие DLL. Логика в лаунчере довольно проста. Что-то вроде:

If IntPtr.Size = 8 Then
  '-- Copy x64 DLLs into position
Else
  '-- Copy x86 DLLs into position
End If

Конечно, при копировании вам нужно копировать обратно, чтобы вы всегда могли переключаться между x64 и x86 (в случае переносимого приложения). Однако, если вы устанавливаете непереносимое приложение, тогда запускать его не нужно, так как все эти проверки ОС можно выполнить внутри установщика (поэтому устанавливаются только нужные DLL).

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

Answer 3

Я выполняю аналогичную задачу. Мое решение состояло в том, чтобы использовать предварительные события и определенные папки ресурсов. Мои 32-битные эталонные библиотеки были помещены в одну папку, а 64-битные - в другую.

del "$ (ProjectDir) \ dlls * .dll" - удалить все dll из общей папки ресурсов

xcopy "$ (ProjectDir) \ CommonResources" "$ (ProjectDir) \ dlls" / s / i / y - копировать общие dll в папку ресурсов

Следующие две команды копируют правильные 32- или 64-битные библиотеки в папку ресурсов

if $ (PlatformName) == x64 (xcopy "$ (ProjectDir) \ dlls-64 \ My64Bit.dll" $ (ProjectDir) \ dlls / s / i / y)

if $ (PlatformName) == x86 (xcopy "$ (ProjectDir) \ dlls-32 \ My32Bit.dll" $ (ProjectDir) \ dlls / s / i / y)

Используя аналогичные команды для пост-сборки, я запрашивал ссылки на выходной каталог для упаковки.