We have with success been updating our development web site at a daily basis using msdeploy from TFS2010.
This was working fine until we upgraded to VS2012, our application from .NET Framework 4.0 to 4.5 and ASP.NET MVC from 3.0 to 4.0. It look like all is well and assemblies deployed but nothing has actually been deployed.
I have been looking into this for two days now and can't figure out why this is happening and now I am running out of ideas.
Below is part of my build script in the way it has been working 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 upgrade was initiated and my problem discovered we were using Web Deploy 2.0 but now we have upgraded to Web Deploy 3.0. I have also made sure we are building with 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=MsDeployPublish
/p:MSDeployPublishMethod=WMSvc
/p:MsDeployServiceUrl=https://10.xxx.xxx.xxx:8172/MsDeploy.axd
/p:UserName=UserName
/p:Password=Password
/p:UseMsdeployExe=True
E:\Builds\1\WhatEver\Daily_Build\Sources\My.Web\My.Web.csproj
Now I also tried to run the above msbuild command from our TFS and no response which frustrates me completely. Nothing in the event log of TFS, nothing in log file no matter verbosity... Any ideas?
It does work using msdeploy directy like below;
<Exec Command=""C:\Program Files\IIS\Microsoft Web Deploy V3\MSDeploy.exe" -verb:sync -source:contentPath="E:\Builds\1\WhatEver\Daily_Build\Sources\My.Web\My.Web.csproj" -dest:contentPath="E:\dev.my.web",computername=https://10.xxx.xxx.xxx:8172/MsDeploy.axd,username=UserName,password=Password,authtype=Basic -allowUntrusted=True"
ContinueOnError="false" />
--
UPDATE 2 --
It appears Microsoft added a check for what type of projects that are publishable projects and our web application are not, since the Output Type is Class Library. This has been valid with v4.0 but apparently not for v4.5.
Anyone have an idea of what to do make it work again? Do I need to change the project type? Create publishing package up front and then deploy that? Or what?
--
Anyone else that has had the same problem? Have you found a solution to share?
Could there be an issue with version of MSBuild?
Here is what I would recommend. In VS2012 we have made it easy to automate publishing your web projects using the publish profiles which are created by the publish dialog. In your case create a new MSDeploy profile. When you create that profile we will save the settings into a file under Properties\PublishProfiles (or My Project\PublishProfiles for VB). The extension of this file will be .pubxml. Those files are actually MSBuild files, which you can customize if needed. You can continue to use the publish dialog as well. The password will be stored in a .user file and encrypted such that only you can decrypt it.
After you have created that profile you can publish with the command below if you are building the .sln file.
msbuild mysoln.sln /p:DeployOnBuild=true /p:PublishProfile=<ProfileName> /p:Password=<Password>
If you are building the .csproj/.vbproj then you need to tweak this a bit in the following way
msbuild mysoln.sln /p:DeployOnBuild=true /p:PublishProfile=<ProfileName> /p:Password=<Password> /p:VisualStudioVersion=11.0
More on why VisualStudioVersion is required at http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx.
Once you do this you will be able to build+publish just like you did previously. FYI we have shipped all these new web publish features for VS2010 in the Azure SDK https://www.windowsazure.com/en-us/develop/net/#.
Also in your question I noticed that you are specifying some custom properties, like MvcBuildViews. You can now place those properties directly inside the publish profile (the .pubxml file) if you want. Of course you can still pass them in on the command line if that makes more sense for your scenario.
More info on this at http://sedodream.com/2012/06/15/VisualStudio2010WebPublishUpdates.aspx.
If you take a look at the approach that we had for developers to automate publishing it was to specify properties and targets to be executed during the build. The problem with this approach is that this limits our ability to enhance the web publish experience. In the new release we have introduced an abstraction, the publish profile, which allows us to change the underlying targets of the web publish pipeline and your automation scripts will continue to run. Hopefully from this point forward you will not have to re-visit this issue.
I had much the same problem today. I too was trying to get a .NET 4.5 web application automatically deployed using a machine that did not have Visual Studio 2012 installed on it. There were a couple of minor differences in my situation, however: I was using TeamCity instead of TFS, and our solution was created with .NET 4.5 as opposed to being one that had been upgraded from .NET 4.0.
Nonetheless, I did have the same problem described. I'd use MSBuild to build the web app and deploy it to IIS, in much the same way. This approach worked fine on my dev machine. However, when I ran MSBuild on the CI server, it quite happily built the web app, but it stopped after that: no errors, no warnings, nothing, just a message that the build was successful. There wasn't the slightest hint of an attempt at deploying the app to IIS.
It seems MSBuild was missing the relevant targets to perform the web deployment.
The fix was to copy the folder C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web from my dev machine to the CI server, copying it to the same place on the CI server as it was on my machine.
Once I did that, MSBuild then grumbled about needing Web Deploy 3.0, but that was fixed easily enough. After installing that on the CI server too, MSBuild quite happily deployed the web app.
To extend Luke Woodward's answer:
I, too, found that deploying C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\ from my local machine to the build server was the fix.
However, the real fix is to install the Microsoft Web Developer Tools as part of the VS 2012 installation, which will create this folder, among other things. This addresses Ieppie's licensing objection.
I tested this by...
Deleting C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\
Running the VS 2012 installer and adding MS Web Dev tools.
Verifying that, after the install, C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\ was back.
Related
I have create a sample ASP.NET 5 application (pretty much the example one from New Solution), and pushed it to GIT hosted on Visual Studio Team Services (former Visual Studio Online). I want to set up continuous integration to Azure Web App (former Azure Web Site). I have tried to set it up from Azure portal itself, it did create a new build definition, but it fails to build ASP.NET 5. I have found a guide how to do this, but it never really worked for me, I get errors like this e.g.
Error parsing solution file at C:\a\1\s\Frontend\src\Frontend\Frontend.xproj: Exception has been thrown by the target of an invocation.
Predefined type 'System.Void' is not defined or imported
Another problem is that it seems it really takes a lot of time to install dnvm, get packages, etc. So all in all it's a pain to make it work.
So are there real alternatives for that or more importantly is Microsoft is planning to implement something like a Build ASP.NET 5, Deploy ASP.NET to Azure and such to make it easy as I suppose it's easy with the current ASP.NET 4 apps. I really hope that it will be an option soon since it's quite impossible to work with current build system.
For "System.Void" issue, please check the runtime version in "global.json" file and make sure it is consistent with the dependencies in "project.json" file.
For dnvm install issue, since AspNet5 runtime environment isn't installed on VSTS Hosted Build Agent for now and the different users may use different runtime versions, it requires the user to add a "PreBuild" PowerShell step to read the runtime version in "global.json" file and then install it. If you can make sure that you will always only use one version (For example: 1.0.0-rc1-update1), you can deploy your own build agent and install "1.0.0-rc1-update1" on it, then you can skip the dnvm installation during the build process.
Take a look on http://riffer.eu/wordpress/?p=112. There I have a solution vor asp.net core RC_1.
Amazingly you need only two powershell scripts - there is no compiling / visual studio necessary.
We're trying to work through the new tool chain for building and deploying an ASP.NET 5 (vNext) CoreCLR web site to a server cluster. Between the new compilation changes and the changes to TFS, I'm not sure how everything now gets built and deployed. The scenario is as follows:
On-premise TFS for source control and build agent
Targeting ASP.NET 5 under CoreCLR, hosted via IIS
Questions are:
Using TFS for continuous integration builds (and hopefully deployment to an on-premise IIS server), how does one build and deploy this new application type?
It seems like MSBuild might still be usable to point at a .sln file so as to indirectly invoke dnu.exe, is that correct? Is that the appropriate way to do that now?
Should we be running a scripted build task instead to run dnu.exe instead?
How are these new CoreCLR builds deployed? Just a straight copy to a directory on a remote machine?
This is a new application and we're using a multi-layered application architecture, where the DAL and Business logic are in their own CoreCLR projects, if that makes a difference.
Thanks in advance for shedding some light on the situation.
Here is what we ended up doing:
Powershell script "prebuild.ps1" as per the previous answer and Microsoft deployment guidelines: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/azure/deploy-aspnet5
Vanilla MSBuild build. no switches or special settings.
Powershell script to execute xUnit test runner. We used guidance from this post at http://fluentbytes.com/running-xunit-test-with-asp-net-dnx-and-tfs-2015-build/
Powershell script to run "dnu publish". This creates a directory of the entire web application's structure.
"Windows File Copy" task to deploy the directory structure created in #4 to all of the target machines in the test environment.
To build and deploy ASP.NET 5 via TFS2015 vNext build system, you need to:
1). Create a PowerShell script (named Prebuild.ps1, for example) to install DNX. Details of the PowerShell script can be found: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/azure/deploy-aspnet5 . Add the script file into TFS version control.
2). Add the PowerShell script build step into build definition. Run the Prebuild.ps1 script in this step:
3). In the MSBuild step, specify the project needs to be built, and add the following /p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:CreatePackageOnPublish=True /p:MSDeployPublishMethod=InProc /p:MsDeployServiceUrl=localhost /p:DeployIisAppPath="Default Web Site/TFSTest1" /p:VisualStudioVersion=14.0 to publish the project to IIS.
I'm trying to configure Visual Studio Online to continuously deploy my ASPNET 5 application to an Azure webapp as described in this tutorial from the Team Foundation Build docs: https://msdn.microsoft.com/Library/vs/alm/Build/azure/deploy-aspnet5
I have followed all the steps and everything is working great. By default this script deploys a build of my app that targets the full .Net 4.5.1 DNX so I decided to try and modify it to deploy for .Net Core.
The build script creates its deployment package by calling: msbuild.exe /t:Build,FileSystemPublish
After turning up log verbosity and reading through the relevant msbuild files I have learned the following:
The "Build" target ultimately uses dnx.exe to compile the project. Because the project.json file includes both dnx451 and coreclr TFMs this step produces build output for both frameworks - so far so good.
However, the FileSystemPublish target seems to only output an msdeploy package that targets the .Net 4.5.1 runtime. From the logs I could see executing the FileSystemPublish target ultimately issues a "dnu publish" command and in my cases passes "dnx-clr-win-x86.1.0.0-beta6" as the -runtime parameter. When I followed the breadcrumbs to find out where it was getting the value "dnx-clr-win-x86.1.0.0-beta6" from I eventually ended up in the "GetRuntimeToolingPath" task in Microsoft.DNX.Tasks.dll. This task seems to look in global.json to determine the correct runtime to use but strangely appears to internally override this value with "x86" and "clr" before creating the return string.
If I have interpreted things correctly, it seems that the FileSystemPublish target (in Microsoft.DNX.Publishing.targets) is essentially (indirectly) hard wired to use the x86, full .Net framework DNX when it produces its package output. At this point I am stuck for how to get this build process to produce a .Net Core package.
My question is why would FileSystemPublish be coupled to the x86 full .Net DNX and given this appears to be the case (unless I am mistaken) what is the recommended way to produce an msdeploy package for an ASPNET 5 app that targets .Net core?
EDIT:
For now I have a workaround. I can pass /p:RuntimeToolingDirectory="C:\Users\buildguest\.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-beta6" as a parameter to msbuild.
This overrides the default logic in the GetRuntimeToolPath and forces it to use .Net Core. This works but feels like a hack so I'm leaving the question open for a better answer.
To publish Core CLR, you can pass the msbuild parameter 'PublishDNXVersion' as dnx-coreclr-win-x64.1.0.0-beta6.
msbuild <project>.xproj /p:deployOnBuild=true;PublishDNXVersion=dnx-coreclr-win-x64.1.0.0-beta6
From the Old Azure portal within the Web App section of it on the Dashboard page of your particular Web App.
[deep breath]
On the right hand side is a section that says "set up publishing with visual studio online". Clicking on that link will walk you through the necessary steps to set up continuous deployment from a visual studio online repository (either git or tfs based)
Since that is a mouthful, I have provided a link to a tutorial which walks you through the entire process: https://azure.microsoft.com/en-us/documentation/articles/cloud-services-continuous-delivery-use-vso/#step3
Had the same problem with .NET Core RC2-preview1 tooling. My solution: Add SDKToolingDirectory to my .xproj with a proper path to .NET Core installation:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">14.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
<SDKToolingDirectory>C:\Program Files\dotnet</SDKToolingDirectory>
</PropertyGroup>
I had some luck with this by passing the following parameters into the Bundling step of my Visual Studio Online build process:
/p:Bundle64BitRuntime=true /p:BundleCoreClrRuntime=true
This causes my publish to leverage the 64 bit CoreCLR Runtime when it runs through msbuild.exe.
I figured this stuff out by digging through the Microsoft.DNX.Publishing.targets file (found at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web) and looking for variables I could pass in as properties. Regarding runtime, this seems to be an interesting snippet:
<GetRuntimeVersion
Condition="'$(IgnoreDNXRuntime)' != 'true'"
RuntimeVersionOverride="$(PublishDNXVersion)"
TargetDNXVersion="$(_DefaultDNXVersion)"
RuntimeToolingVersion="$(RuntimeToolingVersion)"
Want64Bit="$(Bundle64BitRuntime)"
WantCoreClr="$(BundleCoreClrRuntime)">
<Output PropertyName="FinalPublishVersion" TaskParameter="RuntimeVersion"></Output>
</GetRuntimeVersion>
There's probably a little bit(?) of risk here in terms of future proofing your build routine against future changes to variables names. But, you know, beta software and all that :)
Good luck!
I'm trying to get my web application to deploy automatically at the end of an automated build and I'm obviously missing something.
My setup is:
VS2012 on a Win7 workstation
TFS2010 repository on serverA
TFS build agent on serverB
Test site in IIS7 on serverC.
I have created a quick test project using the default MVC4 template and created a Team Project to go with it using the MS VS Scrum 1.0 template.
I created a new publish profile for the web application using the publish web dialog and the .pubxml file is checked in with the project. The .pubxml file looks something like this:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>MSDeploy</WebPublishMethod>
<SiteUrlToLaunchAfterPublish>TestServer/DeployTest</SiteUrlToLaunchAfterPublish>
<MSDeployServiceURL>http://TestServer</MSDeployServiceURL>
<DeployIisAppPath>webapp-dev/DeployTest</DeployIisAppPath>
<RemoteSitePhysicalPath />
<SkipExtraFilesOnServer>False</SkipExtraFilesOnServer>
<MSDeployPublishMethod>RemoteAgent</MSDeployPublishMethod>
<UserName>mydomain\myuser</UserName>
<_SavePWD>True</_SavePWD>
<PublishDatabaseSettings>
<Objects xmlns="" />
</PublishDatabaseSettings>
</PropertyGroup>
</Project>
*some of the names have been changed to protect the innocent :)
Using this profile I can successfully publish the application from Visual Studio to the test web server without any issue. Following Scott Hanselman's blog post I successfully published from the command line on my workstation:
msbuild DeployTest.csproj /p:DeployOnBuild=true /p:PublishProfile=Test /p:AllowUntrustedCertificate=true /p:Password=notTheRealPassword
I then created a build in Team Explorer that would use my build server to compile and then run the unit tests. All good. The project builds, unit tests pass.
I then added the parameters from the command line to the MS Build Arguments in the Advanced section of the build definition:
/p:DeployOnBuild=true /p:PublishProfile=Test /p:AllowUntrustedCertificate=true /p:Password=notTheRealPassword
The build runs, the unit tests pass, nothing is published to the web server. :(
Can someone enlighten me as to what I have missed? Nothing I've read seems to indicate a step I have missed out but there's seemingly precious little documentation to explain how this is done.
It sounds like tfs might not support publish profiles.
You may need to pull out all the parameters from the profile and specify them manually.
Here's a similar question.
Team Build: Publish locally using MSDeploy
I know this is an old question but today I ran into the same issue and I think I know the reason for the behavior you observed. Let me summarize the issue:
You have create a web deploy publish profile.
When you use the profile from command prompt with MSBuild command, the site is published successfully.
But when you use this profile from the build definition (by specifying MS Build Arguments in the advanced section of the build definition) the site is not published.
I think the reason behind this is because you have VS 2012 on your workstation which supports publish using profile feature. Hence when you run the MS build from command prompt on your work-station the site is published. But the support for publish profile is not available on TFS 2010 hence with build server the site is not published.
I faced the same issue today and I did following to resolve the issue:
On TFS machine, from the command prompt, I ran the MS Build command with publish profile. The command ran successfully but nothing got published (copied) on the site. This proves that TFS 2010 server does not support public profiles.
I had VS 2010 deployed on the TFS machine. I installed web deploy 3.5 and Windows Azure SDK for Visual Studio 2010. This is the way to provide support for publish profile on VS 2010.
Then I ran the MS Build command using published profile from command prompt and it published the site successfully.
Then finally executed the build definition with MS Build parameters and the site got published successfully.
I know installing Visual studio on TFS machine not an ideal solution but at least it solved my problem.
I am also not sure why installing VS 2010 with publish profile support resolved the issue. But it seems that, after the installation some of the missing components/dlls got deployed on the TFS machine which resolved the issue.
Hope this resolves your deployment issue.
[UPDATE]: There could be another reason for the above behavior. Check the log messages of the build activity. If you find a warning similar to this:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (484, 9): warning: The OutputPath property is not set for project ProjectName.csproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Release' Platform='Any CPU'
Then it may be related to build configuration. If you are using “Any CPU” as build configuration then change it to “AnyCPU” (remove space). Refer following link for the detailed explanation:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/0bb277ec-a08c-4795-88f0-3207654e2560/the-outputpath-property-is-not-set-for-project-xxxxxbtproj-please-check-to-make-sure-that-you?forum=tfsbuild
Amey
Can someone point out any tutorials that help build windows services using msbuild.
Requirements :
- Should not use the csproj file
- Output should be the same as the publish option in Visual Studio
Updated question:
We have a project of type windows service in our solution. In this windows service, we are referencing a couple of libraries that reside on a different system (one of them is not strongly named). This solution also contains other class libraries and websites/web-apps.
I am trying to write a custom build that outputs a xcopy deployable version of the website, and a deployable version of the windows service. When I say windows service, it shows up on the Control Panel -> Services MMC.
The website build was easy via msbuild...however I am struggling with the windows service build. Until now, my fellow developers were using the right-click on the project file ,and click publish to publish the windows service. This generates a setup.exe file that helps the admins to deploy the service.
So, now here is my question:
I want to use msbuild to build my windows service.
I do not want to directly use the .csproj file in conjunction with msbuild to build the service.
The output my build file generates should match the output from the "publish" option (*the publish option generates a setup.exe file*)
In general, "the publish option" under the covers just runs a build with /t:Publish, i.e., it triggers a different target to the normal default 'Build' one.
Can you tell us more of what you are looking for, as opposed to not looking for?
Are you looking to generate an MSI? (If so, you definitely won't be using MSBuild if you're using the built-in .vdproj system - but be careful - this means having to put VS on a build server)