One MORE gotcha with Web Deployment Projects

Hopefully this is the last ‘gotcha’ for the Visual Studio Web Deployment Projects.  We were trying to setting the system.net/mailSettings in the web.config file, and were trying to do the config section replacement on it.  Unfortunately, the Web Deployment Project didn’t like replacing that section.  So, we had to use the smtp section insid of the mailSettings.

 

Here’s the code from the Deployment section of the Web Deployment project:

system.net/mailSettings/smtp=ConfigurationsQAsmtp.config;

 

And, here’s the SMTP section used to do replacements:

 

<smtp>
  <network
    host="hostname"
    userName="emailUserLogin"
    password="emailUserPassword"/>
</smtp>

I hope that helps somebody!

I waxed poetic a little too soon on Web Deployment Projects

So, yesterday’s rosy blog about the Web Deployment Projects was written 24 hours too soon.  I had not done one small, critical step.  I had not tried to build with our team build server, Team Foundation Server Build.  One would think that because Microsoft wrote all of the products, it should all play nicely.  Well, to make a VERY long story short, it didn’t…

 

When we tried running the build project on TFS Build, we ran into the dreaded "error ASPPARSE: Could not load type ‘blah’" error.  "It built fine on my machine, honest!"   There is some information, but most of it is dealing with either Visual Studio 2005, Web Site Projects, or MSBuild 1.0.  We are using Visual Studio 2008, Web Application Projects and MSBuild 2.0, so most of the things that were found were not pertinent.  After a lot of trial and error (and error and error…) I finally decided to try a solution that didn’t look like it would actually help.  Here’s the ASP.NET forum discussion where that was found.  It turns out that we needed to make the change to the SourceWebPhysicalPath element.  Why?  I have no idea.  My only guess is that we keep our apps in a sub directory of the solution.  I think that confuses the compiler.  Oh well.  It worked.  Just 24 hours AFTER I thought I was done…

 

Here’s the change that was needed to the .wbproj file

Old SourceWebPhysicalPath:

<SourceWebPhysicalPath>..WebApplication1</SourceWebPhysicalPath>

 

Replace with:

<SourceWebPhysicalPath Condition="’$(OutDir)’ != ‘$(OutputPath)’">$(OutDir)_PublishedWebsitesWebApplication1</SourceWebPhysicalPath>
<SourceWebPhysicalPath Condition="’$(OutDir)’ == ‘$(OutputPath)’">..WebApplication1</SourceWebPhysicalPath>

 

Now everything builds correctly!

 

Visual Studio 2008 Web Deployment Projects are cool (and have some gotchas!)

Let’s kick the blogging back off with a bang…  Back to programming…

Lately, I’ve had a heck of a time trying to create decent deployment projects for web projects in Visual Studio 2008.  We use Team Foundation Server to do our build, but for some reason, it doesn’t copy all of the files in the web project to the drop location for deployment.  Things like PDFs and other documents that are part of the system do not get put in the drop directory at all.  I do NOT feel like creating scripts for all of the ‘extra’ files, especially since they can change with any given release (yes, I know that it’s not the solution one should use, but finding 10 minutes to do anything lately is tough). 

The other, much bigger problem is that we have when deploying our sites is the web and library configurations for each stage of deployment.  I had written a script with a tool called ‘Automise’ but trying to get that thing to work completely frazzled me.  The idea is cool, but to subdivide the projects caused the variables to get completely unmanageable.

There has got to be a better way to handle deployments than this!

Well, today I found a fairly decent way to build my deployments.  I had seen the Visual Studio 2008 Web Deployment Projects on Scott Guthrie’s blog, but really hadn’t paid attention to the add-on.  It seemed ‘overly simple’.  Turns out ‘overly simple’ was exactly what I needed!

The Visual Studio Web Deployment Projects solved both problems VERY handily.  First off, it copied the site CORRECTLY to a drop location.  No more, ‘the PDF didn’t get updated!’ to worry about.  The other part is that the deployment project handles building the web config file fairly cleanly.  In fact, the web config handling is what prodded me to get off my rear and actually write a bit!

There are a couple of tricks that make the web config MUCH smoother.  One of them is how the settings can be created.  The Web Deployment project can replace any section of the web config with a section in a file that is specified.  To set the section to be replaced and the name of the file with the section TO replace it, you go to the Web Deployment Project’s properties and go to the Deployment item in the tree.  There you can set the ‘Enable Web.config file section replacement’. 

The format for specifying the section of the web.config to be replaced by a file is: section=filename;  It’s not mentioned anywhere, but you can get to the subsections by going section/subsection.  This is very useful for setting the library sections of applicationSettings.  We use applicationSettings/CompanyName.Bll and applicationSettings/CompanyName.Dal to replace the BLL and DAL library settings.  I don’t know how far into the sub sections one can get, but just being able to get to the subsection helps.

Unfortunately, the files for the config replacement cannot be part of the Web Deployment project.  To me, that would be a logical place for them.  What we did find, though, was that the files can be put into the Web Applications directory!  If you specify just a filename in the section=filename setting, filename will be found in the root directory of the web project.  It is easy to specify sub directories by going section=subdirectoryfilename.  We ended up creating ConfigurationsBuildTypes subdirectories in the web project.

This makes it FAR easier to deploy.  Plus, the Web Deployment Project has some MSBuild tasks that should make it fairly easy to send the projects directly to our servers.

Pretty cool, eh?