Visual Studio 2005 web site publishing nightmare

During every release, my stress level used to go up 10x. It shoudn't have to be that way. Here are my main deployment issues, with workaounds when applicable.

Did I change my config settings to reflect the production environment?

Not an easy one. Maintaining mutliple web.config files is a pain, so I'm using only one, with development, testing and production settings. I comment them out and uncomment each group of settings (appsetings, connection strings, assembly settings, email ...) depending on the environment. There's still room for user error, so if you have a better solution, please let me know.

I built all code libraries in Release mode, but did I forget to change the Web.Config compilation debug attribute to "false"?

As I have written before, running your app in debug mode can have disastrous effects on bandwidth useage and overall performance if you rely heavily on Webresource.axd as an image and javascript provider. For this reason, I would recommend making the following change to machine.config on the production server - this overrides the debug attribute in web.config:

<configuration>
<system.web>
<deployment retail=”true”/>
</system.web>
</configuration>

Did I include all my license files?

You may have noticed that when publishing a web site in VS 2005, .lic and .licx files don't get copied automatically. This has been a real pain for months - for instance I kept forgetting to include my aspnetemail license; the site would seem to be running fine, but emails would consistently fail. Thankfully, there's a fix! Just edit your web.config compilation settings:

<configuration>
<system.web>
<compilation>
<buildproviders>
<remove extension=".lic">
<add extension=".lic" type="System.Web.Compilation.ForceCopyBuildProvider">
</buildproviders>
</compilation>
</SYSTEM.WEB>
</configuration>


This will force all *.lic files to be copied when publishing/precompiling your site.

Data and logic are out of sync on development and production machines. Some files are newer on the production server (images and docs uploaded by users for example), others are newer on my development machine (webforms, usercontrols, dlls, styles etc...)

Use virtual directories for all resources modified at runtime. This way, you don't have to worry about overwriting new data when deploying a new release.

Applying database changes

Versioning and deploying new code is easy, but what about your database? Personally, I keep a log of all database changes during development. The file is kept in SVN and can be modified by all developers. It looks like this:

- Created view_Catalog
- Updated spCatalogItem_GetDetails
...

Very simple. When we're ready to release, we move production data to the testing server, generate a sql file reflecting all the database changes tracked in the log, run the query on the testing database. If it's successful, we do the same on production.

UI testing

If you're building a tiered application, you're probably writing unit tests as well. That's great, but how do you test the UI? If you're like me and can't afford a QA team, you're the one clicking all over your web app to make sure everything works properly. But every developer hates this, and has a tendency to only test things that are supposed to work.

I started implementing NUnitAsp for critical user interactions (account registration, downloads, credit card purchases...). It works fine when using MS web controls, and it's a first step in the right direction; but if you are using 3rd party UI components, you'll need to write your own testers. Moreover, there's no support for Ajax and javascript... so if you build fancy user interactions, you're out of luck.

One thing to consider is the atlas UpdatePanel. Partial page rendering can be turned on or off easily through the Script Manager; so in theroy you could turn it off, run your UI unit tests, then turn them on on production. This is just an idea though, I haven't tried it yet...

Also, I found this project in SourceForge. On paper, it looks interesting...

Link to NUnitWeb

Consider Web Deployment projects

Web Deployment Projects offer more build options, such as creating a virtual directory, replacing web.config sections, toggle debug compilation setting and more. See my next entry.

Web deployment projects resources:
Microsoft Web Deployment Project resource page

Web Application projects?

Microsoft recently released a template for this new project type. I haven't tried it yet, but apparently it's similar to web app projects in VS 2003. That's nice, it's a much cleaner approach when building an enterprise web application.

Microsoft Web Application Project resource page