Ориентация на разные фреймворки с использованием MSBuild создает проблемы с зависимостями - PullRequest
Новая
       12

Ориентация на разные фреймворки с использованием MSBuild создает проблемы с зависимостями

2 голосов
/ 13 февраля 2009

У меня небольшой проект, и я хочу иметь 2 скомпилированные версии этого проекта:

  • тот, который нацелен на .NET 2.0 framework
  • тот, который нацелен на .NET 3.5 framework

Все идет хорошо; Я поставил свой проект на непрерывную интеграцию (используя CC.NET) и создал 2 CC.NET «проекта». Один проект для каждой целевой структуры.

Я не буду вдаваться в подробности (не относящиеся к делу), но мое решение настроено на использование платформы .NET 3.5 в VS.NET.

У меня есть 2 задачи msbuild:

  • одна задача, которая создает решение для .NET 3.5 (просто и легко)

  • одна задача, которая создает решение для .NET 2.0

    В этой задаче я вызываю MSBuild и указываю, что TargetFrameworkVersion должен быть v2.0. Я также определяю некоторые дополнительные условия сборки (чтобы в сборке, предназначенной для .NET2.0, не создавался специфический код .NET3.5).

Пока все хорошо. Все отлично работает Теперь проблема заключается в следующем:

Мое решение имеет несколько зависимостей (ссылки на сторонние сборки). В VS.NET для этих зависимостей я установил для параметра «копировать локально» значение true. Когда CC.NET собирает мою версию сборки .NET3.5, сторонние зависимости действительно копируются в мой выходной каталог.

Однако, когда CC.NET строит мою версию сборки .NET2.0, зависимости не копируются в мой выходной каталог. (Затем это приводит к сбою моих юнит-тестов.)

Мой вопрос сейчас: Как я могу сказать msbuild, что некоторые сторонние ссылки должны копироваться локально при сборке моей версии .NET2.0 моего проекта? Или, есть ли другой способ добиться этого, так как я не хотел бы указывать каждую зависимость еще раз в моем скрипте сборки. Думаю, это быстро станет кошмаром технического обслуживания.

Ответы [ 3 ]

2 голосов
/ 29 июня 2009

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

Итак, я копался в MSDN и наткнулся на это:

ResolveAssemblyReference.TargetFrameworkDirectories Недвижимость

Примечания Это свойство необходимо для определения статуса CopyLocal для Итоговые предметы.

Если это свойство не указано, нет Полученные предметы будут иметь CopyLocal значение true, если они явно есть личные метаданные значение true на исходном элементе.

Таким образом, это означает, что есть еще одна возможность, а именно: установить TargetFrameworkDirectories задачи ResolveAssemblyReference. Однако есть ли кто-нибудь, кто знает, как это сделать?
Я пробовал разные вещи, но, похоже, ничего не работает ...

Я пробовал это: 

<ItemGroup>
    <TargetFrameworkDir Include="$(SystemRoot)\Microsoft.NET\Framework\v2.0.50727" />
</ItemGroup>

<PropertyGroup>
   <TargetDirsToUse>@(TargetFrameworkDir)</TargetDirsToUse>
</PropertyGroup>

<ResolveAssemblyReference TargetFrameworkDirectories="$(TargetDirsToUse)" />

Но безрезультатно ... Может быть, кто-то еще знает, как это сделать, или имеет золотой совет. (Я тратил много времени на эту чертову проблему).

1 голос
/ 16 февраля 2009

Мне удалось решить эту проблему, убедившись, что я не ссылаюсь на сборки из GAC. Вместо этого я создал каталог lib в своем проекте, который содержит сторонние сборки. В моем решении я ссылаюсь на сторонние сборки оттуда и устанавливаю copy local == True.

Кроме того, вы также должны убедиться, что в вашем файле csproj указанные сборки имеют тег Private, значение которого равно true. Как это: 

<Reference Include="...">
   <SpecificVersion>False</SpecificVersion>
   <HintPath>...</HintPath>
   <Private>True</Private>
</Reference>
0 голосов
/ 01 июля 2009

Один вопрос: что произойдет, если вы попытаетесь скомпилировать решение или проекты 2.0 внутри VisualStudio? Сторонние ссылки автоматически копируются или нет?

Странно, что это будет работать для 3.5, а не для 2.0. Я не занимался параллельным построением, но когда я преобразовал свои проекты с 2.0 на 3.5, все сторонние ссылки были скопированы независимо от версии .NET.

Кстати: я никогда не ссылаюсь на сторонние библиотеки от GAC (только от Microsoft, и даже не все из них). Я всегда копирую их в свою структуру каталогов lib, добавляю их в систему контроля версий и ссылаюсь на них оттуда. Насколько мне известно, использование сборок из GAC является плохой практикой, поскольку оно представляет собой ненужную зависимость от настройки машины разработки.

Пример такой директории: http://code.google.com/p/projectpilot/source/browse/#svn/trunk/lib

...