I’ve spent the better part of a day now wrestling with web deployment projects, and I am ready to conclude that they are too rigid to be useful for practical scenarios.  Here’s what I wanted to do:

• Create a directory structure for my web app and all its dependencies.  This means not just the folder for the virtual directory, but a folder for log files, a folder for the DAL plug-in, a folder for scripts, and a folder for misc. other things.
• Compile my web app, copying all the necessary ASP.NET files and DLLs to a folder in the directory structure I created.
• Move (manually for now) this directory structure to production.
• Drop in the necessary resource files and other config changes.
• Actually use the web app without it exploding.

That last part is where things went wrong.  Not only could I not use my web app, but it did actually explode in a mess of "You can’t have an App_GlobalResources folder!" and "I found ProfileCommon in two DLLs because I’m st00pid!"  Fun, fun.  Turns out all this headache is caused by how Web Deployment Projects do the precompile.  Even if I tell it that I want the site to be updatable, it still won’t let me change something as simple as my resource files.  I also can’t change App_Code (doesn’t happen often, but we have dropped hotfixes in to production from time to time).

I tried to fix things by editing the WDP’s MSBuild script, but that was an epic failure.  The thing exposes a few points for you to extend, but they’re nothing more than pre/post build events.  I can’t actually fix it no matter what combination of settings I try, either.

Instead, I’m going to just create my own MSBuild script to do all this from scratch.  In the end, I think it will be much less painful.  Check back on Monday for the first part of the script.

PS: No new "How to run a software development company (INTO THE GROUND)" this week, sorry!  I’ve got plenty of things I *could* say on the topic, but they’re less on the funny side and more on the sad, depressing side and not very entertaining.