While I was at Microsoft last week at an IIS 7 event I ran into Scott Guthrie, who was just bubbling over to show me an add-on tool that will be shipping as VS.NET 2005 is released. You may have seen my previous Blog posts regarding the difficulty in creating repeatable deployment configurations and in general managing the deployment issues and I’ve been bitching about it for a while (here and here and here), trying to get Microsoft to change it. Basically the built-in project compiler options do not allow for a compact repeatable build of a project, so it becomes difficult to deploy a project quickly and manage the updated files on the server. This has a number of side effects like projects need to go offline for updates because if you’re copying many files the project can get out of sync.

 

Well the stock behavior won’t get changed but apparently Microsoft has recognized the issue. Scott showed a new tool that addresses this particular issue. The tool is basically a new project type that acts as an Über-ASP.NET project which you can add it to your VS.NET Solution as a separate project. The job of this project type is to control the compilation of your ASP.NET project with a number of options that are not natively available in the ASP.NET compiler.

Single Assembly Compilation and Repeatable Compiles

One of the really nice options is the ability to compile the entire Web application into a single assembly with a fixed name! Yeah!!!! Other compilation options include the ability to create one assembly per directory – again with fixed and repeatable names, so now it becomes much easier to distribute your Web app to the server by writing a simple FTP script or simply dragging and dropping known files. From an operational point of view this addresses one of the more unpleasant surprises that ASP.NET 2.0 brings and I’m really glad Microsoft decided to address this issue.

File Inclusions/Exclusions and custom Web.Config settings

The tool does a lot more than this though. The tool is a project file/MSBUILD script and you can use it to control a number of other options such as which files get included in builds and what to exclude. This is pretty important too if you have stuff in folders that are temporary – you don’t want this stuff moved to your deployment folders. You can select the files you want to deploy or automatically pull everything.

 

Another important feature is the ability to inject XML into Web.Config depending on which build configuration you are using. This is a big issue with complete deployments direct to the server as you rarely can deploy a development config directly to the server. Usually your Config settings vary between dev and live installations. The tool allows you to create custom XML that gets injected into Web.Config.

 

The thing has UI associated with it so it’s easy to use. But it’s also project file and MSBuild script so you can hook into the logic and perform additional operations such as before and after build actions. Again this is handy so you can customize the output that gets dumped into the output directory by copying and deleting files and/or even executing your own code externally to perform additional build operations. With all of this it becomes possible much more easily to create a fully automated install without having to write your own MSBUILD scripts to do it.

Development and Deployment Modes

During development you can set the project to Debug mode and disable the project from building. Switch to Release Mode and build the Solution and it will recompile everything and go right on to deploy into a directory. I don’t remember if there’s an option to publish directly to an FTP site.


I’m rattling of things here from memory and of course it was Scott demo’ing things, so it all looks ultra-smooth <g>. I spent a bit grilling him about a few issues I’ve had and best as I can remember this tool addresses all of them from the deployment perspective. Deployment’s been a thorn in my side for the 3 apps I’ve ported to 2.0 and moved onto my server and this seems to fit the bill perfectly.

 

Of course, I have nothing in hand – Microsoft is already off to RTM builds that won’t run on our RC builds, so no pre-trials. We’ll have to wait it out…

 

All I kept thinking while I was seeing Scott run through the demo was: Why the heck didn’t this go into the box? According to Scott, nobody complained about the project manager and deployment until Beta 2. Not surprising I guess – prior to a Go-Live license most people dabble and won’t be spending much time with deploying their applications… So, by the time this came to be it was too late to get it in the box. Apparently, it will be pushed onto the VS.NET Home Page, so hopefully most people will see and download it right away. One good thing about an external tool is that it’s not part of the Vs.NET product cycle so it can be updated much quicker. I’m sure once people start to play with it in the real world there are going to be issues and other opportunities that can be rolled into it.