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
Related
I am using Visual Studio 2010 to manage a web application. This web application is organised into a number of projects, where the UI itself is one project, and the business logic resides in another assembly which is then set up as a project reference for the UI, and makes calls out to code in third-party libraries.
When I do a deployment build, MSBuild creates the usual _PublishedWebsites folder and copies the web application into there. What it does not do is copy the dependencies of the business layer, which means nasty YSOD when I try to run the application. Now, I can set the third-party libraries as references of the UI project, and that ensures the libraries are copied and deployed as expected - however, that rather misses the point of having the business layer doing all the work, and means additional maintenance in that when another third-party library is added, it needs to be added in more than one place.
How can I ensure, once and for all, that dependencies of my business layer are deployed to the _PublishedWebsites folder when the deployment build is run?
As per my comment to #Shaun Plourde's response, it appears that this scenario is not supported. If you want indirectly-referenced assemblies to appear in the build output, you'll need to reference them directly.
This should just work out of the box with VS.NET. Try setting "Copy local" to true where the dependencies are actually needed. Your UI project should not require any explicit references to those assemblies.
For smaller projects, this may scale fine in terms of compilation performance. For larger projects, you may want to consider alternative approaches such as those outlined in Patrick Smacchia's article at http://www.simple-talk.com/dotnet/.net-framework/partitioning-your-code-base-through-.net-assemblies-and-visual-studio-projects/.
It isn't a perfectly automated solution, but you can solve this with a post-build script on your main project.
I've found that the $(WebProjectOutputDir) variable is managed such that it resolves to the "_PublishedWebsites" directory when you supply an output directory that is not equal to the directory of the project being built. (Otherwise, it is the same as the current project directory.) So, for your problem, you could put this in the post build of your web application:
xcopy /Y /S "$(ProjectDir)..\Your Business Logic Project\bin" "$(WebProjectOutputDir)\bin"
It should work both on your machine and on your build server.
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. :(
I am working to setup a build server using Team City to build and deploy asp.net web applications to a staging site with transformed web.configs automatically. Everything is working except that the code that ends up on the website (the aspx files) have the HTML in them when you open them in notepad.
Before all of this I was using web deployment projects with websites, and the code was compiled. If you opened one after it was deployed, it said it was a marker file.
I have tried some tutorials on how this process should work, but the code always ends up in an editable state (the html).
My question is:
What do I need to do to get MSBUILD from the command line to ultimately have precompiled code on the webs server?
Any suggestions, links, pointers, or ideas would be very helpful to me.
You need to invoke the aspnet_compiler tool to do this. There are some limitations or complications depending on exactly what you need to do for things like strong-naming. The MSDN article here has pointers.
I used to have MSBuild project steps that did this, but we decided to drop precompiling because our clients want to integrate our product into their internal portals, and precompiling made things complicated for them.
Are you using MS Web Deploy? I use it regularly for automated deployments from my Team City Build server to dev, staging, QA, etc. And I'm transforming configurations as well.
If you want to check out this alternative you can follow the excellent guide by Troy Hunt:
http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_26.html
I have a solution with a fair few projects, 3 of them web-based (WCF in IIS / MVC site). When the solution builds, it dumps each of the components of this distributed system in a 'Build' folder. Running the 'configurator' part of the whole output will set up the system in the cloud automatically. It's very neat :) However, the Web Deploy Projects are a major pain. They "build" (i.e. deploy) every, single, time I build - even when no changes have been made to their respective projects.
Changed a single line of code? Look forward to waiting around a minute for the 3 web projects to redeploy.
[These projects are VERY straightforward at the moment - two have a single .svc and one .ashx file - the other is an MVC app with ~5 views]
I realise I can change solution configurations to not 'build' them, but I've been doing that and it's very easy to log on the next day and forget about it, and spend a couple of hours tracking down bugs in distributed systems due to something simply having not been built.
Why I use Web Deploy Projects? Well, because I need all pages + binaries from the web project. The build output for the project itself is the 'bin' folder, so no pages. The entire project folder? It has .cs, .csproj and other files I don't want included.
This will be building on build servers eventually, but it's local at the moment. But I want a quick way of getting the actual output files from the web project to my target folder. Any ideas?
Not sure if this will help in your situation, (plug for own project coming up), but I am working on a project to help ease IIS deployments:
https://github.com/twistedtwig/AutomatedDeployments
The idea being you can use config files for IIS (app Pool, applications and websites) to automate the creation and update of sites locally (dev machines) or remotely (test and production machines).
It is still a work in progress but is ready to be used in production systems.
using the package creation as a post build step might get you closer to what you want, (don't believe it includes all the extra files), but that would still build it each time, (although if code hasn't changed it should not rebuild unless you choose rebuild all projects).
In the end I created a utility/tool which, given a project file, XCOPYies the project folder for the web project to a target location, then looks in said project file and deletes anything that doesn't have Build Action set to Content. Very quick and effective.
I know it is still in RC but VS2012 does have a neat feature when doing publish that it detects the changes and publishes only those. Might be something a little deeper down in the build where it does an automatic publish too.
You can take a look to the Octopus project: http://octopusdeploy.com/
Deployment based on nuget packages.
My team builds reusable libraries for other (internal) software development teams. We use FlexBuilder 3 as our development environment. Our SCM standards state that these projects must include test harnesses and a unit test runner, and (of course) we want to be able to use the debugger. For that reason, all the projects are Applications.
Our build scripts (used primarily by the CI system and for release deployment) build our actual libraries which works great. This approach is used so that FlexBuilder is not required to actually build our production artifacts (on the command line).
The problem is this - in order to have add a FlexBuilder Project to the Library Path for an Application it must be a Library Project. I have tried adding a nature to the project that we want included, but haven't gotten it to work yet. You would want to do that if you wanted to debug source files in another project.
A simple (yet annoying) work around is to include the source folder of the "library project" as a source folder in the "application project." It's annoying because it takes multiple steps to swap between a swc of the "library project" and the source folder of the project itself.
I would also suggest breaking this up into 2 projects. Have 1 library project and 1 application for the tests and the testrunner.
On a sidenote: FlexBuilder 4 will have support for running FlexUnit tests in the IDE, for both Flex applications and Flex library projects. So you won't have to maintain an application just for the sake of running the tests.
Assuming it is possible, I'd suggest adjusting your SCM standards to allow test harnesses and unit test runners to exist in other projects. Simply mandate that any library project must include a companion test project.
I don't know that this is going to make it any easier, but I would actually make the library and the testing harness seperate projects. This would allow you to source control each and would solve your problem with flexbuilder. Its not going to make it easier to work with, but it will be cleaner and the easiest to update.
I didn't totally understand the description of your situation, but if it's helpful, I'll describe how we have organized our Flex projects. The majority of our application code is contained within a SWC ("library") project. We then create two SWF ("application") projects - a "shell" application which represents the final output SWF, and a test harness FlexUnit 2 application. Both of these SWF projects reference the SWC project using a source path. Using this approach has made it trivial to enable unit testing for the application codebase in the SWC.