There's a ton of free content on MSDN and elsewhere, but these professional courses usually cost about $50 each, and cover a specific task or topic in-depth.  Enjoy!

One of my favorite development tools is Google.  It's better than MSDN's built in search at putting the links I want at the top.  For example, you can search for "site:microsoft.com Some Class, Method, etc." and quickly get MSDN docs on anything that's bugging you.  And what developer hasn't Googled an error message? 

Now there's a new feature in Google labs that lets you search public source code.  Obviously, you'll need to be wary of licensing issues, but if you want to see how a, say, an HttpHandler is used "in the wild", you'd just search lang:C# (or VB.NET, etc), and the keyword. 

One caveat: there's tons of bad code (tm) out there.  Even on MSDN, there are hard-coded connection strings, unclosed readers, and un-disposed disposables galore.  Don't use Google as a crutch for really learning your trade!

This is a pretty good article on some security considerations in ASP.NET applications, and how they can be addressed by editing your web.config file.

If you haven't checked out the September drop of the Atlas Control Toolkit (Soon to be renamed ASP.NET AJAX Control Toolkit), you should.   One of the coolest new features is the AnimationExtender, which lets you declaratively animate controls.  Just a few lines of markup buys you cross-browser scripted animation.  Obviously, great potential for abuse and breaking site accessibility, but used sparingly could add some nice effects to your site.

http://atlas.asp.net/atlastoolkit/

Need a lightweight paint program?  Paint.NET is a full-featured, fast and free one written in C#.  It hits that sweet spot that Jasc Paint Shop Pro used to: not so bulky that it's overkill for a quick web graphic, but not so feature-limited that you may as well use MS Paint.

http://www.getpaint.net/

Here it is. So hopefully source code won't mess up our blog's layout anymore, let's see:

(Took out code block)

Nope.  Apparenly, it still causes problems in IE.  We'll keep looking...

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.