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.

In the slides from Scott Guthrie's 'ASP.NET Tips and Tricks' TechEd Presentation, I ran across this gem.  You can turn off debugging server-wide by adding the following to <system.web> section in the server's machine.config file (typically located in C:\windows\Microsoft.NET\Framework\v<version>\Config):

       <deployment retail="true"/>

This is a great backup in case developers forget to turn it off in the application using <compilation debug="false"/>.  Scott also mentions a few of the negative results of forgetting this little setting:

• Slower performance due to debug code
• App uses much more memory
• Client-side scripts are not cached

One of the most useful tools for .NET development is Lutz Roeder's .NET Reflector, now in version 5.  It uses reflection to peek inside .NET assemblies and disassembles the IL back into C# or VB code for those times that you need an in-depth look into any .NET library.  Ever wonder what the code for System.String looked like? This release adds some really nice features:

• Formatted code comments- doubles as a documentation browser for XML code-commented members
• 'Expand members' in disassembler lets you see code for an entire class at once- previously you had to look at each method separately.
• New analyzer features shows where classes are instantiated and exposed.
• Search Google or MSDN for a member

In addition to helping you debug code, this is also a great learning tool.  What better way to understand framework development than to peek inside The Framework itself?

Ever wondered what a secure ASP.NET 2.0 application should look like?  The ASP.NET Internet Security Reference Implementation rolls all of the Patterns and Practices Security Guidance into real-world sample application, complete with full documentation about all of the security features, why and how they were implemented, and the drawbacks to doing so.

If you are doing ASP.NET 1.1 or 2.0 web design, you should download this, read through it, and check out the code.  While the code is 2.0, all of the security concepts- and some of the solutions- map to 1.1 apps as well.

One note: it installs into C:\Program Files\Microsoft\Internet Security Reference Implementation by default.  It took me forever to find it!

I recently data bound to a DateTime property in ASP.NET 2.0, and couldn't figure out why the formatting wasn't working properly.  I set the DataFormatString property to {0:d}, which should change the column to short date format.  But it wasn't formatting at all.  After a little digging, I found that it was because HtmlEncode wasn't set to false.  Setting HtmlEncode="false" on the column fixed the problem. 

Seems a bit odd at first, but the purpose of HtmlEncode is to prevent cross-site-script attacks.  Here's what's happening:

• The property's value is retrieved.
• ASP.NET converts the value to a string and formats it to remove any HTML.  For example a '<' gets changed to '&lt;'.  So, if someone were to somehow add the value <script>doSomethingTricksy()</script> to your database, it wouldn't get run here...
• ASP.NET applies the DataFormatString, but by now the date is already a string. 
• Formatting the string "1/1/2005 12:00:00 PM" doesn't do anything.

Since we know the type is a date, and it would be difficult to insert HTML into the date, then it's pretty safe to turn off this feature for this column.  Microsoft has a little note on this issue here.

I say pretty safe, because it's actually still possible that script or other HTML could be inserted into this column.  A recent post by Scott Hanselman may give you a clue.  Suppose you let users define their own DateTime formatting preferences, and did something really evil, like this:

customCulture.DateTimeFormat.ShortDatePattern = Request("format").ToString()
System.Threading.Thread.CurrentThread.CurrentCulture = customCulture
System.Threading.Thread.CurrentThread.CurrentUICulture = customCulture

And then suppose some crafty hacker sent a link to  yourpage.aspx?format=<script>doSomethingTricksy()</script>MM/dd/yyyy.  Any time you databound to a DateTime, if HtmlEncode was false, then the script would be run! Once somebody gets that far, they can do any number of bad things.

Granted, it's a pretty low threat, but it's worth knowing about.

• Add a reference to MyCompany.Web.dll
• Add the line MyCompany.Web.UI.ClientScriptManager.EnablePNGSupport(...) to a control, page, or master page's OnLoad event.

• Rt Click the project
• Choose Properties
• Choose the Application Tab
• Empty the 'Default Namespace' field.

• Right click the script file and choose 'Properties'
• Set Build Action to 'Embedded Resource'.
• Go to the Solution Explorer and click 'Show All Files'
• Expand the 'My Project' item
• Open AssemblyInfo.vb
• Add this line to the bottom: <Assembly: WebResource("pngfix.js", "text/javascript")>
• Note: If you didn't set the default namespace to empty as above, you'll need to include it here  (ie: "MyCompany.Web.pngfix.js")
  

The introduction of the DataSource model in .NET 2.0 has made it much easier to perform data binding in ASP.NET.  In most cases, it's trivial to use the SqlDataSource and ObjectDataSource for purposes of binding and updating the backing data store when a single row is changed.  However, there's no out-of-the-box way to use a DataSet itself as the backing data store and later persist its entire batch of data to the database.  Consider a shopping cart scenario in which you are adding multiple rows to a temporary data store...you don't necessarily want to go to the DB each time a row is added; rather, you'd prefer to perform a batch update at the end of the process.

Andres Aguiar presents a good solution to the problem by creating a custom data source for this purpose -- the DataSetDataSource.

There is an excellent collection of tutorial videos on the Official ASP.NET 2.0 web site.  While they are probably most beneficial for developers seeking to learn about the new features in 2.0, they should also be useful for those moving to ASP.NET 2.0 from other environments, like traditional ASP or PHP.