Creating a server-level Web Deploy package

Question

I can use Web Deploy to create packages that can be imported in existing IIS sites after the IIS server administrator manually creates the site for me.

Can I use Web Deploy to create packages that can be imported as a site instead of an application?

When I try to import my existing packages, I get this ugly error.

error

I would want to ask the same question. I am only able to import on server-level when I use the provided command line .cmd and edit SetParameters.xml with the appropriate data — spankmaster79, Jun 23 '15 at 09:30
I found that you can use PowerShell DSC to deploy sites. It doesn't have anything to do with Web Deploy, but it looks far more flexible. — Steven Liekens, Jun 23 '15 at 13:30
Also looks nice. I did stick with Web Deploy and use parameters.xml to configure and execute `Web.deploy.cmd /Y -setParamFile:"Web.SetParameters-.xml"` — spankmaster79, Jun 23 '15 at 15:02
I'd love to see how you set up your build configurations/web config transformations/parameters.xml files @spankmaster79 — Steven Liekens, Jun 24 '15 at 06:24

score 0 · Answer 1 · edited May 23 '17 at 11:44

This might not be an answer to the question as was not able to find information on how to create a site package.

But as you asked for it in the comments, here's my approach on how to use the .cmd file created by the package process to install on site level.

Step 1

I create a package in our build process with msbuild. I've just added an extra step to our normal build that creates the project files in a deploy directory.

<Target Name="CreateDeploymentPackage">
    <MSBuild Projects="$(CurrentProject).csproj" Targets="Package"
      properties="Platform=$(Platform);
      Configuration=$(Configuration);
      DeployOnBuild=false;
      DeployTarget=Package;
      PublishProfile=$(Environment);
      PackageLocation=$(DeployDirectory)\_PublishedWebsites\DeployPackage\$(CurrentProject).zip;
      PackageAsSingleFile=true;
      _PackageTempDir=$(PackageOutputDir)\temp;">
    </MSBuild>
</Target>

I did set a specific PublishProfile to be able to pass a Web.config transformation for everything I know at build time.

Step 2

I've created a Parameters.xml in my project to be able to change params on install time of the package.

<?xml version="1.0" encoding="utf-8" ?> 
<parameters>
  <parameter name="Log4net to email"
   description="Please provide the email address for Log4net."
   defaultValue="itsupport@ourcompany.com"
   tags="">
    <parameterEntry kind="XmlFile" scope="\\web.config$" match="//log4net/appender[@name='SmtpAppender']/to/@value" />
  </parameter>

  <parameter name="Webservice address"  
    description="Please provide the endpoint address for the document web service" 
    defaultValue="http://test.services.ourcompany.com/Service.svc"
    tags="">
    <parameterEntry kind="XmlFile" scope="\\web.config$" match="//system.serviceModel/client/endpoint/@address" />
  </parameter>

  <parameter name="Elmah error email subject"
    description="Please provide the elmah errormail subject"
    defaultValue="Our Portal (Production) | An unexpected error occurred"
    tags=""> 
    <parameterEntry kind="XmlFile" scope="\\web.config$" match="//elmah/errorMail/@subject" />
  </parameter>
</parameters>

You might think why there is no sitename and connection string in the Parameters.xml. But these are created automatically configurable when the deploy package is created and can be set with the SetParameters.xml

Read here: Why are some Web.config transforms tokenised into SetParameters.xml and others are not?

Step 3

Then I created a SetParameters-.xml for every environmen we have (prod, staging, test, dev). Here's one example for staging:

<?xml version="1.0" encoding="utf-8"?>
<parameters>
  <setParameter name="IIS Web Application Name" value="staging-sitename.ourcompany.com" />
  <setParameter name="Log4net to email" value="webdev@ourcompany.com" />
  <setParameter name="Webservice address" value="http://staging.services.ourcompany.com/Service.svc" />
  <setParameter name="Elmah error email subject" value="Our Portal (Staging) |  An unexpected error occurred" />
  <setParameter name="PortalEntities-Web.config Connection String" value="metadata=res://*/Src.Entity.PortalEntities.csdl|res://*/Src.Entity.PortalEntities.ssdl|res://*/Src.Entity.PortalEntities.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=test.sql.ourcompany.com;Initial Catalog=Portal_Staging;User Id=<userid>;Password=<password>;Application Name ='OurPortal';Connection Timeout=180;MultipleActiveResultSets=True&quot;" />
</parameters>

Step 4

Then I excecute the install on the server with the following command

Portal.Web.deploy.cmd /Y -setParamFile:"Portal.Web.SetParameters-STAGING.xml"

There's still a lot of room for improvement, and I would like to automate more but this is what I have right now.

This is very similar to how I have it now. I'm not happy with having to set up a Web.$(Configuration).config file for each environment, but I also don't want to move environment-specific constants to the parameters.xml file. I wish there was a better way. — Steven Liekens, Jun 24 '15 at 08:09
I wish there was too, still searching in hope that I did miss something somewhere — spankmaster79, Jun 24 '15 at 08:58
Maybe use *.wpp.targets files to drive the XDT transformation instead of the $(Configuration) variable? So you would always build and deploy the `Release` configuration, optionally apply `Web.Release.config`, then finally let a custom deploy step in *.wpp.targets apply environment-specific transformations. — Steven Liekens, Jun 24 '15 at 09:31
how would I create different *.wpp.targets files for different environments then? I'm using .wpp.targets files for applying custom skip rules for the delete action of some folders and files — spankmaster79, Jun 26 '15 at 07:35
You would have a single wpp.targets file. In that file, you would have a custom build step that applies XDT transformations from `Web.$(Environment).config`. This would happen after `Web.$(Configuration).config` is applied. Finally, you would specify `/p:Environment=STAGING` as an MSBuild argument. — Steven Liekens, Jun 26 '15 at 08:12
Suppose you have these arguments: `/p:Platform=AnyCPU;Configuration=Release;Environment=STAGING`. This would build your web app, then apply `Web.Release.config`, then apply `Web.STAGING.config`, then package your web app. — Steven Liekens, Jun 26 '15 at 08:18
that's also a good idea. But then I would have to create a different package for every environment. Now I have one deployment package and on installtime set params for the environment needed. BTW, did you get SkipExtraFilesOnServer working? For me it doesn't [see the question here](http://stackoverflow.com/questions/31053260/web-deploy-ignores-skipextrafilesonserver-set-by-msbuild) — spankmaster79, Jun 26 '15 at 08:31

score 0 · Answer 2 · answered Aug 14 '17 at 15:15

0

Basically instead of installing at the root of the site, deploy to a folder within the site!

answered Aug 14 '17 at 15:15

Sparksido

585
2
11
22

Creating a server-level Web Deploy package

2 Answers2

Step 1

Step 2

Step 3

Step 4