I have been trying to figure this out for a few days to no avail.
I have an MVC .Net Application that is stored in a GIT repo in VSTS. When I check in code it is being built and unit testa are being run in the cloud.
Now If these unit tests succeed I would like the project to be deployed to a remote machine that has the VSTS agent installed. I can see the agent in the VSTS web interface but I don't know how I get the automatic build to send the completed build to d:/mydeploypath on the remote agent machine.
Is this possible?
Absolutely possible!
There are build steps available to copy files to a remote machine such as Copy Files over SSH and Windows Machine File Copy. But if you are trying to deploy the code to the machine you are building on, you can use the Copy Files step since it won't require credentials. Since it is a web application, there are a few steps like IIS Utilities to stop\start the application pool so the files won't be locked for the deployment.
So using the Copy Files build step, you could use $(Agent.BuildDirectory) as the source directory (or wherever you have your build output going) and set the target folder to your desired destination on the machine.
The build/release variables helped me out a lot during the development of our release process:
https://learn.microsoft.com/en-us/vsts/pipelines/build/variables?view=vsts
The easy way is using WinRM-IIS Web App Deployment task.
To generate the web deployment package, you can specify these arguments in MSBuild Arguments box of Visual Studio Build task:
/p:SkipInvalidConfigurations=true /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageLocation="$(build.artifactstagingdirectory)" /P:PackageTempRootDir=""
Related
We are using an on-premise installation of Microsoft Visual Studio Team Foundation Server Version 16.131.
We have a Development Continuous integration build definition that includes running some unit-tests on a very old application. As such, the unit-tests require a database to run (I know, not an ideal situation with unit tests...)
One of the artifacts of the build is a DACPAC of the database.
I'd like to deploy any database changes from that DACPAC as part of the build definition, before running the Unit-Test steps. That way, any tests that are added / changed that are dependent on database changes will (hopefully) pass.
Any ideas if this is possible, and if so, how can I publish from the DACPAC within the build definition?
We are using a PowerShell step in the build/release pipeline.
In the powershell script you will call SqlPackage:
&"C:\Program Files\Microsoft SQL Server\140\DAC\bin\SqlPackage.exe" /Action:Publish /SourceFile:"Dacpac_Artifact\DACPAC\DB.dacpac" /Profile:"Dacpac_Artifact\DACPAC\FileWithPublishPrife.publish.xml"
You could also have a look at this Microsoft DevLabs task, it also contains a sub task to deploy dacpac remotely, so you could deploy to another machine (or use localhost to deploy on the build server itself if you want). There are also other marketplace task you could use just navigate to the store and type sql you'll see a dozen.
IIS Web App Deployment Using WinRM
I have a build process on VSTS which builds the web solution .sln file and publishes the artifact. All seems to be working fine.
Now I wish to use the artifact in a release to 'Publish' the web application and copy the published files over to a windows VM via SSH.
How can I get VSTS to 'publish' the application like it publishes in Visual Studio, or can I use the build Visual studio to publish.
.Net Framework Application.
Image - Build process in VSTS
If you must use SSH you can in your Release pipeline you can use the "Copy Files Over SSH" Task:
If you do not have to use SSH you can use the "Windows Machine File Copy" task:
These tasks will copy the build artifact to your windows VM.
Via VSTS I am trying to automate the following process which is currently performed manually:
Within VS 2017 perform a publish to file system.
Set settings in web.config.
Repeat 1 & 2, for each environment, e.g. Test, UAT, Production, etc.
Copy those files to an FTP server.
Logon to secure infrastructure, download files from FTP, and copy into place on IIS target servers.
The secure infrastructure is locked down, and has limited internet access. The FTP is used as a way to move files into that infrastructure.
Within this question I specifically want to address elements; 1, 2, and 3.
The struggle I am having is that VSTS seems setup to deploy web apps into Azure Web Sites or publicly accessible IIS. Whilst IIS is my eventual target, initially I was hoping to achieve a file system deployment - similar to what VS 2017 provides.
I have tried using MSBuild to create a package, using; /p:WebPublishMethod=Package /p:PackageAsSingleFile=true.
Then MSDeploy to extract the package into a folder msdeploy.exe -verb:sync -source:package="Package.zip" -dest:contentPath="content".
However that results in the following error Source (sitemanifest) and destination (contentPath) are not compatible for the given operation.
It looks like I can use MSBuild and /p:DeployOnBuild=true /p:PublishProfile=VSTS to deploy to a folder at build time, but that seems a little awkward within the structure of VSTS. E.g. I have to repeatedly build the solution for each environment.
After I have the solution deployed into a folder, I intend to use VSTS to push to FTP.
Is there a better way to do this? For example; VSTS Azure deploy provides the ability to easily set connection sting parameters.
You can achieve what you want to do with the FTP Upload build/release task.
1 - You don't have to publish to the file system.
Just create a new build definition based on asp.net application template:
This will add the tasks you need to build and package and as a final step to publish the artifacts to a drop location.
After you published it to a drop location you can either continue on build by adding the ftp task or you could add the ftp task to a release pipeline. This is up to you.
The ftp upload task then needs to be added after the publish artifacts task, like:
For 2 and 3 it is best that you use a release pipeline, where you can add several environments and tasks to it. That you can add your ftp task and get it from artifact (your build) that you will add to the release. The web.config settings can also be changed using release tasks.
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.
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.