Как автоматически упаковать (MSDeploy) проект веб-приложения как часть сборки проекта в Visual Studio IDE? - PullRequest
4 голосов
/ 14 сентября 2011

У меня есть проект веб-приложения в Visual Studio 2010, для которого настроены параметры MS Deploy.Я могу щелкнуть правой кнопкой мыши проект в обозревателе решений и запустить «Build Deployment Package», который говорит MSDeploy создать zip-файл развертывания.Это внутренне зависит от цели Build для проекта.Все это работает.

Проблема в том, что я не могу понять, как заставить функционирование упаковки MSDeploy работать как часть цели Build в Visual Studio.Другими словами, когда я щелкаю правой кнопкой мыши по проекту в обозревателе решений и выбираю старую «Build», я бы хотел, чтобы он также выполнил «Build Deployment Package».

«Почему бы просто не нажать« Build »«Развертывание пакета», спросите вы?Потому что я действительно хочу, чтобы цель сборки моего веб-приложения была зависимостью от другого проекта в моем решении, который является установщиком WIX.Другими словами, у проекта WIX есть одна зависимость, которая является моим проектом веб-приложения.Когда я собираю проект WIX, VS автоматически создает проект веб-приложения, но не создает пакет развертывания.Установщик WIX использует пакет развертывания как часть процесса установки.В этом рабочем процессе либо проект установщика WIX не удастся построить, поскольку он не может найти файлы, созданные MSDeploy (плохо), либо он найдет устаревший пакет MSDeploy и будет использовать его без жалоб (очень плохо).Излишне использовать MSDeploy и Microsoft Installer, но я беру очереди с здесь .Мне нравится идея иметь MSI, который можно связать с другими MSI или включить в приложение GPO.

Если я просто попытаюсь вручную добавить «Пакет» как событие после сборки в проект веб-приложения, вставивэто в необработанном csproj XML:

<Target Name="AfterBuild">
   <CallTarget Targets="Package" />
</Target>

, тогда простая старая сборка потерпит неудачу, потому что тогда она будет зависеть от Package, и, очевидно, цель Package зависит от Build.Это круглое.

Может быть, я действительно очень хочу, чтобы способ указать проекту установщика WIX зависеть от выходных данных цели "Build Deployment Package" или решения использовать "Build Deployment Package"а не «Build» в графе зависимостей проекта.Есть идеи по этому поводу?

Не думаю, что мне нужен скрипт MSBuild, который должен выполняться из командной строки, как при выполнении запланированной TFS TeamBuild.Я хотел бы сохранить это как задачу VisualStudio, выполняемую разработчиком (мной) с монитором, клавиатурой и мышью случайным образом и много раз в день.На самом деле, я хочу сказать, что у меня вообще нет доступа к TFS.

Ответы [ 3 ]

3 голосов
/ 15 сентября 2011

Хорошо, так что ответьте на мой собственный вопрос ...

Просто добавьте «; Package» в список целей сборки по умолчанию в самом верху рассматриваемого файла проекта, как в:

<Project ToolsVersion="4.0" DefaultTargets="Build;Package" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

Это строка 2 моего файла csproj. Теперь, когда вы нажмете «Построить», проект также выполнит задачу MSDeploy Packaging. И когда другой проект зависит от этого проекта веб-приложения, а другой проект обычно создается с помощью VS, целевой объект упаковки MSDeploy выполняется в установленном порядке.

И с миром все в порядке. Почему это было так трудно исследовать, и почему я должен вручную отредактировать файл проекта, чтобы выполнить это? Не отвечай.

1 голос
/ 15 октября 2015

Добавление «Package» Target прекрасно работает, пока вы не захотите использовать разные профили публикации.Я обнаружил, что вы можете добавить профиль публикации в качестве элемента группы свойств в свой файл .csproj, как показано ниже:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
  <PlatformTarget>$(Platform)</PlatformTarget>
  <PublishProfile>ServerDebug</PublishProfile>
   ...
</PropertyGroup>

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

1 голос
/ 20 сентября 2011

Добавьте следующее свойство в аргументы MSBuild:

/property:DeployOnBuild=true
...