We recently ran into an issue concernig an Automatic Security update for Windows 2003 and WSS 3.0.  The customer's SharePoint site became inoperative and displayed a 'Cannot connect to the configuration database' error.  The server Application Log showed a Windows SharePoint Services error of 'Unkown SQL Exception 33002' - 'Access to module dbo.proc_getObjectsByClass is blocked because the signature is not valid.'  Turns out that this was caused by a security update for Windows SharePoint 3.0 reference KB934525.  If this patch is applied you have to run psconfig -cmd upgrade -inplace b2b. This utility can found under Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Bin .  Please reference KB934525.

Ron

One technique we've started using is automating our apps' configuration using Pre-Build Events and Build Configurations in Visual Studio.  It takes a little more work to set up, but once you do, publishing test and production apps is much easier.  It also helps the developer to think not just about a "works on my machine" app, but an app that works on any number of scenarios.  Without this approach, the developer still has to keep up with multiple config files, but typically does so in their head. Scott Guthrie has a great post showing how all this is done.  However, a few tips will help you fine tune your automation, so that development is even more painless:

• Decide the different scenarios your app will run in.  In our case there are typically 3:
  • Local - App is being developed and running on the developers' PC
  • Staging - App is being tested in a copy of the production environment
  • Production - App is "live".
• Create a folder named Configuration.
• Create a .config file for each scenario above.
  • Name the .config file scenario.web.config or scenario.app.config (ie local.web.config).  Using this approach over Scott's means you still get intellisense in the .config files!
  • If you have an existing .config file, just copy it to the Configuration folder and rename it as above.  Remember that after this is set up, the "real" .config file will be overwritten.  If you put blank .config files in Configuration, you'll loose the "real" configuration file.
• Create Build Configurations in Configuration Manager for each scenario above. 
  • In each configuration, add the following Pre-Build event

  • IF EXIST "$(ProjectDir)Configuration\$(ConfigurationName).web.config" xcopy "$(ProjectDir)Configuration\$(ConfigurationName).web.config" "$(ProjectDir)\web.config" /Y /R

  • This script accomodates the naming schema above, and works with source control by overwritting the read-only .config file. Note if your project is a windows forms, console, or class library app, change "web.config" to "app.config"

And that's it - before each build, the appropriate config file will be copied over and used.  Note that you'll never want to change the .config file in your project's root, as it will be overwritten.  Instead, whenever you need to change configuration, decide how the change will affect each scenario, and change each .config in your Configuration folder.