Развертывание .Net Source Source Control (SVN) на 32-битных и 64-битных станциях разработки

Question

Вот ситуация:
Наша команда разработчиков имеет разнородные системы ОС, распределенные между 32-разрядными и 64-разрядными.Это не идеально, мы фактически планируем гомогенизировать нашу инфраструктуру, но в то же время нам приходится иметь дело с ней.

Проблема в том, что когда 32-разрядный разработчик проверяет 64-разрядное решение на SVNон должен вручную изменить целевые платформы снова, чтобы скомпилировать его (не говоря уже о других побочных проблемах)

Мой вопрос:
Какое чистое (хотя и временное) решениеможет быть решено в такой ситуации, позволяя каждому разработчику сохранять свои настройки проекта / платформы по умолчанию при проверке и из SVN.

Я думаю, что - по крайней мере, в первый раз, когда проект / решение извлекается,Разработчик все еще должен настроить параметр вручную, чтобы правильно его скомпилировать.После этого, согласно соответствующим SVN-фильтрам, можно игнорировать некоторые файлы настроек (какие, кстати?)

Я открыт для всех умных и подробных предложений.

Спасибо.

Answer 1

Вы проверяете файлы .suo и .user в системе контроля версий? Так как они должны быть специфичными для разработчика, и не следует включать . Уверен, что suo поддерживает состояние сборки проекта для каждого пользователя.

Другой вариант - выполнить сборки из сценариев. Например, у меня есть 4 различных файла сценария сборки, соединенных с помощью autohotkey для создания версии проекта в фоновом режиме и в режиме отладки. Это можно настроить с помощью msbuild или nant на то, как вы хотите, чтобы конфигурация проекта выглядела.

Это дает преимущество, не связывая визуальную студию.

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

Answer 2

Есть ли причина, по которой вы специально ориентируетесь на 32-битные и 64-битные решения?Например: Собственные, неуправляемые библиотеки DLL?

Если вы используете опцию платформы «Любой процессор», тогда .NET будет запускать ее в 64-битном или 32-битном режиме в зависимости от того, что доступно на машине.

Редактировать: Другой вариант, если вы должны установить режим ЦП статически, это настроить конфигурацию сборки x86-32 и x86-64, а затем попросить разработчиков выбрать соответствующую конфигурацию сборкина их конце.

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

Answer 3

Пока вы используете только управляемый точечный код (без собственного 32/64-битного кода), каждый корпус может работать только с 32-битным решением на 64-битных и 32-битных дев-станциях.На win7-64 visual studio также есть 32-битное приложение.