Подтвердить что ты не робот

Как вы можете получить доступ к платформе уровня решения Visual Studio из события сборки проекта С#?

У нас есть большое решение VS 2010, которое в основном является кодом С#, но есть несколько родных DLL, от которых зависят различные проекты С# (включая нашу модульную DLL). Мы работаем над обработкой поддержки 32-разрядных и 64-разрядных версий наших библиотек. Итак, теперь мы создаем собственные DLL как 32-битные и 64-разрядные. Проблема в том, что многие наши проекты С# имеют события после сборки, которые копируют необходимые библиотеки DLL в проект TargetDir. Теперь, когда у нас есть две разные версии родных DLL (32 и 64 бит), мне нужно указать правильный каталог для копирования родной DLL. Первоначально я думал, что могу просто использовать $(Platform) в пути следующим образом:

copy $(SolutionDir)\NativeDll\$(Platform)\$(Configuration) $(TargetDir)

Но это не работает, потому что $(платформа) - это платформа проекта, а не платформа уровня решения. В этом случае $(Платформа) есть "Любой процессор". Из того, что я вижу, глядя на макросы события после сборки в проекте С#, похоже, нет способа получить доступ к платформе уровня решения, которая строится. Есть ли лучший способ достичь моей цели?

4b9b3361

ОТВЕТЫ

Ответ 1

Я считаю, что платформа решений, в отличие от проектов, - это просто текст.

То, что у меня было в прошлом, это:

  • Удалите Win32 и "смешанную платформу" из решения (и продолжайте делать это после добавления проектов).

  • Задайте все DLL-библиотеки С# для сборки как AnyCPU на платформах решений AnyCPU, x86, x64. (Не удаляйте AnyCPU, если вы хотите открыть в Blend или если в решении есть какие-либо чистые управляемые приложения.)

  • Установите С# EXE и модульные тесты для построения в x86 в платформе решений x86 и x64 в платформе решений x64, а не для сборки вообще на платформе решений AnyCPU.

  • Задайте все туземцы для сборки в Win32, когда решение x86 и вывести в $(ProjectDir)\bin\x86\$(Конфигурация) и промежуточное к тому же с obj в пути, а не в bin. x64 то же самое с x64 вместо x86 и Win32.

  • Задайте события предварительной сборки С# EXE и модульные тесты для копирования собственных DLL, на которые они зависят от относительного пути с именем конфигурации проекта: $(Config)

  • Инициализировать класс unit tests, чтобы скопировать все содержимое тестов bin dir (правильная платформа и конфигурация, конечно) в тестовые файлы. Используйте, если #DEBUG и небезопасный sizeof (IntPtr), чтобы указать, где искать файлы bin для тестов.

  • Вручную (с помощью Блокнота) добавьте относительный ссылочный путь к файлам .csproj вне решения, использующим сборки x86/x64 из места развертывания решения, поэтому путь будет включать в себя $(Платформа) и $(Конфигурация) и не будет пользователь.

Microsoft: Лучшая поддержка 32/64 бит в Visual Studio будет действительно на месте.

Ответ 2

Когда мне приходилось это делать, я просто сделал все свои сборки доступными как x86 или x64, а не AnyCPU, и имел два отдельных пакета вывода. В AnyCPU действительно нет смысла, если вы ЗНАЕТЕ, что ваш процесс должен быть 32-битным или 64-битным prori.

Ответ 3

Я не использовал его сам, но Build → Batch Build, вероятно, вы хотите. С его помощью вы можете создавать несколько платформ.

http://msdn.microsoft.com/en-us/library/169az28z.aspx

Конечно, это фактически не позволяет вам получить доступ к "платформе" для решения, но вам не нужно, поскольку вы будете строить каждую платформу отдельно.

Обновление: Если вы хотите автоматизировать сборку, создайте пакетный файл со следующим содержимым

"c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv" ../solution.sln /rebuild "platform"

где "платформа" - это "Release | Any CPU", "Release | x86" и т.д. и повторяйте строку для каждой конфигурации, которую нужно построить. Используйте Configuration Manager для настройки каждого проекта для сборки для x86 и x64, и вы должны иметь то, что хотите.

Ответ 4

Я не думаю, что "Конфигурация активного решения" имеет эквивалентное свойство макроса.

Я предлагаю вручную добавить настраиваемое свойство во все файлы .csproj, как это (см. новое настраиваемое свойство MyVar, добавленное для каждой комбинации конфигурации/платформы):

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  ...
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    ...
    <MyVar>MyDebugAnyCpu</MyVar>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    ...
    <MyVar>MyReleaseAnyCpu</MyVar>
  </PropertyGroup>

Вы можете использовать меню "Unload project" и "Edit MyProject.csproj" для редактирования .csprojet, в то время как в Visual Studio. Важно знать, что Visual Studio не уничтожит эти "неизвестные" значения, даже если вы сохраните их с помощью обычного графического редактора.

Затем в событии post build вы можете использовать эти значения, например:

copy $(SolutionDir)\$(MyVar)\$(Platform)\$(Configuration) $(TargetDir)