Тогда я думаю, что разница между где-то между .csproj и вашим сценарием сборки MSBuild. К сожалению, я не могу вам чем-то помочь - я не использую нестандартные сценарии MSBuild, я просто вызываю MSBuild с файлом решения VS. Для остальной части сценариев я использую свой собственный движок сборки C #.
я есть небольшой проект, и я хочу иметь 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. Я также определяю некоторые дополнительные условия сборки (чтобы специфичный код .NET3.5 не был встроен в сборку, нацеленную на .NET2.0).
Все идет нормально. Все отлично работает Теперь проблема, однако, заключается в следующем:
Мое решение имеет несколько зависимостей (ссылки на сторонние сборки). В VS.NET для этих зависимостей я установил для параметра «копировать локально» значение true. Когда CC.NET собирает мою версию сборки .NET3.5, сторонние зависимости действительно копируются в мой выходной каталог.
Однако, когда CC.NET создает мою версию сборки .NET2.0, зависимости не копируются в мой выходной каталог. (Затем это приводит к сбою моих юнит-тестов).
Теперь у меня вопрос: как я могу сказать msbuild, что некоторые сторонние ссылки должны копироваться локально при сборке моей версии .NET2.0 моего проекта? Или, есть ли другой способ добиться этого, так как я не хотел бы указывать каждую зависимость еще раз в моем скрипте сборки. Думаю, это быстро станет кошмаром технического обслуживания.