I'm sure this question has come up before, but I can't seem to find an elegant solution.
I have a web application project with multiple configurations based on deployment environment (Test, QA, Production) along with web.config transforms for each environment. We are using a web deployment package to automatically create the .zip of the app which can be deployed via MSDeploy. It's easy enough to call the package target multiple times, each with a different configuration:
msbuild MyProject.csproj /t:Package /p:Configuration=QA
msbuild MyProject.csproj /t:Package /p:Configuration=Test
But this triggers a complete rebuild of the web project each time before packaging. I want to build once, then apply the web.config transforms, and create separate packages for each environment. Is there an easy way to accomplish this without forcing a complete rebuild for each environment?
Dupe of Build once and deploy to multiple environments with msdeploy & Visual Studio 2012
I've also been wanting a solution to this, but apparently there isn't any real COMPLETE MS solution that I know of. Visual Studio provides the following (as noted here):
Web.Config transformation
Parameterization
Vishal Joshi concluded with the following:
If you can know your environment settings during build time use
Web.Config transformation.
If you would want to create deployment package only once and then
enter the settings during install time then use Parameters.xml
What I would like to see, though, is have the best of both worlds. I want to "package" up a target having ALL the configuration transformations embedded. Therefore, when the IT guy runs the WebDeploy cmd file (that gets generated when you "package"), they can provide a switch of which environment configuration they want (i.e. Dev, Test, Stage, Prod, Release, etc). I don't believe there is a solution from MS out there that does that. :(
Related
I am using OctoPack in my asp.net project to package for deployment to my environments. I noticed that OctoPack is packaging all the web.config transformation files in the package. How do I get it to transform into the one web.config so that they are not all sent to all environments?
Note: I would like to keep the default behavior of not setting up a nuspec file if possible.
Transformation is not done by OctoPack but by Octopus Deploy during the deployment.
I will assume you're using Octopus Deploy. If your Nuget package contains the transform files (like f.ex. Web.Release.config) then all you need to do is to goto your projects Process and the relevant step, click the Features link and enable Config transforms. You will have new options where you can also specify additional transforms you want to run.
More details under "Config transformations" here http://docs.octopusdeploy.com/display/OD/Configuration+files
I'm wanting to know how to perform the following
Build & package an ASP.NET website to the file system
Be able to deploy the website to one or more environments. I want to the transforms of config file to happen at the point of deployment, rather than at the point of building. This way my code is not recompiled for each deployment and there is not risk of new changes being introduced.
From my own reading I'm unsure of how to do this. WebDeploy seems to package, transform and deploy based on a configuration but Im unsure how these steps can be decoupled to avoid the need to recompile code from source control.
Does anyone have any experience in solving this issue?
You can use the Parameterization feature of web deploy a.k.a MSDeploy. You will need to use a parameters.xml file and a setParameters.xml file to dynamically swap out settings since you are not transforming your package at build time.
At deployment time you can pass in any .xml file to set the parameters you have specified in the parameters.xml file. Since the parameters.xml is at the root of your project solution (e.g see example link of where to place the file) then at build time it gets baked into your web package. However, you now have the flexibility to change those values by passing in the setParms .xml file from the command line during deployment. This is different than transforming the values during build time based on configuration settings.
Here is a msdeploy command line example of passing in a ParamFile for a staging environment.
msdeploy -verb:sync -source:package="c:\packages\mypackage.zip" -dest:auto,computername=StagingServer1 -setParamFile="c:\StagingParameters.xml"
See the below links for examples and MSDN technical information:
Web Deploy Parameterization in Action
Parameterization vs. Web.Config Transformation
Web Deploy Operation Settings
Similar question on stackoverflow that provides several methods
The majority of our internal apps are built on a Java EE stack using Ant, and deployed to Tomcat with a WAR file. We have a build box that creates a Production-targeted WAR, and the WAR is then delivered to the Test environment. A script is run to convert the deployed webapp to point to Test data environments.
After a few cycles of Test -> Bug Fix -> Build -> Redeploy to test, the WAR file is then deployed to Production, and is then live.
I've recently inherited some ASP.NET 4.0 webapps, and their Build/Deploy is quite different; the code is built in VS, and then the entire project directory is copied to each environment. It is then tweaked by hand, and is occasionally rebuilt with a VS instance on the server.
This is a bit scary, as there are plenty of opportunities for tweaks in one environment to be forgotten, and thus require that we're playing around with our apps after they're "live", outside the bounds of testing, version control, etc.
So, all of this being said:
Is there an equivalent to the Ant/WAR mechanism in a .NET world? What's the safest way to create an executable artifact from a .NET webapp and move it between environments with minimal modification? I know that "best pratices" is a taboo phrase, but I'd like to dip into some expert knowledge before I remake Ant in .NET. :-)
Three technologies you need to know about to automate web deployments:
MSBuild - This is Microsoft's equivalent of ANT. Project files are basically just a series of MSBuild tasks.
WebDeploy - This is essentially your WAR/Tomcat equivalent, except that it creates deploy packages, and is meant for IIS.
XML Transforms - You should never have to manually edit configuration by hand. Config transforms are essential if you have multiple environments you need to deploy to.
Put all these together with your favorite Build server (I use Jenkins), and you can totally automate your entire deployment process to any environment. Each of these individual topics is too broad to cover in depth here, but you should be able to get started with minimal knowledge of each.
To give you an example of how simple it can be, here is a sample command line build that will deploy a website to a 2003/IIS6 box.
MSBUILD "MyWebSite.csproj"
/p:Configuration=Dev
/p:OutputPath=bin
/t:Rebuild
/p:DeployOnBuild=true
/p:DeployTarget=MSDeployPublish
/P:AllowUntrustedCertificate=True
/p:MSDeployPublishMethod=RemoteAgent
/p:MsDeployServiceUrl=http://MyDevServer
/p:DeployIisAppPath="Default Web Site/MyWebSite"
/p:username=deployUser
/p:password=deployPassword
I have a website with lots of files using team build and deploying though web deploy packages. The problem i am having is that the packages are build from one of the machines from the farm and the time stamp will not always match. By default with web deploy that means a full site roll and with so many file and the sync across the cluster this is not optimal.
With cmd line deploy i can pass -UseCheckSum and this is solved for manual deployment. Now i'm trying to use a CI build with auto deploy and passing MSbuild arguments though my build setup. Is there a way to get this to deploy in the same manner?
You can't do it in your MSBuild, but you can edit the Microsoft.Web.Publishing.targets file on the build server to apply -UseChecksum.
See my answer here: https://stackoverflow.com/a/13863041/8037
UPDATE: MS has added the ability to pass the UseChecksum flag to VS 2013. To do this, add the following property to the .pubxml file:
<MSDeployUseChecksum>true</MSDeployUseChecksum>
Further information can be found here: http://blogs.msdn.com/b/webdev/archive/2013/10/30/web-publishing-updates-for-app-offline-and-usechecksum.aspx
If, by "MSBuild" you mean the Web Publishing Pipeline, then the answer is no. The MSDeploy msbuild task supports a UseChecksum property, but the WPP targets provide no mechanism through which you can set it. This is also true of a number of other features (like stored credentials).
We've got an Asp.Net web application we're trying to get pseudo-deployed to a folder, and I'm starting to think Microsoft are crazy -- why is it so hard to get a WAP to do a "Local FileSystem" deploy as part of MSBuild?
I can build with this:
msbuild .\SubSite.csproj "/p:Platform=AnyCPU;Configuration=Release" /t:Package
And get a nice package.zip which I can deploy to a website...
However, I have two projects in my solution, which I need to combine before I ship them, so I want to deploy both packages into a folder, and then re-package that folder. Despite the documentation on technet to the contrary, it doesn't seem to be possible to do:
msdeploy -verb:sync -source:package=.\SubSite.zip -dest:contentPath=.\Www\SubSite
Because you get the error:
Source (sitemanifest) and destination (contentPath) are not compatible for the given operation.
Does anyone have a suggestion of how I could web deploy two sites inside one another without manually copying files out of a "PackageTmp" folder? I mean, I'm aware that I could just skip zipping the package and manually copy the files out to do this, but I'm not happy about having to create a custom target, and there's no other way to find that just to do something that should be built in.
We did eventually figure out how to do this, but I'm not really happy about it ;-)
Basically, (as mentioned elsewhere on so), you can call msbuild with the target set to _WPPCopyWebApplication. You can also specify/override the WebProjectOutputDir property when you do that. Something like this (where ${name} are variables we're using)
msbuild ${SourcePath}\Www\UI\UI.csproj "/p:Platform=AnyCPU;Configuration=Release;WebProjectOutputDir=${OutputPath}\AppRoot" "/t:_WPPCopyWebApplication"
msbuild ${SourcePath}\Www\Mobile\Mobile.csproj "/p:Platform=AnyCPU;Configuration=Release;WebProjectOutputDir=${OutputPath}\AppRoot\Mobile" "/t:_WPPCopyWebApplication"
msbuild ${SourcePath}\Www\Service\WebService.csproj "/p:Platform=AnyCPU;Configuration=Release;WebProjectOutputDir=${OutputPath}\AppRoot\WebServices" "/t:_WPPCopyWebApplication"
We can then package up the whole "AppRoot" in a separate step.