Позвольте мне объяснить, что здесь происходит.Я должен предположить, что подпроект, который вы строите здесь, является немодифицированным проектом C-Sharp.
По умолчанию файлы .csproj имеют цель по умолчанию «Build», поэтому при использовании здесь задачи MSBuild она будет выполнять цель по умолчанию в проекте.Это определяется как
<Target
Name="Build"
Condition=" '$(_InvalidConfigurationWarning)' != 'true' "
DependsOnTargets="$(BuildDependsOn)"
Outputs="$(TargetPath)"/>
В документации к задаче MSBuild указывается, что вывод «TargetOutputs» будет содержать элементы, объявленные в «Выходах» этой вызываемой цели - в данном случае это single item, а именно значение свойства $ (TargetPath) в вызываемом проекте.Это только содержит имя встроенного исполняемого файла или библиотеки DLL (обратите внимание, что не только отсутствует .config, но и любые ссылки на сборки!)
Я отменяю свое первоначальное решениеон получает все встроенные выходные данные, поскольку он просто не работает - это была цель, которую я имел в одном из моих файлов импорта утилит, но при исследовании кажется, что я фактически нигде не использовал его, плюс он требовал ссылки на Microsoft.CloudService.цели (которыми я являюсь, но я сомневаюсь в этом).
То, что я думаю вы пытаетесь сделать, - это получить все файлы, из которых состоит Foo.exe (включая.config) в одну группу элементов, так что вы можете скопировать их куда-нибудь.Это довольно сложно, если учесть все, что может составить вывод csproj: первичный вывод (.exe), файл конфигурации, ссылки на сборки, помеченные copyLocal, сателлитные сборки (ваши DLL-библиотеки .resx), элементы содержимого и т. Д. И т. Д.
Об этом очень легко позаботиться, если вы знаете, что при создании файла csproj все элементы будут выводиться в папку single .Это верно при сборке в Visual Studio, поскольку она помещает все выходные данные компиляции в bin \ Debug.Таким образом, вы можете подумать, что FilesToDeploy $(OutDir)\**\*.*.Но это , а не , когда ваш проект создается TeamBuild - поскольку TeamBuild изменит OutDir на глобальный каталог "Binaries", который каждый проекта выводит в (для предотвращения дублирования)сборки и т. д.).Это будет означать, что FilesToDeploy будет содержать содержимое этой папки, что, я сомневаюсь, именно то, что вы хотите.
Вы, без сомнения, обнаружили это (или, по крайней мере, ожидаете этого), и именно поэтому у вас есть цельэто спрашивает .csproj "каковы ваши выходные данные сборки и где они?"Однако в Microsoft.Common.Targets нет единой цели, которую можно вызвать, объявляющей весь набор выходных данных сборки.Группа Azure попыталась решить эту проблему (и, возможно, удалось в контексте того, что они пытаются сделать), и я попытался скопировать это в предыдущем решении, которое у меня было здесь, но оно просто не работает (или, по крайней мере,У меня нет времени, чтобы заставить это работать).
Это не все идеально, но не все потеряно, если вы вернетесь к предположению, что я сбил: проблему было бы легче решить, если бы мы это сделалиЗнайте, что все результаты сборки будут отображаться в одной папке при сборке как внутри VS, так и в TeamBuild.Тогда FilesToDeploy был бы простым ***. * Glob.
. Вы могли бы достичь этого, если бы вы изменили свой TfsBuild.Proj и заставили OutDir вашего проекта быть (скажем)$ (BinariesRoot) \ FooExe:
<SolutionToBuild Include=$(SolutionRoot)\Sources\Foo.csproj">
<Properties>
OutDir=$(BinariesRoot)\FooExe\
</Properties>
</SolutionToBuild>
На самом деле у меня есть полный набор настроенных «связывающих» целей - в файле .csproj я могу объявить, что хочу, чтобы копии выходных данных передавались в наборкаталоги, и цели будут копировать весь вывод в каждый каталог.Но это как раз то, что я должен был представить, поскольку последние несколько месяцев я потратил на постепенное преобразование устаревшей nmake.exe сборки в собственный MSBuild, и я не хочу публиковать это здесь и испортить этоответить