Укажите другой путь для провайдера iisApp при создании пакета с помощью msdeploy

Question

Как мне сделать пакет

Я делаю пакет msdeploy так:

msdeploy.exe -verb:sync -source:iisApp=c:\content\ -dest:package=c:\pkg.zip

Каталог c: \ content содержит один файл index.html .

Результат

Вывод выглядит так:

Info: Adding package (package).
Info: Adding child iisApp (c:\content\).
Info: Adding child createApp (c:\content\).
Info: Adding child contentPath (c:\content\).
Info: Adding child dirPath (c:\content\).
Info: Adding child filePath (c:\content\index.html).
Total changes: 6 (6 added, 0 deleted, 0 updated, 0 parameters changed, 0 bytes copied)

Если я извлекаю содержимое c: \ pkg.zip в каталог c: \ pkg , это выглядит так:

archive.xml
systemInfo.xml
Content\c_C
Content\c_C\content
Content\c_C\content\index.html

Если я дам дамп пакета следующим образом:

msdeploy.exe -verb:dump -source:package=c:\pkg.zip -xml

Я получаю:

<output>
    <MSDeploy.iisApp>
        <iisApp path="c:\content\">
            <createApp 
                path="c:\content\" 
                isDest="False" 
                managedRuntimeVersion="" 
                enable32BitAppOnWin64="" 
                managedPipelineMode="" 
                applicationPool="" 
                appExists="True" />
            <contentPath path="c:\content\">
                <dirPath 
                    path="c:\content\" 
                    securityDescriptor="D:" 
                    parentSecurityDescriptors="" 
                    attributes="Directory">
                    <filePath 
                        path="index.html" 
                        size="0" 
                        attributes="Archive" 
                        lastWriteTime="07/07/2011 20:58:00" 
                        securityDescriptor="D:" />
                </dirPath>
            </contentPath>
        </iisApp>
    </MSDeploy.iisApp>
</output>

---

Как я хочу, чтобы это было

Я не хочу, чтобы пакет зависел от текущего местоположения файлов сайта. Я собираюсь отправить посылку покупателю, и я не хочу, чтобы какие-либо подробности о процессе упаковки доставлялись вместе с посылкой. Я хочу, чтобы содержимое пакета c: \ pkg.zip было таким:

archive.xml
systemInfo.xml
Content\index.html

Я хочу, чтобы пакет мог создавать приложения IIS, поэтому мне нужен виртуальный путь. Я также хочу установить пакет в папку по умолчанию. Таким образом, физический путь также должен измениться. Я хочу, чтобы свалка выглядела примерно так:

<output>
    <MSDeploy.iisApp>
        <iisApp path="Default Web Site\Site">
            <createApp 
                path="Default Web Site\Site"
                isDest="False" 
                managedRuntimeVersion="" 
                enable32BitAppOnWin64="" 
                managedPipelineMode="" 
                applicationPool="" 
                appExists="False" />
            <contentPath path="c:\inetpub\wwwroot\site">
                <dirPath 
                    path="c:\inetpub\wwwroot\site" 
                    securityDescriptor="D:" 
                    parentSecurityDescriptors="" 
                    attributes="Directory">
                    <filePath 
                        path="index.html" 
                        size="0" 
                        attributes="Archive" 
                        lastWriteTime="07/07/2011 20:58:00" 
                        securityDescriptor="D:" />
                </dirPath>
            </contentPath>
        </iisApp>
    </MSDeploy.iisApp>
</output>

Я изменил атрибуты iisApp и createApp поставщика path на Default Web Site\Site. И я изменил атрибуты contentPath и dirPath provider path на c:\inetpub\wwwroot\site.

---

Вопросы

• Как мне это сделать?

Answer 1

Вам нужно взглянуть на правила замены MS Deploy, полезную функцию , хорошо спрятанную в блоге MS Deploy Team .

В вашем случае вам потребуется расширить командную строку с помощьюкуча выражений замены, что-то вроде этого:

msdeploy.exe 
-verb:sync 
-source:iisApp=c:\content\ 
-dest:package=c:\pkg.zip
-replace:objectName=iisApp,targetAttributeName=path,
         replace="Default Website\Site"
-replace:objectName=createApp,targetAttributeName=path,
         replace="Default Website\Site"
-replace:objectName=contentPath,targetAttributeName=path,
         replace="c:\inetpub\wwwroot\site"
-replace:objectName=dirPath,targetAttributeName=path,match="^c:\content",
         replace="c:\inetpub\wwwroot\site"

Выполнение этого должно дать желаемый результат.

В приведенном выше примере первые 3 правила замены совпадают по имени тега (objectName) и имя атрибута (targetAttributeName), и заменяется указанной строкой замены.Последнее правило замены будет соответствовать всем атрибутам пути всех тегов dirPath, начинающихся с "c: \ content", и будет заменять только ту часть значения атрибута строкой замены.

Наконец, я не нашел способа избежать того, чтобы zip-файл пакета содержал имена исходных папок.Единственный обходной путь - упаковка из нейтрального временного местоположения, например «c: \ site».

Итак, процедура такова:

• Скопируйте ваши вещи в нейтральное, временное местоположение.
• Создайте свой пакет отсюда.
• Используйте глагол: dump, чтобы увидеть сгенерированный XML.
• Создайте свой пакет заново с добавленными правилами замены для всего, что вы хотите изменить впакет.
• Принимайте таблетки от головной боли; -)

Answer 2

У меня были более или менее такие же проблемы.

Перво-наперво:

Длинные пути для машин развертывания

Для этого я использовал трюк, найденный на http://sedodream.com/2013/01/13/WebPackagingFixingTheLongPathIssue.aspx

Как предлагается в посте, можно изменить желаемый (, у вас может быть несколько ) .pubxml файлов в папке Properties / PublishProfiles в вашем проекте. , Я придерживался этого подхода, поскольку он позволял мне настраивать поведение для каждого профиля публикации.

Если я не ошибаюсь, я полагаю, что вы можете применить ту же модификацию к файлу {project-name} .wpp.targets (который, вероятно, еще не существует) в корневом каталоге проекта. каталог. Изменения здесь, однако, влияют на конвейер веб-публикации (wpp) и, следовательно, на все профили публикации, найденные в проекте.

Однако ...

Этот подход чуть не испортит ваше развертывание, когда придет время заменить строки подключения на строки, предоставленные вашим профилем публикации . Причина: вышеупомянутый трюк не влияет на строки подключения, так как они создаются автоматически wpp в время сборки . Бух-ха!

Решение, которое я нашел для этой проблемы, было двойным:

1.) Создан файл parameters.xml , в котором я вручную объявил строки подключения. Хорошо, возможно я скопировал их из файла parameters.xml в файле .zip моего пакета, так как я развертывал его в пакете. Это помогло.

Они выглядят примерно так:

<parameter name="myConnection-Web.config Connection String" defaultValue="" tags="SqlConnectionString" 
        description="myConnection Connection String used in web.config by the application to access the database.">
    <parameterEntry kind="XmlFile" scope="DeploymentPackage\\Web\.config$" match="/configuration/connectionStrings/add[@name='myConnection']/@connectionString" />
</parameter>

2.) Включил следующую строку вверху того же .pubxml файла, который мы изменили ранее

<AutoParameterizationWebConfigConnectionStrings>false</AutoParameterizationWebConfigConnectionStrings>

И ... Вуаля!

Создание приложения ISS

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

Однако, когда вы создаете пакет, независимо от того, создали ли вы файл elements.xml или нет, для вас создается файл *. SetParameters.xml template . В нем в качестве самого первого параметра вы увидите «Имя веб-приложения IIS», которое по умолчанию будет соответствовать тому, что вы вставили в свой профиль публикации. Вы можете изменить это; на все, что вы хотите.

Помните, я уже говорил шаблон раньше? Я имел в виду это; это просто шаблон. Вы должны взять этот *. SetParameters.xml файл и сделать столько копий, сколько необходимо. Для чего они? Параметры, связанные с окружающей средой. Вы можете иметь:

• DEV.SetParameters.xml
• QA.SetParameters.xml
• Staging.SetParameters.xml
• Production.SetParameters.xml
• ... и так далее и тому подобное

, а затем используйте файл параметров, наиболее подходящий для работы (или среды), например:

{yourProjectName}.deploy.cmd /Y /M:{targetServer} [...] -setParamFile:QA.SetParameters.xml

или ее эквивалентная командная строка MsDeploy, конечно.

Теперь, по умолчанию, манифест, созданный для вас в время сборки и хранящийся в вашем пакете в файле archive.xml , будет использовать iisApp Поставщик в первую очередь. Это хорошо, потому что этот провайдер, в отличие от провайдера createApp , фактически создаст каталог для вас, если он не существует. По крайней мере, согласно этой заметке от TechNet:

"В отличие от поставщика iisApp, если физическая папка для нового приложения не существует, поставщик createApp не создает физическую папку под папкой родительского сайта; он только создает ссылку в конфигурации на такую ​​папку. Если вы хотите создать физическую папку, вам придется создать ее вручную до или после использования createApp. По этой причине вам следует вместо этого использовать провайдера iisApp. Поставщик iisApp является более подходящим выбором, поскольку он использует провайдера createApp в качестве первый шаг в серии шагов, которые включают создание приложения в конфигурации, создание физической папки для приложения, если папка не существует, и копирование файлов содержимого в папку нового приложения. "

Я был бы рад включить ссылки ... но так как у меня нет 10+ баллов, мне разрешено только одно за сообщение. Пойди разберись! :)

Итак, короче ...

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

В случае, если вам действительно необходимо переопределить это, вы можете либо определить свой собственный файл манифеста и развернуть его (отдельная тема) ... или вы можете следовать совету @peter_raven и переопределить его значение, используя -Replace правила от MsDeploy.

Любой из них будет работать как заклинание.

Answer 3

Префикс пакета удаляется путем предоставления свойств вида, области видимости и соответствия, как показано ниже:

"msdeploy.exe" \
     -verb:sync                                                   \
     -source:iisApp="[Path to your website contents]"             \
     -declareParam:name="IIS Web Application Name",kind="ProviderPath",scope="IisApp",match="^C:\\path\\to\\your\\site\\folder",defaultValue="Default Web Site/SomeSite"  \
     -dest:package=[WebDeployPackageName].zip

Answer 4

Мне удалось решить проблему с заданными вручную строками подключения при использовании решения от @SkyFighter.Теперь можно использовать функцию автопараметризации и иметь параметры строки подключения с правильными областями действия.

К счастью, в WPP есть место для внедрения.К сожалению, мне пришлось использовать AfterTarget / BeforeTarget вместо SomeTargetDependsOn переменных, чтобы сузить размещение новой цели.

А вот и сама цель:

<Target Name="Replace_WebConfigsToAutoParmeterizeCS_TransformScope"
        AfterTargets="PreAutoParameterizationWebConfigConnectionStrings"
        BeforeTargets="AutoParameterizationWebConfigConnectionStringsCore"
        Condition=" '$(EnableAddReplaceToUpdatePacakgePath)'=='true' ">
  <ItemGroup>
    <_WebConfigsToAutoParmeterizeCS>
      <TransformScope>$([System.String]::Copy('%(TransformScope)').Replace('$([System.IO.Path]::GetFullPath($(WPPAllFilesInSingleFolder)))', '$(PackagePath)'))</TransformScope>
    </_WebConfigsToAutoParmeterizeCS>
  </ItemGroup>
</Target>

Он управляется теми же переменными, что и в примере Саида для фиксации длинных путей.Так что поместите эту цель в любое место, где эти переменные уже доступны.

PS Для этого трюка / взлома требуется по крайней мере MSBuild v3.5, где манипулирование метаданными было впервые введено.