2015-01-11 7 views
0

Я хочу настроить решение VS так, чтобы в конце сборки устанавливаемые файлы были застегнуты на молнии для удобства распределение. Это должно работать как с локальной сборкой, так и с сборкой TFS. Это устанавливается следующим образом:Сценарий MSBUILD должен застегивать все сборки в решении после сборки, но получает только некоторые библиотеки DLL (в локальной и TFS-сборке)

  • Там будет один проект (так называемый MyApp.Packaging), который не содержит никакого кода, просто MSBUILD .targets сценарий
  • Проект имеет ссылки на все другие проекты, так строит последний (подтверждено просмотром заказа на сборку проекта)
  • Сценарий сборки содержит следующие данные для идентификации и zip (с использованием почтовой задачи MSBUILD Community Task) EXE и DLL в два разных пакета (есть другой код, который вытаскивает номер версии из файл version.txt с использованием MSBUILD Community Tasks - опущен для ясности)
<!-- Set package name and input/output folders --> 
<PropertyGroup> 
    <PackageName>MyAppService</PackageName> 
    <BuildTargetFolder>$(TargetDir)</BuildTargetFolder> 
    <PackageOutputFolder>$(OutDir)</PackageOutputFolder> 
</PropertyGroup> 

<!-- Set location of files --> 
<ItemGroup> 
    <MyAppBinaries Include="$(BuildTargetFolder)*.exe$(BuildTargetFolder)*.dll;" Exclude="$(BuildTargetFolder)MyApp.Packaging.dll" /> 
    <MyAppOtherFiles Include="$(SolutionDir)MyApp.Packaging\InstallService.bat;$(SolutionDir)MyApp.Packaging\UnInstallService.bat;$(BuildTargetFolder)MyApp.HostService.exe.config" /> 
    <MyAppContracts Include="$(BuildTargetFolder)MyApp.Common.DataContext.dll;$(BuildTargetFolder)MyApp.Common.Shared.dll" /> 
</ItemGroup> 

<!-- After building (in Release mode only), build the installation package --> 
<Target Name="AfterBuild"> 
    <CallTarget Targets="BuildPackage" Condition="'$(Configuration)'=='Release'" /> 
</Target> 

<!-- Build the package --> 
<Target Name="BuildPackage"> 
    <!-- Package for installing the MyApp Service --> 
    <Zip Files="@(MyAppBinaries);@(MyAppOtherFiles)" Flatten="True" WorkingDirectory="$(MSBuildProjectDirectory)" ZipFileName="$(PackageOutputFolder)\$(PackageName)_$(Major).$(Minor).$(Revision)_Install.zip" /> 
    <!-- Package for MyApp Contracts --> 
    <Zip Files="@(MyAppContracts)" Flatten="True" WorkingDirectory="$(MSBuildProjectDirectory)" ZipFileName="$(PackageOutputFolder)\$(PackageName)_MyAppContracts_$(Major).$(Minor).$(Revision)_Install.zip" /> 
</Target> 

Файлы ZIP создаются в раскрывающемся месте TFS, когда TFS делает сборку или бен папку упаковочного проекта для местной сборки.

Второй ZIP (содержащий 2 библиотеки DLL) всегда создается ОК, под локальной сборкой и TFS.

Проблема в том, что , когда TFS делает сборку, первый ZIP не содержит EXE и только 2 из 23 DLL (и все 3 файла, идентифицированные MyAppOtherFiles). Когда сборка выполняется локально (и первая папка bin проекта упаковки опустела), первый ZIP не содержит EXE или DLL и только 2 файла .bat, идентифицированные MyAppOtherFiles.

Если я изменил BuildTargetFolder с $ (TargetDir) на $ (OutDir), я получаю тот же результат.

В определении сборки TFS используется немодифицированный шаблон по умолчанию.

Как будто TFS делает сборку, проект упаковки является третьим проектом, который должен быть построен, а не последним, поэтому только zipping 2 DLL. Однако решение, установленное в TFS, точно такое же, как то, что я создаю локально, и в этом случае кажется, что скрипт не может видеть ЛЮБОЙ из двоичных файлов. Если локальная сборка выполняется снова (без опорожнения папки bin в проекте Packaging), тогда ZIP-файлы содержат все необходимые файлы, но это очевидно, потому что после первой сборки папка bin теперь содержит EXE & все библиотеки DLL.

Его также сбивает с толку, что при создании TFS MyApp.HostService.exe.config (который создается сборкой) является zipped, но не MyApp.HostService.exe. И почему 2-й ZIP всегда создается ОК, когда он содержит библиотеки DLL, которые пропущены в 1-м ZIP ????? Я попытался заменить порядок создания ZIP-файлов, но это не имеет значения!

Что я могу сделать, чтобы гарантировать, что zipping всегда выполняется после того, как все проекты будут построены как в локальной, так и в сборке TFS?

Благодаря

+0

См https://github.com/ligershark/template-builder/commit/b2baa3da23481bc866a0534e22916246485153fb#commitcomment-8864994 –

ответ

1

Удостоверьтесь, что вы устанавливаете зависимость проекта упаковки от решения в зависимости от других проектов таким образом, что он всегда будет строить других в первую очередь, таким образом, вы оставите упаковку последней.

enter image description here

+0

Ticking все коробки на этом экране решить проблему! Почти все уже были отмечены галочкой, потому что в проекте Packaging были ссылки на другие проекты, но их было 2, а это не так. Я не думал, что они могут повлиять на процесс сборки (например, проект базы данных SQL), но, по-видимому, они это делают! – Laurence

0

Мы делаем что-то подобное, но у нас есть наши TFS построить установку разрешения строить Мишени/файл PROJ вместо SLn. В файле целей/proj у нас есть цель, которая компилирует наше приложение, а затем использует wix для создания msi. В вашем случае вы должны создать цель, использующую цель msbuild для компиляции вашего проекта exe, а затем вызвать zip-цель для сжатия вывода.Вы можете оставить параметр outdir как наш, вы можете установить свойство, чтобы выход шел в выбранный вами каталог. Построение этого легко будет работать как на сервере tfs, так и локально.

 Смежные вопросы

  • Нет связанных вопросов^_^