Publish WebDeploy Automatically with VS Build

In general, its pretty easy to extend the MSBuild process in ASP.NET projects using the [ProjectName].wpp.targets file.  I recently attempted to answer a StackOverflow question asking how to automatically deploy on every Visual Studio build using this technique.  My first overly-confident answer was to add the same MSBuild properties that would be used from the command line in the .csproj or file:


I didn’t even try this out before answering because I was sure this would work.  Alas no, it didn’t work so I spent the next few days researching this further.

The DeployOnBuild property specifically was ignored when set statically in  the project file.  Apparently it is a special property that must be set globally on the commandline.  

As an alternative, I found that I could call MSBuild again passing the property and it worked.

You’ll notice I created some new properties to make it a bit easier to understand.  The MSBuild call references the same project so I also placed a Condition on the call to avoid a circular reference.  You can also customize which publish profile is deployed by updating the AutoDeployPublishProfileName MSBuild property.


The working source for this solution is on Github at

Please leave a comment below if this blog post was helpful or you have additional questions.  Happy deployments!

7 thoughts on “Publish WebDeploy Automatically with VS Build”

  1. This got me really close, I definitely appreciate it.

    I know my publish profile is good, because everything gets deployed without error when I publish interactively in Visual Studio. But when I attempt to publish using the “AfterBuild” approach above (pointing to the same publish profile) I get ERROR_CERTIFICATE_VALIDATION_FAILED.

    Any idea why it wouldn’t like the server’s certificate in this case?

      1. Thanks for your reply!

        I actually had seen that page. My thought was that if the publish profile worked when clicking the Publish button interactively, that the certificate is fine. I don’t understand why running the build interactively vs. calling the same publish profile programmatically would change its behavior.

        But I did manage to get around the certificate error by adding this child element under the publish profile’s element:


        That got me to a new error:

        Web deployment task failed. (Connected to the remote computer (“”) using the Web Management Service, but could not authorize. 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. Learn more at:

        I checked the event log on the target server and it showed an ArgumentNullException on the Password property. My publish profile has the password saved, so it should find it. The event log entry did show the correct user name, but for some reason it’s not grabbing the saved password.

        I tracked down that the password is encrypted in a .user file in a property named . I tried copying that element into the main profile, but no luck. On a hunch, I put the plain text password in a property named and now it works.

        I do not want to use plain text passwords. Any idea why the saved password isn’t pulled from the .user file’s property?

        I’m still confused as to why the behavior is so different when publishing using the Publish button vs. calling the publish profile programmatically.

        I really appreciate any ideas you might have.

        1. hm, apparently I need to learn the code formatting rules for these posts… that last one stripped out all of the XML elements I typed.

        2. What got me around the certificate error was adding a property named AllowUntrustedCertificate with a value of true.

          The password is persisted in a property named EncryptedPassword

          And I put the plain text password in a property named Password

        3. Sorry I haven’t run across this and I’m unsure how to decrypt the password. You could potentially create a separate targets files that you don’t check-in with a plain text password if you’re only worried about checking in the plain text password into source control.

          Visual Studio publish has always been different with additional features outside of the pure commandline tools. Not sure why, seems like this was a bad call.

  2. Sorry for all the chatter on this 🙂 I wish I could edit and delete previous comments instead of tacking on new ones.

    Turns out the property values can just be added to the MSBuild Properties attribute.


    I’d rather not deal with storing and retrieving passwords at all, so I guess I’ll need to figure out how to use NTLM, if that can be made to work.

Leave a Reply