After I ran the Publish-Interactive.ps1 script all *.configs are gone. If I deploy the same package via VS everything is fine.

Missing files:
web.config in root folder
~/Views/web.config
some other .config files I added as "content" in my project.

Any ideas what happend?

[The real root of this issue appears to be an MSDeploy bug, but there appears to be a work-around for PackageWeb, as outlined below.]

If remotely deploying (i.e. not localhost) via PackageWeb to an IIS site that is nested within one/more sites (i.e. "MySite\MyNestedSite"), PackageWeb will generate the following MSDeploy string:

"C:\Program Files\IIS\Microsoft Web Deploy V2\msdeploy.exe" -verb:sync -source:archiveDir="[archive dir here]" -dest:auto,includeAcls='False',ComputerName='https://MyServer:8172/MSDeploy.axd?site=MySite\MyNestedSite',Username=myusername,Password=mypassword,AuthType='BASIC' -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -setParamFile:"[archive dir here]\SetParameters.xml"  -skip:objectName=dirPath,absolutePath="_Deploy_" -skip:objectName=filePath,absolutePath=web\..*\.config -skip:objectName=dirPath,absolutePath=_Package -skip:objectName=filePath,absolutePath=.*\.wpp\.targets$ -allowUntrusted -enableRule:DoNotDelete

Running this will result in the following error:

Error Code: ERROR_USER_UNAUTHORIZED
More Information: Connected to the destination computer ("MyServer") using the Web Management Service, but could not uthorize. Make sure that you are using the correct user name and password, that the site you are connecting to exists, and that the credentials represent a user who has permissions to access the site.
Error: The remote server returned an error: (401) Unauthorized.
Error count: 1.

The error msg appears to be a red herring though. You will notice that the ComputerName value tacks on the site in the querystring:

https://MyServer:8172/MSDeploy.axd?site=MySite\MyNestedSite

Because the site name is still being written to the SetParameters.xml file, PackageWeb doesn't need to tack the site in the querystring. In fact, if you execute the same command above and only change the ComputerName key/value to:

ComputerName='https://MyServer:8172/MSDeploy.axd'

the deployment succeeds! So, the fix to this issue would simply be tweaking a line in the BuildMSDeployCommand() method in the Publish-Interactive.ps1 file to remove the "?site={1}", like so:

$compNameCommandFrag = ",ComputerName='{0}'" -f $compNameFixedUp

As stated earlier, the issue appears to be an MSDeploy issue, not accepting/parsing nested site names in the querystring for whatever reason. But that limitation can be alleviated if you use the SetParameters.xml file to specify the site name instead - and NOT specify the site as a querystring parameter in the ComputerName variable.

The default VS publish process does not run into the dreaded 259 character limit in the Windows File System. MSDeploy has built in support for handling this.

When using PackageWeb since the package is extracted you are much more likely to run into this.

See the email from @tbehunin

App offline support

Currently when a publish is occurring the app will stay online, we should have an option to drop an app_offline.htm file to take the site offline for the duration of the publish process.

When the option is enabled, if there is a file named app_offline-template.htm that should be the app_offline.htm file otherwise create an empty one.

For multiple configs how can I set this file randomly or do I need to have multiple files having settings pointing to test, live. How can I tell it to Publish-Interactive.ps1 file to run which configuration setting. A bit confused. Need to run these using team city. Please guide

Apologies for raising it in issues. as couldn't find the right place to ask a question

When a user selects to allow untrusted certificates we are not passing the flag to msdeploy.exe.

There are many cases that a user would be interested in passing additional parameters to the msdeploy.exe call.

We should expose a parameter in which we can pass in additional MSDeploy parameters.

Instead of having a folder named SedodreamPackage it would be better to have it as _Package.

In some cases you can have a package which exceeds the windows 255 character limit. See the comment by David on Sayed's blog at http://sedodream.com/CommentView,guid,a3b53276-c7c7-4150-855a-ccb03198052b.aspx.

Proposed Solution
When extracting the files to %temp% filter out all the unneeded folders which are created by default by a VS package.

PromptUserForParameterValues is creating duplicate entries in the array which it returns. This is not causing issues currently because the values are the same, but this should be fixed.

For some reason when Publish-Interactive.ps1 is executed as a Windows Service (e.g. automated builds, continuous integration environments, etc.), it silently fails to extract the zip - no error message is indicated anywhere as to the reason why it doesn't unzip. Everything appears to function fine, with the exception to the following method call:

$destinationFolder.CopyHere($zipPackage.Items())

Currently all publishing settings are gathered from a .ps1 file. This makes it difficult to automate publishing to many environments.

We should be able to pass in specific parameters through the command line. This should be additive to the PublishConfiguration.ps1 file. When specific parameters are passed in they should take precedence over those found in the PublishConfiguration.ps1.

Currently we are prompting for all the Web Deploy settings. If the user has a publish profile it would be better to gather the publishing settings directly from that file.

Ideally PackageWeb would produce a web deploy package that can have transforms applied to all config files, not just the web .config file.

For some reason if a file is named web.QA.config it doesn't show up as an available transform when publishing.

This is most likely related to the regex used to pick up the config transforms.

In this scenario an additional ?site=bar is added to make the URL to be https://foo.com:8172?site=bar?site=bar and this causes the publish to fail.

The default VS behavior is to create packages using the same folder structure as the source. Better would be to create a package with the IIS App Path (i.e. Default Web Site/sample or msbuildbook.com).

For hoster scenarios if you give the server name as foo.com:8172 the publish fails.

Now that XDT has been released on NuGet https://nuget.org/packages/Microsoft.Web.Xdt/ we should use that instead of SlowCheetah.Tasks.dll.

When publishing there should be an option to backup the site before the publish. This would be really good in case there are any issues during the publishing so that you can revert back.

Currently the project files are a bit confusing. The files should be laid out better so that its easier to understand.

In some cases it would be useful to allow the temp directory to be overridden. Currently it just used the %temp% directory.

We have a custom TFS BuildProcess and use MSBuild to create the MSDeploy Package, but this problem occurres also on my local machine.

The MSBuild CMD for building the package is just like that:

msbuild MyWebProject.csproj /t:Package /p:Configuration=Release /p:Platform="Any CPU" /p:PackageLocation=E:\Output_Release\Web.zip /p:OutputPath=E:\Temp\

Problem: The output folder only contains the normal web-deploy files:
Web.deploy-readme.txt
Web.deploy.cmd
Web.SetParameters.xml
Web.SourceManifest.xml
Web.zip

But the Publish-Interactive.ps1 is missing. If I publish it via VisualStudio than I get the file.

On my local machine I get this warning in the build output:
Build succeeded.

E:..._Package\Sedodream.Package.targets(33,57): warning MSB4057:
The target "CopyPipelineFiles" does not exist in the project.

1 Warning(s)

On TFS I get this warnings:

$/.../_Package/Sedodream.Package.targets - 0 error(s), 2 warning(s)
C:..._Package\Sedodream.Package.targets (33):
The target CopyAllFilesToSingleFolderForMsdeploy" does not exist in the project.
C:..._Package\Sedodream.Package.targets (33):
The target "CopyPipelineFiles" does not exist in the project.

Any idea?

If you import the NuGet package multiple times in a project there may be duplicate Import elements. We should ensure that the import is only added once to a given project.

I have a question that obj\Debug\Package folder is created on run time when you run a build using teamcity on some agent. If you have test.ps1, Dev.ps1, live.ps1 parameter files for Publish-Interactive.ps1 then with a clean build they will be no longer present. how to keep those settings and pass them to Publish-Interactive.ps1 file on run time. Please guide. really sorry as I am a novice and getting time to understand this. regards

Just tried the PackageWeb and it worked well on my workstation (Win7, VS2010), but failed on my TFS Build Server (with VS2010) . I get this error:

C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (1690): The target "CopyTransformFilesWap" does not exist in the project.

The target is called in the "Sedodream.Package.targets" on line 29. I couldn't figure out where this target is defined so I now have a broken build ;-)

Currently the path to PublishConfiguration.ps1 is hard coded, it should be easily overridden.

When executing PublishInteractive.ps1, one of the user input fields is Username. After entering that field, the Powershell script executes the MSDeploy command, but the username key/value pair is missing (the password key/value are present though). On line 385 of the PublishInteractive.ps1 file, we see the following lines:

$userNameParamValue = FindParamByName -allParams $paramValues -name $paramNameUsername
$usernameCommandFrag = ""
if($userNameParamValue.length -gt 0){
    $usernameCommandFrag = ",Username={0}" -f $userNameParamValue.Value
}

$passwordParamvalue = ($paramValues | Where-Object{$_.name -eq "Password"}).Value
$passwordCommandFrag = ""
if($passwordParamvalue.length -gt 0) {
    $passwordCommandFrag = ",Password={0}" -f $passwordParamvalue
}

There is a difference in the way it's retrieving the value of the username with the value of the password - possibly the source of the bug. Is that by design?

There are some cases where the auth type should not be inferred, instead its better to allow users to pass in the value.

When this extension is used with VS 11 the Publish-Interactive.ps1 file is going to the wrong location.

Right now, PackageWeb defaults the DoNotDelete rule to true with no ability to change that. Looks like the code has a "todo" comment in place to build that feature in, but hasn't yet happened. This is just a placeholder to track that feature.

When using automated software to build/deploy solutions, they typically look at either the stderr stream or the return value of the script (zero or non-zero) to decipher whether the job succeeded or failed. When PackageWeb fails for whatever reason, the stderr stream isn't written to and/or the response returns zero. An easy fix for this is to call the "edit" PS command whenever an error occurs. For example:

Write-Host "Exiting with code 12345"
exit 12345

Add support for -Verbose to Publish-Interactive.ps1 as described at http://stackoverflow.com/questions/8469821/powershell-script-support-for-verbose.

When we create the .wpp.targets file we should update the Import statement to also include a condition which will not perform the import if the file doesn't exist on disk.

When publishing a site which has an App_Data folder with at least 1 file inside of it we are getting an error from MSDeploy. For example here is some sample output

Info: Adding sitemanifest (sitemanifest).
Info: Adding child dirPath (Default Web Site/WebApplication3_deploy\App_Data).
Info: Adding child filePath (Default Web Site/WebApplication3_deploy\App_Data\placeholder.txt).
Info: Updating filePath (Default Web Site/WebApplication3_deploy\bin\WebApplication3.dll).
Info: Updating filePath (Default Web Site/WebApplication3_deploy\bin\WebApplication3.pdb).
Info: Updating filePath (Default Web Site/WebApplication3_deploy\Web.config).
Info: Object dirPath (C:\Temp\repro\WebApplication3\obj\Debug\Package\PackageTmp\_Deploy_) skipped due to skip directive
 'CommandLineSkipDirective 1'.
Info: Updating setAcl (Default Web Site/WebApplication3_deploy).
Info: Updating setAcl (Default Web Site/WebApplication3_deploy).
Info: Adding setAcl ({IIS Web Application Name}/App_Data).
Error Code: ERROR_SITE_DOES_NOT_EXIST
More Information: Site '{IIS Web Application Name}' does not exist.
Error count: 1.

Currently if MSDeploy v2 is not installed the publish is not performed but a "silent" error occurs.
Better would be to give an error, we should also create a mechanism (env variable?) that users can specify the full path to msdeploy.exe which should be used.

Details

Here is the implementation in Publish-Interactive.ps1 which needs to get updated

function GetPathToMSDeploy {
    return ("{0}\IIS\Microsoft Web Deploy V2\msdeploy.exe" -f (Get-ChildItem env:"ProgramFiles").Value)
}

I received the comments below from someone using package-web we should updated it with his changes.

• In line 414 (in our version) (function PublishWithMSDeploy), we replaced Invoke-Expression $cmdFile with .$cmdFile because if the web app’s project name (=folder name) has a space in it, the script would fail (it works if we don’t use Invoke-Expression).
• Around line 338 (function BuildMSDeployCommand) we had to add quotes around the site name for another space/escaping issue.
• Around line 295 (function CreateSetParametersFile), we added another if statement to never include the “Add write permission to App_Data Folder”. We had to do this because for some reason the IIS web app name wouldn’t resolve properly (not sure if this is an issue in your script or VS but I suspect VS). It would still end up in the final version of SetParameters.xml as “{IIS Web Application Name}/App_Data”.

If I have a web solution that has the following structure:
~/default.aspx
~/web.config
~/web.Debug.config
~/web.Release.config
~/services/web.config
~/services/web.Debug.config
~/services/web.Release.config

When running Publish-Interactive.ps1 and specifying "Release" as the transform to apply, only the root web.config is transformed. No other transformations are applied to nested web.configs.

During publish we populate the global property $settingsFromUser, if the user passes in parameters. After the publish has completed we should wipe out this variable. There may be strange issues for multiple publish operations from the same PS window if we do not do this.

In VS2012 the default item type for added files is now Content. Because of this when PackageWeb adds files to the project they are added as Content and published. The files should not be published.

Extra files:

1. _Package folder
2. .wpp.targets

Currently the transform files must be contained inside of the package. There are a lot of scenarios where it makes sense to have the transform files outside of the package. Because of this we should allow users to specify a file path for the transform.

I am getting the following error while trying to publish it using teamcity. Steps I am using are

1. build and package
2. execute publishinteractive file by passing it a test.ps1 parameter

[12:45:07]Mode LastWriteTime Length Name

[12:45:07]---- ------------- ------ ----

[12:45:07]d---- 13/08/2012 12:45 abc.vbproj_zip

[12:45:07]Extracting .zip file

[12:45:08]Deploy folder []

[12:45:08]Skipping transform since a transform name was not specified

[12:45:08]Error: Object of type 'archiveDir' and path 'Z:\publish\trunk\abc\obj\Deploy-Test\Package\abc.vbproj.zip' cannot be created.

[12:45:08]Error: The archive directory 'Z:\publish\trunk\abc\obj\Deploy-Test\Package\abc.vbproj.zip' could not be loaded.

[12:45:08]Error: Could not find directory 'Z:\publish\trunk\abc\obj\Deploy-Test\Package\abc.vbproj.zip'.

[12:45:08]Error count: 1.

I am passing it the required values in a parameter file and also transform parameter is there but still it is saying no name given.

Please guide. What I am doing wrong here.

Using vs10 and msbuild

Publish-Interactive is always output to the obj folder, standard package files located at the PackageLocation specified by the msbuild command line.

Currently we are extracting the full package to %temp%. This can be very slow for large packages. We should simply extract out what we need and then work directly from the .zip file instead of the archiveDir.

We need to clean up the code including getting rid of the extra projects there which are not needed.

Currently each time the app starts we update the contents from the remote git repo. We should add an option so that this can be disabled. For environments in which sites are recycled often this can be extremely annoying.

Experiencing the same issue with SlowCheetah (http://sedodream.com/2012/12/24/SlowCheetahBuildServerSupportUpdated.aspx), however I feel that editing the msbuild file manually to include the targets file is a better solution than running a dummy project build, so that's what I've done.

Added the following to my web .csproj file, now it works like a dream.

<Import Project="_Package\Sedodream.Package.targets" />

When Publish-Interactive.ps1 is invoked and a value is specified for the transform we should look for a PublishConfig file that lines up with that. For example if Staging is specified for the transform we should look to see if there is a file named PublishConfiguration.Staging.ps1 and use that for gathering the parameter values.

Currently all the functions which are re-used are declared directly in the Publish-interactive.ps1 file. We should leave this as a single file for customers (because we don't want to introduce more files), but in order to facilitate testing we need to convert the script into a module.

When building on VS2010 you will receive the error

Error 13 The expression "[System.IO.Path]::GetFullPath('')" cannot be evaluated. The path is not of a legal form. C:\Temp_NET\PkgWeb\dev10\dev10_Package\Sedodream.Package.targets 94 7 dev10
.