After updating the solution for the .NET framework 4.5, daily deployment stopped working

Question

We have been successfully updating our development website daily using msdeploy from TFS2010.

This worked fine until we updated VS2012, our application from the .NET Framework 4.0 to 4.5 and ASP.NET MVC from 3.0 to 4.0. Everything seems to be fine, but the assemblies are deployed, but nothing has been deployed.

I have been studying this for two days now and cannot understand why this is happening, and now my ideas are running out.

The following is part of my build script in how it worked before the upgrade.

<MSBuild Projects="$(SolutionRoot)\My.Web\My.Web.csproj" Properties="MvcBuildViews=False;AllowUntrustedCertificate=True;AuthType=Basic;Configuration=Dev;CreatePackageOnPublish=True;DeployIisAppPath=dev.myweb;DeployOnBuild=True;DeployTarget=MsDeployPublish;MSDeployPublishMethod=WMSvc;MsDeployServiceUrl=https://10.xxx.xxx.xxx:8172/MsDeploy.axd;UserName=UserName;Password=Password;UseMsdeployExe=True" ContinueOnError="False" /> 

When the update started and my problem was discovered, we used Web Deploy 2.0, but now we upgraded it to Web Deploy 3.0. I also made sure that we are building ToolsVersion="4.0" .

UPDATE -

msbuild.exe / p: AllowUntrustedCertificate = True / P: AuthType = Basic / P: Configuration = Dev / P: CreatePackageOnPublish = True /p:DeployIisAppPath=dev.myweb / P: DeployOnBuild = True / P: DeployTarget = MsDeployPub MSDeployPublishMethod = WMSvc /p:MsDeployServiceUrl=https://10.xxx.xxx.xxx:8172/MsDeploy.axd / P: UserName = Username / P: Password = Password / P: UseMsdeployExe = True E: \ Builds \ 1 \ \ Daily_Build, however, \ Sources \ My.Web \ My.Web.csproj

Now I also tried to run the above msbuild command from our TFS and no answer that completely disappointed me. Nothing in the TFS event log, nothing in the log file, verbosity ... Any ideas?

It works using the msdeploy command, as shown below;

 <Exec Command="&quot;C:\Program Files\IIS\Microsoft Web Deploy V3\MSDeploy.exe&quot; -verb:sync -source:contentPath=&quot;E:\Builds\1\WhatEver\Daily_Build\Sources\My.Web\My.Web.csproj&quot; -dest:contentPath=&quot;E:\dev.my.web&quot;,computername=https://10.xxx.xxx.xxx:8172/MsDeploy.axd,username=UserName,password=Password,authtype=Basic -allowUntrusted=True" ContinueOnError="false" /> 

-

UPDATE 2 - It looks like Microsoft has added verification of which projects that are published and our web application are not, since the Output Type is a class library. This was true with v4.0, but apparently not for v4.5.

Does anyone have an idea what to make it work again? Do I need to change project type? Create a publishing package up and then deploy it? Or what?

-

Has anyone else had the same problem? Did you find an exchange solution?

May have a problem with the version of MSBuild?

Answer 1

Here is what I would recommend. In VS2012, we simplified the automation of publishing your web projects using publishing profiles created in the publishing dialog box. In your case, create a new MSDeploy profile. When you create this profile, we will save the settings to a file in the section "Properties \ PublishProfile" (or "My project \ PublishProfile for VB"). The extension of this file will be .pubxml. These files are actually MSBuild files that you can configure if necessary. You can also continue to use the publish dialog. The password will be saved in the .user file and encrypted so that you can decrypt it.

Once you have created this profile, you can publish it using the following command if you are creating a .sln file.

 msbuild mysoln.sln /p:DeployOnBuild=true /p:PublishProfile=<ProfileName> /p:Password=<Password> 

If you are creating .csproj / .vbproj, you need to adjust it a bit as follows.

 msbuild mysoln.sln /p:DeployOnBuild=true /p:PublishProfile=<ProfileName> /p:Password=<Password> /p:VisualStudioVersion=11.0 

Learn more about why VisualStudioVersion is required at http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx .

After that, you can create + publish, as before. FYI, we sent all these new online publishing features for VS2010 to the Azure SDK https://www.windowsazure.com/en-us/develop/net/# .

Also in your question, I noticed that you are specifying some custom properties, such as MvcBuildViews. Now you can put these properties directly into the publication profile (.pubxml file) if you want. Of course, you can still pass them on the command line if that makes sense for your scenario.

More information about this at http://sedodream.com/2012/06/15/VisualStudio2010WebPublishUpdates.aspx .

If you look at the approach that we had for developers to automate the publication, you had to specify the properties and goals that will be performed during the assembly. The problem with this approach is that it limits our ability to improve our online publishing experience. In the new issue, we introduced an abstraction, a publishing profile that allows us to change the basic goals of the web publishing pipeline, and your automation scripts will continue to work. Hopefully from this point of view you do not have to re-visit this issue.

Answer 2

Today I had the same problem. I am also trying to get a .NET 4.5 web application that is automatically deployed using a machine that does not have Visual Studio 2012 installed. However, there were a few minor differences in my situation: I used TeamCity instead of TFS and our solution was created with .NET 4.5, not the one that was updated with .NET 4.0.

However, I had the same problem. I would use MSBuild to build a web application and deploy it for IIS, in much the same way. This approach worked fine on my dev machine. However, when I ran MSBuild on the CI server, he created the web application quite successfully, but after that he stopped: no errors, no warnings, nothing, just a message that the assembly was successful. There was not the slightest hint of trying to deploy an application in IIS.

It seems that MSBuild lacked the appropriate goals for performing a web deployment. The fix was to copy the folder C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web from my development machine to the CI server, copying it to the same place on the CI server, as it was on my the car.

As soon as I did this, MSBuild then grumbled about the need to use Web Deploy 3.0, but it was fixed quite easily. After installing this on the CI server, MSBuild also quite successfully deployed the web application.

Answer 3

To extend Luke Woodward's answer :

I also found that deploying C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\ from my local machine to the build server was a fix.

However, the real fix is ​​to install Microsoft Web Developer Tools as part of the VS 2012 installation, which, in particular, will create this folder. This applies to the Ieppie licensing objection.

I checked this ...

• Uninstall C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\
• Launching the VS 2012 installer and adding MS Web Dev tools.
• Verification that C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\ returned after installation.