On occasion, I have downloaded a sample project for Visual Studio which requires a reference to a sample database.  Of course, I never have that database installed, so I have to go on a hunt to find the database creation files.

The two most common samples I come across are the Northwind database (old sample for Sql Server 200) and the AdventureWorks database (sample for Sql Server 2008). If you need to install one of these sample db's, you can find them all on this CodePlex project...

Microsoft SqlServer Community Projects and Product Samples (databases and sample projects)

and

Microsoft SqlServer Database Product Samples (just the databases)

I typically only access the Windows SDK on an as needed basis.  In ASP.NET development I have run rools such as aspnet_regsql.exe to create database tables for built-in providers like the ASP.NET Membership Provider.

When working with XML, the xsd.exe tool has been useful in the past for creating C# objects from .xsd schema files (but now I use XSDObjGen.exe).

Today, I got curious and began looking through all the other tools offered as part of the SDK.  Some others I found are

TcpAnalyzer.exe - shows all network communication with your pc.
WinDiff.exe - file comparison tool.. granted there are better tools out there.
WSDL.exe - generates code for web services.
MakeCert.exe - for creating x509 (SSL) certificates
SqlMetal.exe - creates code files from database tables, views, and procedures

These are just a few that I thought were interesting, but a full list can be found on the MSDN site...
.NET Framework Tools

On Windows, the SDK is located at C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin

I think there are three main components to every coding project.... application, logging, and reporting.

Of course you have to have the application code, but why do we often leave off the other two?  It seems that even the smallest of projects require some level of logging/reporting, yet we often leave these off.  

Not having some basic logging features will result in poor debugging later because you can't trace a problem.  You don't have to log every little thing, but just enough to help locate a problem should something come up.

Reporting... eventually, someone will ask "how many times did... " or "what is the percentage of...".  Add a basic reporting mechanism to your application, so that you can, at least, answer the big questions.

For small applications, I have begun making a habit of using simple XML files to keep track of logging and reporting info.  It doesn't have to be complicated, in fact, the simpler the better.  A simple solution is likely to get used more!

It looks like the location of ASP.NET Temporary Files has changed in .NET 3.5.

I found the new location today, and it was in the Windows User's AppData folder.  Here is an example path...

C:\Users\[user]\AppData\Local\Temp\Temporary ASP.NET Files\

Previous to 3.5, the temp files could be found in...

C:\Windows\Microsoft.NET\framework\v2.0.50727\Temporary ASP.NET Files\

I don't usually have to be concerned with these files, but on occasion the cached files can cause problems with project builds.  Some build issues can be resolved by deleting all the files in the Temporary ASP.NET Files folder.