Migrating from ASP.NET 1.1 to 2.0 can be quite a disturbing experience, at least it has been for me.  You must go through a major (mostly automated) conversion process to recompile your application for 2.0.  Most every one of your source files will be modified during conversion, so there isn't really an option of "going back" or developing a code base against both 1.1 and 2.0 in parallel (although I still hope to attempt this parallel track, it will require tremendous attention to detail and custom automation).

I wish I had read this document from Microsoft before I did the migration for the first time so I wouldn't have been so shocked and horrified at what the conversion wizard did to my code:

Common ASP.NET 2.0 Conversion Issues and Solutions

I highly recommend you at least skim it before attempting the conversion to get a vague idea of what you are in for.  Running the conversion wizard the first time for me caused major problems because of my unrealistic expectations about what I was in for.  My first 3 options for restoring a backup copy of my 1.1 project and source failed for unfortunate reasons, but luckily I had a 4th backup option that I could restore from.  Lesson learned: You can't have enough backups before running the conversion wizard (it's hard to fault Microsoft too much for my near miss, but there are a couple of things they could have done differently that would have saved me quite a bit of grief).

Microsoft has more on migrating from ASP.NET 1.1 to 2.0 here:
http://msdn.microsoft.com/asp.net/migration/upgrade/default.aspx

[via The Daily Grind]

Gunjan Doshi: Using Visual Studio.Net to edit NAnt build files
[via Bill Arnette on WinTechOffTopic]

This very quickly makes the NAnt build script editing environment a lot more pleasant and productive.

For some reason I always have to go searching for this sample code when I want it and it's never as easy to find as I want it to be.  This is a very nice starting point for creating your own custom exception classes in C#.  The translation to VB.NET is straightforward.

using System;
using System.Runtime.Serialization;

namespace YourNamespaceHere
{
    /// <summary>
    /// YourCustomException is a vanilla custom exception for this application.
    /// </summary>
    [Serializable()]
    public class YourCustomException : Exception, ISerializable
    {
        /// <summary>
        /// Calls the default exception constructor.
        /// </summary>
        public YourCustomException()
        {
        }
        /// <summary>
        /// Calls the default exception constructor with a message parameter.
        /// </summary>
        /// <param name="message">The exception message.</param>
        public YourCustomException(string message) : base(message)
        {
        }
        /// <summary>
        /// Calls the default exception constructor with a message and innerException parameter.
        /// </summary>
        /// <param name="message">The exception message.</param>
        /// <param name="inner">The inner exception.</param>
        public YourCustomException(string message, Exception inner): base(message, inner)
        {
        }
        /// <summary>
        /// Calls the default exception constructor with a serialization info and streaming context parameter.
        /// </summary>
        /// <param name="info">The SerializationInfo that holds the serialized object data about the exception being thrown.</param>
        /// <param name="context">The StreamingContext that contains contextual information about the source or destination.</param>
        public YourCustomException(SerializationInfo info, StreamingContext context) : base( info, context )
        {
        }
    }
}

Note that there is some controversy regarding whether you are supposed to inherit from Exception or ApplicationException for custom exceptions due to Microsoft giving inconsistent guidance.

This is the source of information I've giving the most authority to on this issue in my choice of inheriting from Exception:

Brad Abrams Blog

Trying to run NDoc (1.3.1) on a newly setup PC, I ran into this error:

From the NDoc GUI:
---
An error occured while trying to build the documentation.

Exception: NDoc.Core.DocumenterException
Unable to find the HTML Help Compiler. Please verify that the HTML Help Workshop has been installed.

Exception: NDoc.Core.DocumenterException
Unable to find the HTML Help Compiler. Please verify that the HTML Help Workshop has been installed.
---

From the NAnt NDoc Utility:
---
Error building documentation.
    Unable to find the HTML Help Compiler. Please verify that the HTML Help Workshop has been installed.
        Unable to find the HTML Help Compiler. Please verify that the HTML Help Workshop has been installed.
---

As of today, it's not well documented on Google what this error really means.

I am a huge proponent of "fail fast" as a best practice.

Here's a great writeup of what Fail Fast means.  It was written by Jim Shore and edited by Martin Fowler.