Tuesday, July 20, 2004

Two Quick .NET Tips for Smoother Team Development

While doing some work with Dan the other day, we both ended up showing each other a hidden .NET feature that, although they both had existed since .NET's release, the other party was unaware of. Given the general usefulness of the features (especially in a team environment), I thought them worthy of a quick post.


Nick's Tip - Config File Overrides


It is not uncommon in team situations for the config file to become a real source of contention, with developers checking in changes that are only relevant for their PC. Also common is the the config file thrashing between test and staging server settings. To avoid this problem, it is possible to locally override appSettings settings in the config file by using the file attribute of appSettings element. The app.config or web.config file that lives in VSS would look something like:


<?xml version="1.0" encoding="utf-8" ?>
<configuration>
 <appSettings file="development.config">
  <add key="DBSever" value="Staging Server Name Here" />
</appSettings>
</configuration>


Locally, outside of source control, a developer can (but doesn't have to) create a file called development.config, and override appSettings settings as desired. If this file doesn't exist, the main config file is used. The development.config file would look like:


<appSettings>
 <add key="DBSever" value="Local Server Name Here" />
</appSettings>


That's it for development.config - there is no other elements like configuration in the file.


As an interesting side story, at one (unnamed) telco where I did some performance consulting earlier this year, the connection details to the real database ended up in VSS during the final stages of a deployment, and when contractor did a get latest and ran a cleansing script that is usually run against the test database, a heap of real data was deleted. While most data was recovered from backups, a contractor ended up being sacked, but it ended up being the wrong guy, so the company had to pay out his contract. The morale: pay attention to config file settings!

Dan's Tip - Setting Up Web Projects from VSS for the first time


Getting a web project from VSS and getting it running on a developer box that it was created on is one of the great challenges of the current Visual Studio.NET release. Visual Studio will attempt to add the file to a folder in the c:\inetpub\wwwroot folder if you simply do a get latest and open a solution containing a web project. This will upset relative references, and is pretty untidy, as you end up with two copies of the files on disk, and two folder where VSS is putting files. To avoid this, do a get latest, map the web folder into ISS with the same vdir name as the original developer used, and then delete the files from the mapped folder. The last stage is critical (and was the missing link that Dan provided) as, if the files do exist, VS will attempt to create a new vdir with an "_1" appended to it, and with the file going to c:\inetpub\wwwroot. Thankfully, Whidbey fixes this problem completely.

1 Comments:

At July 23, 2004 at 3:51 PM, Blogger Chris said...

This mechansim doesn't allow you to deal with Custom Configuration Section Handlers. The way that we have down it is to create a "environment" custom configuration section handler that allows you to have a section in your configuration file that is specific to a machine.

eg.
>environmentmanager<
>environment machine="MyDevMachine"<

Any setting you want
>/environment<

>/environmentmanager<

 

Post a Comment

<< Home