Как я могу избежать этой глубокой структуры папок с MSDeploy для файловой системы, используя MSBuild? - PullRequest
23 голосов
/ 16 ноября 2010

Я дергаюсь за эту проблему MSBuild.

Мы используем TeamCity для создания решения с двумя веб-сайтами MVC. В рамках сборки мы развертываем папку на сервере сборки. IIS указывает на эту папку, чтобы дать нам интегрированную сборку, видимую для управления.

Вот код из файла MSBuild, который использует MSDeploy для публикации пакета, но не в виде zip-файла.

<Target Name="Deploy">
  <MSBuild 
    Projects="$(SolutionFile)"
    Properties="Platform=$(Platform);Configuration=$(Configuration);
    DeployOnBuild=true;
    DeployTarget=Package;
    PackageLocation=$(PackageLocation);
    PackageAsSingleFile=False;
    AutoParameterizationWebConfigConnectionStrings=False" />
</Target>

Проблема в том, что мы получаем невероятно глубокую структуру папок. Вот пример ...

C: \ DEPLOY \ Archive \ Content \ C_C \ Users \ Edmond \ Documents \ Visual Studio 2008 \ CreatioGreen \ Creatio \ Код \ core \ trunk \ Website \ Website \ obj \ Release \ Package \ PackageTmp [опубликованные файлы]

Я действительно хочу развернуть в предсказуемые папки, такие как ...

C: \ build \ website [опубликованные файлы] C: \ build \ mobilewebsite [опубликованные файлы]

Это фон. Вот конкретные вопросы.

  1. Мы совершаем ошибку, пытаясь использовать MSDeploy для публикации в локальной файловой системе? Нам в основном нужен эквивалент функции «публикации» VS2010 с преобразованиями конфигурации. Мы не пытаемся выполнить развертывание на удаленных экземплярах IIS или чем-либо еще.

  2. Есть ли способ сделать это, кроме указания папки публикации?

  3. Я пытался использовать задачу MSBuild Copy, чтобы скопировать файлы в более разумные папки - но я не могу понять, как использовать подстановочные знаки для указания папок, которые нам нужно взять - нужно было бы быть чем-то вроде ...

C:. \ FolderPackageEndsUpIn [ANYFOLDERS] \ Сайт [ANYFOLDERS] \ PackageTmp **

Помощь!

Ответы [ 3 ]

26 голосов
/ 09 июля 2012

Если вы добавите параметр _PackageTempDir в MSBuild, он даст вам те же результаты, что и при локальной публикации.например,

msbuild C: \ PathToMyProj.csproj / p: Configuration = UAT; DeployOnBuild = true; PackageAsSingleFile = False; DeployTarget = Package; _PackageTempDir = c: \ PathToMyDeploy \; AutoParameterizationWebSt * * * 100 * false = 4Эта команда опубликует все мои файлы в c: \ PathToMyDeploy \ без сумасшедших подпапок

4 голосов
/ 17 ноября 2010

Вы можете использовать WebDeploy напрямую, чтобы получить более настроенный результат. Например, вы можете использовать следующую команду для синхронизации двух папок напрямую от корня к корню:

>"%ProgramFiles%\IIS\Microsoft Web Deploy\msdeploy.exe" -verb:sync -source:dirPath=<SourceFolder> -dest:dirPath=<DestinationFolder>

Или вы можете настроить WebDeploy для включения конфигурации IIS в место назначения, используя поставщика iisApp вместо dirPath:

>"%ProgramFiles%\IIS\Microsoft Web Deploy\msdeploy.exe" -verb:sync -source:iisApp=<SourceFolderOrIISPath> -dest:iisApp=<DestinationFolderOrIISPath>

Например, для синхронизации из простой папки с новым приложением «NewApp» на веб-сайте по умолчанию вы будете называть его следующим образом:

>"%ProgramFiles%\IIS\Microsoft Web Deploy\msdeploy.exe" -verb:sync -source:iisApp="d:\MyWebSite" -dest:iisApp="Default Web Site/NewApp"

Затем вы можете получить пакетный файл, который будет выполнять синхронизацию / упаковку, вызывая WebDeploy напрямую и будет выполняться как событие после сборки.

2 голосов
/ 19 февраля 2015

Есть немного скрытое, но элегантное решение.

При запуске сборки на общем сервере CI может быть сложно упаковать файлы в c: root по причинам изоляции.В конечном счете, предпочтительнее было бы удалить глубокий путь в самой упаковке.

К счастью, есть решение.Добавьте правило замены в файл .pubxml!Я нашел это в дополнении к внутренней сборке MS, 2-е издание: https://www.microsoft.com/learning/en-us/book.aspx?ID=16854

Я также нашел это в этом блоге: http://learnaspmvc.blogspot.se/2014/07/web-packaging-fixing-long-path-issue.html

...