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.

I sat for hours in Design 101 trying to get a even coats of cadmium red, cadmium yellow medium hue, and pthalo blue acrylic and their various combinations in perfect circles to learn the basics of complementary colors and other ins and outs of color theory.  Now several years later, it all comes back to haunt me with Adobe's Kuler.  I've seen several for-pay downloadable apps to do this, but Kuler is free and web-based (Flash).  Simply pick from a library of pallets or generate your own using a variety of color relationships.  Use with Firebug for quickly knocking out CSS color schemes.

FireBug is an amazing web development plugin for FireFox.  Like Web Developer Plugin, it lets you tweak HTML, CSS, and JavaScript on the fly.  However, it also bakes in features like visualizations to make sense of CSS and deeply nested elements easily.  It also gives you a nice drill-down report of network traffic, so you can see exactly how much each element contributes to the total page size, which is great when you're trying to trim those extra Kb off your pages.  The UI is very well thought out and easy to understand. 

Hang on to Web Developer Plugin for the validation features, but this is definitely a must have for your web development toolbox.

http://www.getfirebug.com/

One of the more exciting things going on in the Microsoft development world is the upcoming release of Silverlight.  Silverlight is (or soon will be) Microsoft's answer to Adobe's Flash and Flex products.  Silverlight technology is powered by the .NET framework in the form of a trimmed-down CLR (CoreCLR) that runs on both Windows and Mac -- Scott Hanselman has a pretty good summary of the product and its associated jargon here.
Based on the early examples, I think Silverlight will quickly achieve the ubiquity that Flash has enjoyed; hopefully it will stir the interest of .NET developers who have avoided Flash in the past and drive the development of some really useful applications.  There's also a good DotNetRocks podcast available in which Brad Abrams discusses the philosophy behind Silverlight and gives some glimpses of its future direction.

See the difference between these two icons?  Me neither, but the one on the right has about an 8% smaller file size. Portable Network Graphics (PNG) is quickly becoming the prefered format for web graphics.  It supports alpha transparency for nice blendy graphics (now in most browsers), and has amazingly small file sizes.  But those small file sizes can be made even smaller thanks to some custom compression tricks and pulling out unneeded data.  PNGOUT is a great little command-line utility for doing just that. 

Since it's a command line app, it can be integrated easily into your build process to automatically compress any PNG files in your images folder, so that no matter where your PNGs come from, you can ensure they take up as little bandwidth as possible.

ASP.NET Health Monitoring is one of the more under-hyped features of ASP.NET.  It is a rich, flexible logging framework that can be used to log application events in a database, flat file, email, or custom source.  However, JavaScript errors, since they occur on the client-side, do not get the benefits of this framework.   Fortunately this can be fixed by linking the client to the server with a little Ajax.  James Newton-King has posted a great solution to do just this in ASP.NET. 

In this solution, a small script to capture errors from window.error is registered on the client.  These errors are wrapped in XML and sent to the server via XmlHttp.  On the server, an HttpHandler unwraps the XML and logs a Web Event for the exception- including browser information.  Viola!  Client-side errors in your application's event log.  This is extremely useful for debugging problem scripts and alerting you to problems in your application you may otherwise miss.

The Patterns & Practices team at Microsoft recently released the 3.0 version of the ever-useful Enterprise Library.  Among the changes in the current iteration of the library is the addition of a new application block - the Policy Injection Application Block ("PIAB").

The purpose of the PIAB is to provide developers a way to define "policies" that can be applied selectively throughout an application.  Imagine that you're building a human resources application and one of the requirements is that the application provide an audit trail for all changes made to an employee's personnel record.  The PIAB allows you to define this requirement as a "policy" and configure its behavior external to your application.

Here's how it works:

• Using the Enterprise Library Configuration tool, you define a policy (in this case we'll name it "Audit Policy")
• Each policy can have any number of associated "matching rules"; these rules define how/when the policy is applied.  The PIAB provides the following rules out-of-the-box:
  • Assembly Matching Rule
  • Custom Attribute Matching Rule
  • Member Name Matching Rule
  • Method Signature Matching Rule
  • Namespace Matching Rule
  • Parameter Type Matching Rule
  • Property Matching Rule
  • Return Type Matching Rule
  • Tag Attribute Matching Rule
  • Type Matching Rule
• Each policy can also have any number of "handlers"; handlers determine what happens when a policy is executed.  The PIAB provides the following handlers, which utilize other Enterprise Library application blocks, out-of-the-box:
  • Authorization Handler
  • Caching Handler
  • Exception Handling Handler
  • Logging Handler
  • Performance Counters Handler
  • Validation Handler
• In our HR application example, we'll elect to use a "Tag Attribute Matching Rule" that allows us to mark methods in our business tier classes as requiring audit functionality; in addition, we'll choose to apply the Enterprise Library's Logging Application Block as our policy's handler.
  
   The resulting XML in our application's configuration file looks like this (the Logging Application Block section has been omitted for brevity):
  

<policyInjection>
<policies>
<add name="AuditPolicy">
<matchingRules>
<add match="Audit" ignoreCase="false" 
  type=
  "Microsoft.Practices.EnterpriseLibrary.PolicyInjection.MatchingRules.TagAttributeMatchingRule,
  Microsoft.Practices.EnterpriseLibrary.PolicyInjection, Version=3.0.0.0,
  Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
  name="Tag Attribute Matching Rule" />
</matchingRules>
<handlers>
<add logBehavior="After" beforeMessage="" afterMessage="" eventId="0"
  includeParameterValues="true" includeCallStack="false" includeCallTime="true"
  priority="-1" severity="Information"
  type="Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers.LogCallHandler,
  Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers,
  Version=3.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
  name="Logging Handler">
<categories>
<add name="General" />
</categories>
</add>
</handlers>
</add>
</policies>
</policyInjection>

• In our application, we're going to mark each method that requires an audit trail with a "Tag" attribute...notice that "Audit" corresponds to our matching rule defined above:
  

      /// <summary>
      /// Note:  class must inherit MarshalByRefObject 
      /// for use with the PIAB
      /// </summary>
      class Employee : MarshalByRefObject
      {
          [Tag("Audit")]
          public void Save()
          {
              //write employee to data store
          }
  
          [Tag("Audit")]
          public void Delete()
          {
              //remove employee from data store
          }
      }

• The "policy injection magic" performed by the PIAB will occur as a result of the way we create an instance of our Employee class: 
  
  

  Employee ourEmployee = PolicyInjection.Create<Employee>();
  ourEmployee.Save();

  
  The Create() factory method actually builds and returns a "proxy class" -- in this example, the proxy class intercepts our call to the Save() method, evaluates the matching criteria and determines that the handler should be executed because of the "Audit" tag match.  The result in this case is that an entry is written to the Windows event log as defined by our Logging Application Block configuration.
  

The "policy injection" pattern is worth a look if you have common functionality that needs to be applied throughout your application, and you want to do so in a declarative, transparent way.