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

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

11 голосов
/ 23 июня 2011

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

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

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

Ответы [ 5 ]

2 голосов
/ 23 июня 2011

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

В прошлом у меня было:

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

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

  3. Настройка C # EXE и модульных тестов для встраивания x86 в платформу решений x86 и x64 в платформу решений x64, а не в сборку на платформе решений AnyCPU.

  4. Установить все нативы для сборки в Win32, когда решение имеет значение x86 и вывести в $ (ProjectDir) \ bin \ x86 \ $ (Configuration) и промежуточное значение для него с obj в пути вместо bin. x64 то же самое с x64 вместо x86 и Win32.

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

  6. Установить инициализацию класса модульных тестов, чтобы копировать все содержимое bin dir tests (конечно, правильную платформу и конфигурацию) в out of dir tests. Используйте if #DEBUG и unsafe sizeof (IntPtr), чтобы указать, где искать тестовую папку bin.

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

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

2 голосов
/ 23 июня 2011

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

1 голос
/ 23 июня 2011

Я сам этим не пользовался, но 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"

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

0 голосов
/ 29 мая 2014

Франческо Претто имеет расширение, которое помогает в этом. Вроде бы есть некоторые странности и недостатки, но это только начало.

http://visualstudiogallery.msdn.microsoft.com/619d92a2-4ead-410d-a105-135f7b4b4df9

С источником на github:

https://github.com/ceztko/SolutionConfigurationName

0 голосов
/ 23 июня 2011

Я не думаю, что у 'Active Solution Configuration' есть эквивалентное свойство макроса.

Я предлагаю вручную добавить пользовательское свойство во все файлы .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>

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

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

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