Используйте единственное решение для Visual Studio создать и x86 и x64 одновременно?
Удостоверьтесь, что Вы определяете где пункт при удалении записей.
5 ответов
Мы делаем что-то подобное для сборки основных сборок для .NET CF. Попробуйте следующее:
<Target Name="AfterBuild">
<MSBuild Condition=" '$(Platform)' == 'x86' " Projects="$(MSBuildProjectFile)" Properties="Platform=x64;PlatFormTarget=x64" RunEachTargetSeparately="true" />
</Target>
Я думаю, что лучший способ сделать это - вызвать msbuild из командной строки. Редактировать файлы msbuild не нужно, просто запустите
msbuild myproj.sln /p:Configuration="Debug|Win32"
msbuild myproj.sln /p:Configuration="Debug|x64"
. Я предполагаю, что если разработчик использует Visual Studio, он будет генерировать только библиотеки DLL, чтобы они могли выполнять отладку с ними, и что у вас есть отдельный процесс сборки, если вы действительно развертываете библиотеки DLL?
Вы не сможете сделать это с помощью пользовательского интерфейса Visual Studio. Для этого вам нужно будет взломать файлы MSBuild.
Для C ++, и если это проект, файлы / настройки которого меняются нечасто, один из способов сделать это - создать два проекта в решении, причем оба проекта будут ссылаться на одни и те же исходные файлы. Затем в сборках x64 установите для одного проекта 64-разрядную сборку, а для другого - 32-разрядную. (В сборках x86 установите один из них как 32-разрядный, а другой отключите.)
Мы используем это некоторое время, и он отлично работает.
Конечно, вы должны быть осторожны, чтобы любые изменения, которые вы вносили в один, также были внесены в его копию. т.е. если вы добавляете / удаляете файл или изменяете его настройку сборки, вы должны сделать это в двух местах. Изменения исходного кода по-прежнему нужно вносить только один раз, потому что остается только одна копия каждого исходного файла.
И, конечно, вы можете решить, что это более сложно / рискованно, чем отказ от использования IDE. Однако в нашем случае это сработало очень хорошо.
Я столкнулся с этой проблемой с проектом, запущенным в VS2008 XP (32-bit), а также VS2010 7 (64-bit). Решением, которое я использовал, было использование переменной $(PROGRAMFILES). Она правильно разрешилась на обеих машинах.