views:

56

answers:

3

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?

+1  A: 

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.

JB King
Well, older as it was initially 1.1, but I recently (a few weeks ago) converted the project to 3.5. So far, so good.
lush
Also, reading the provided links. Thank you.
lush
+3  A: 

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

sebastian
Thanks for this, reading now.
lush
A: 

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.

TskTsk