Is there a way to automatically Zip/archive the entire solution after I right click on the project file and click "Publish"?
I've ran into some issue trying to revert to previous versions of my application because I forgot to check everything in after a publish. And someimtes TFS is tricky to get a snapshot of the app at a given date. Having a ZIP archive of each time there was a publish or build would be very beneficial.
If you are building a Web application, your website project should have a tab where you can set the "Package/Publish Web" settings for different build configurations. This should allow you to generate ZIP packages when building.
For the standard 'Debug' build that most developer's use on their machine, you won't want this on, but you might want to configure it for other build configurations.
Some good MSDN reads on the topic are:
ASP.NET Web Application Project Deployment Overview
How to: Create an Automated Build and Deployment Solution with Team Foundation Server Team Build
Common practice is to do that on build server side. Any continuous integration system allows to perform actions on successful build. Not a good practice to increase build time on developer's machine, because it would affect productivity.
Related
Currently, I'm maintaining an older ASP.NET website. In the solution, there exists 5 C# projects which build to assemblies as well as the development server's web directory. Normally, I do whatever work needs to be done (adding pages, making changes to existing projects, etc), build the projects (the current output path is my development server's wwwroot\bin\ directory) and if all is well, I open Windows Explorer and drag either .aspx or .dll files from the dev server to the production server. It's that last step that I'm wondering if there is a better way of doing. Does anyone have a different way of doing things where you don't have to leave Visual Studio to push updates?
You should add a Web Deployment Project, that´s (in my opinion) the easiest/best way to deploy a Asp.net app
Here´s an interesting article from the MSDN Magazine. http://msdn.microsoft.com/en-us/magazine/cc163448.aspx
ASP.NET Web Site Precompilation Overview would seem to be what you are wanting, yes?
Otherwise, there are web deployment projects for VS 2005 and web deployment projects for VS 2008 if you want a couple of alternatives depending on which version of Visual Studio you use.
How old is older? Are you using ASP.Net 1.0, 1.1, or 2.0, as those are what I'd consider older, but then I've been doing web development for over a decade.
You might want to consider creating a build script and a deployment script. You can look at using either Nant or MS Build, which are popular, or simply go with a batch file approach.
Some of the reasons I suggest going with scripts are:
1. You'll never forget to push that one file that you added
2. Either your build script or your deploy script should create a copy of all the artifacts need for deployment. This way, if you push out a bad build and need to roll back for whatever reason, guess what, you have a working copy tucked away somewhere.
3. Your scripts can run the installers (if you created a setup project) or they can simply copy out the files to the correct location, so that you don't have to have your dev box pointing to the right folder.
4. Sometimes you need to make changes to the configuration before you deploy... your scripts can also do this for you.
In general automating the whole process just makes it easier, faster and repeatable.
Currently we deploy compiled ASP.Net applications by publishing the web site locally and emailing a zip file to the system administrator with a (usually) lengthy set of instructions for deployment. This is because the first time we deployed an ASP.Net application to a customer the dev and test IIS instance were the same, and we were unable to deploy the site twice to the same machine. This set the tone for deployment on all subsequent projects.
I am now evaluating our deployment methods and am looking specifically at the built in deployment tools; specifically I'm looking at custom installation tasks and using as much of the standard installer functionality as I can (mostly the user interface).
Secondly, I'm looking at merging deployments and automatic updates.
How do you go about deploying sofware in your organisation? What tools do you use, and what problems do you come across most frequently?
We have dedicated DEV, TEST, STAGE, and PRODUCTION servers.
We also have a dedicated build machine which runs Cruise Control.
Cruise Control is configured for a Continuous Integration build, which runs after code is checked in. It is also configured for separate Development, QA, Stage, and Production tasks.
To deploy to development, the code is first retrieved from SVN and built, then the "Precompiled Web" folder is copied to the development web site, and the web service project is copied to the development application server. Cruise Control is also configured to "tag" the source code before the build starts so we can reproduce the build at a later time, or branch from the tag if we need to do a hot fix.
To deploy to QA, the files are copied from the development machines to the QA machines.
Likewise, to deploy to Stage the files are copied from the QA machines to the Stage machines.
Finally, to deploy to production, the files are again copied from the Stage machines to the Production machines.
To configure each environment, we have a custom tool which is part of each environment's Cruise Control task that modifies connection strings, "debug=true|false", "customErrors=Off|RemoteOnly", and other environment-specific settings.
So each environment can be deployed with a button push from the Cruise Control dashboard.
One caveat is that we currently have the production database password configured in the Cruise Control config file...it would be nice move it elsewhere!
Lastly, let me add that even though our production machines are in a dedicated hosting facility, the servers are accessible from our Cruise Control machine, which makes it very easy to do a production deployment. The only manual step is to encrypt the web.config files and remove the "AppOffline.html" file that Cruise Control puts up.
Let me know if this helps, or if you have any questions.
Thanks!
A couple things that I have done is the following:
1) Use a Web Deployment Project in order to compile and clean the build as well as handing web.config section replacement if the config changes between environments.
2) Use NAnt to do all of the building, archiving, and copying in a repetitive manner.
The Web Deployment Project ends up creating a MSBuild file which can be used in place of NAnt; however, I came from a Java background and used Ant all of the time so NAnt is my preference in .Net. If you add in the NAnt Contrib tasks, you will be able to deploy not only the files but also handle items such as your source control (incase it is not part of the default tasks) and Sql Script Execution for changes.
Currently I use both of the options together. I have my NAnt build file call the Web Deployment Project through MSBuild. With the configuration manager setup for each environment, it allows me to manage the web.config section replacements automatically and still have fairly decent control over my copying and archiving of a release.
Hope this helps.
We use web deployment projects, and the VS 2008 projects to create an .msi from the output of the webdeployment & other projects. A normal windows app called 'setup' is used to do a lot of the db creation and preliminary stuff, rather than trying to customise the setup projects with custom steps. It is a lot easier to do this yourself than trying to customise the MS code. This windows app then calls the correct .msi files that the user needs.
Team foundation build runs every evening to rebuild the solution and copy everything to a 'Release CD' directory which anyone can access and do testing on the latest 'release'.
To be honest TFS build is a bit overboard for a small team like ours, and I only use it because its what I am used to.
In a previous company we used this http://www.finalbuilder.com/ and I can recommend it for ease of use and for the amount of software supported.
1) Build project with MSBUILD
2) FTP files to Production Environment
3) Copy / Paste manually to each web server
For intranet sites, we use CruiseControl in conjunction with SVN to have the site rebuilt automagically.
Theoretically you could extend this model over a VPN if you could map a drive remotely to a client's intranet. Or a more quick and dirty solution might be to use a tool like SyncBack to sync the remote folder containing the compiled DLLs for the site.
Deploy Web Applications Using the Copy Web Tool
Text from Microsoft Training Kit Book Web Based Development
Web Setup Projects are useful if you are providing a Web application to many users (for example, allowing people to download the application from the Web and install it). If you are responsible for updating a specific Web site for your organization, it’s impractical to log on to the Web server and install a Windows Installer package each time you make an update. For internal applications, you can edit the Web application directly on the Web server. However, changes you make are immediately implemented in your production Web application, and this includes any bugs that might be there. To enable yourself to test a Web application, you can edit a local copy of the Web application on your computer and publish changes to the production Web server using the Copy Web tool. You can also use the Copy Web tool to publish changes from a staging server to a production Web server, or between any two Web servers. The Copy Web tool can copy individual files or an entire Web site to or from a source Web site and a remote Web site. You can also choose to synchronize files, which involves copying only changed files and detecting possible versioning conflicts in which the same file on both the source and remote site have been separately edited. The Copy Web tool cannot merge changes within a single file; only complete files can be copied.
Does Microsoft offer a tool where you can deploy a web application to multiple web servers in a load-balanced environment/web farm?
My team is looking for a tool, preferably from Microsoft, where we can deploy our web application from development environment to production environment automatically.
If I understanding what your asking for your looking for a build server, to my knowledge Microsoft don't offer one, but some to take a look at are Team City, Hudson(requires a plug-in), and CruiseControl.net.
Basically they work by pulling from your source control building your application and running your tests. They all support scripting that will allow you to build then deploy to your servers. This can be set up to run nightly, weekly, etc. you can also set it up to monitor your source control for changes and build anytime it sees a change
The only one I've used is Team City, the install was easy, and depending on how many build agents you need it's free.
If your just looking to build and deploy from VS Another option is creating an NAnt script and running it from VS as an external tool.
For a good over view of Build servers check out this SOF question cruisecontrol.net vs teamcity for continuous integration
The Web Deployment Team blog at Microsoft has some reasonably useful information, and have a deployment tool you could try...
In the last environment we setup we used TeamCity for all our builds and deployments (Which is basically to say we wrote MSBuild scripts and automated them with TeamCity). In short we had the following 5 build configurations:
Continuous Build - Automatically rebuilt our product upon every check-in. Running all the tests. This build did not deploy anywhere
Nightly Build (Dev) - Automatically build and deployed our product to the development web server (no server farm). We build would run the tests, update the development database, shutdown the Dev IIS web site, copy the necessary files to our web server, and restart the site
Test Build - Like our Nightly build only it deployed to our test environment and it wasn't scheduled so it had to be manually started by logging into Team City and pressing a button
Stage Build - Like test only deployed to a web server that was externally visible to our customers sot that they could validate the application. Also, only run on demand.
Production - Created a zip file of our product that the deployment team could install on our production web servers
So I guess what I'm suggesting is that you use TeamCity and then write build scripts in such a way that they'll deploy to your Web Farm. If you want examples I could supply you with the pertinent portions of our build scripts
** One more thing: we check in our web.config files and such for each environment into subversion and then part of the build process is to copy and rename the appropriate config file for the environment. For example, web.prod.config => web.config in our production build
I believe that Sharepoint does this.
File Replication Service ( e.g. DFS Replication ) is a typical and very good choice for doing this.
Your changes are synced between member servers at the file system level.
Sharepoint does this automatically when you deploy a solution package.
what is the preferred method of deploying a web project? Just copy the dll's after compiling in release mode and registering them? or using NSIS to build an installer or the MS set up project.
I usually use a Web Deployment Project per WebSite or WebApplication, it allows me to manage build configurations, merging, and define pre-post build MSBuild tasks.
You can also take a look to the Microsoft Web Application Installer, it will be really nice, but it still in beta stage, however you can try it...
This depends greatly on where your webapp is going and the experience you wish to provide.
If you deploy to a web host its best to use xcopy deploy and documentation. If you have a real end system its simpler to create an installer to do all the leg work for your customers and maybe save your self some documentation work.
I would recommend investing in setting up a continuous integration process (CruiseControl.Net or TeamCity etc...) As you are probably not only going to deploy it to your customer only once.
Having an automatic deploy at the push of a button is a Godsend. If you invest a few days you can have automatic deploy to a dev-environment every time someone checks in code (and it compiles and all tests pass), set up daily deploys to a test environment and have a button to automatically deploy it to a staging environment whenever you want.
Andreas, I am in the process of getting CC.Net. In the meanwhile, I am using the Web Deployment Project. Using this and going through the set up, it creates a 'release' folder with a bin folder conntaining dll's and also the aspx in the parent folder.
I assume I can now create an MSI file using the 'release' folder or do i need to do something different to create an MSI which i can run on the client server
When I build my ASP.NET web application I get a .dll file with the code for the website in it (which is great) but the website also needs all the .aspx files and friends, and these need to be placed in the correct directory structure. How can I get this all in one directory as the result of each build? Trying to pick the right files out of the source directory is a pain.
The end result should be xcopy deployable.
Update: I don't want to have to manually use the Publish command which I'm aware of. I want the full set of files required by the application to be the build output - this means I also get the full set of files in one place from running MSBuild.
One solution appears to be Web Deployment Projects (WDPs), an add-on for Visual Studio (and msbuild) available that builds a web project to a directory and can optionally merge assemblies and alter the web.config file. The output of building a WDP is all the files necessary to deploy the site in one directory.
More information about Web Deployment Projects:
Announcement on webdevtools MSDN blog for WDP 2008
ScottGu introduction to WDP 2005
The only disadvantage to this solution is the requirement on an add-on which must be available on the build machine. Still, it's good enough for now!
ASP.NET doesn't have real xcopy deployment for new sites. It depends on having a virtual directory/Application in IIS. However, once that virtual directory is created you can use xcopy for updates.
You can Publish Web site..If you want to automate your deployment, you need to use some script.
Have you tried using the aspnet_compiler.exe in your .net framework directory? I'm pretty sure you can create a "deploy ready" version of a web application or web site.
The _CopyWebApplication target on MSBuild will do exactly what you need. The catch is that only the main assembly will be copied to the bin folder and that's why a copy task is needed to also copy any other file on the bin folder.
I was trying to post the sample script as part of this post but wasn't able to.
Please take a look at this article on my blog that describes how to create a MSBuild script similar to the one you need.
Have you tried right clicking the website in Solution Explorer and clicking 'Publish Website'?
Build --> Publish
A dialog box will appear that will guide you through the process.
For the automated building you describe in the update, I would recommend you look into MSBuild and CruiseControl.NET
It depends on how complicated solution you need, you could just use a script and jenkins for example. You can use MSBUild with Jenkins for just deploying to an IIS. And if you got Jenkins other tools is pretty easy to connect into it later on. But if you just want to build, use a script that jenins execute every build that uses MSDeploy and it will work great.
This is how i do it, just to give you a feeling:
Sonarqube uses Gallio, Gendarme, FXcop, Stylecop, NDepths and PartCover to get your metrics and all this is pretty straight forward since SonarQube do this automatically without much configuration.
Here is Jenkins witch builds and get Sonar metrics and a another job for deploying automatically to IIS. I use a simple script one line that calls my MSBuild and wich URL, pass and user.
And Sonarqube, all metrics for my project. This is a simple MVC4 app, but it works great!:
If you want more information can i provide you with a good guide.
This whole setup uses MSBuild, too build and deploy the apps.