Just a quick note... If you don't use Sysinternals tools, you must not be programming anything important.  Its the be-all, end-all of windoze troubleshooting tools. 

But sometimes getting those tools where you need them is inconvenient.  For instance, say you need to use Process Monitor to figure out why your ASP.NET website is bombing out during the compilation phase on a production server.  The error logs won't help you; all you get is a FNF without the filename that wasn't found in the error message (thanks, framework guys!).

You're connected to the server over an RDP.  How do you get procmon on the server?  You can Google the addy for Sysinternals and then click through a few pages to download it.  Of course, you'll have to specifically allow every page you have to click through due to the extended security on the 2k3 box.  Or you might find port 80 is blocked completely by the client's corporate firewall. 

You could then try to copy it over the RDP... OOPS!  You forgot to set up disk and desktop sharing.  Or maybe you're bandwidth to the server is a 1/2 inch diameter pipe due to some stringent QoS settings.

Well, the Sysinternals guys just made it a whole lot easier.  They set up a network share on the internets.

\\live.sysinternals.com\tools

You can open it up in any Explorer window like any other network share, as long as you can get to the internet.  You can download the apps directly by copying them, or just run them over the share.  For example, open a cmd window and run Filemon directly:

\\live.sysinternals.com\tools\filemon.exe

Its just that bad-ass.

I've been hit by this lovely error a number of times over the past year when attempting to run unit tests in Visual Studio 2005.  I always end up searching for the answer, encountering the fifty or so different "solutions" that fail horribly.  So now I save it here.

The fix is to reset your environment in Visual Studio.  You can do this by opening a Visual Studio Command Prompt (MS Visual Studio 2005 -> Visual Studio Tools from the start menu) and run the following command (PLEASE READ ON prior to running this!  Important stuff comes later!):

devenv /resetuserdata

This brings Visual Studio back to the primordial stage.  Unfortunately, you lose all your settings.  That includes all your tricky VS fonts and colors customizations.  You won't lose your Add-ins, however.  So if you want to save and then reload all your UI customizations, you'd better save them first. 

For some info about saving color and font settings, you can check out this post over at CodingHorror.

I have need for this every once in awhile; now I know exactly where to look for the answer.

Compiler warnings are useful.  But sometimes they're annoying, too.  For instance, when you're working on a framework and creating events.  Unless you're using the event within the assembly, you'll encounter compiler warning CS0067, "The event 'event' is never used". 

These compiler warnings can be suppressed.  I'm not suggesting you should suppress them automatically, every time they crop up.  You should consider whether or not the event is useful.  Events aren't just a single line of code.  The compiler spends much time creating classes and generating code in the background.  So, please, before you suppress your compiler warnings, take a moment to consider if it is a good idea or not.

Once you have decided to kill the warning, you can instruct the compiler to suppress the warning using a #pragma compiler instruction to suppress the warning thusly:

#pragma warning disable 67

        public event EventHandler UselessEventLol;

#pragma warning restore 67

The same command can be used to suppress any compiler warning.  Its best to disable them prior to the line you wish to suppress and then immediately restore (why it isn't enable I don't know) afterwards.

Ran into an annoying issue while working on some unit tests today.  It involves unit test projects within Team System for Developers.  Skip to the bottom for the TL;DR version.

I was doing some general project maintenance, as is needed when multiple developers are touching the same codebase.  Somewhere someone had changed the build configuration to Release and I didn't notice it after I did my usual Get Latest Version.  The result of this was that my unit tests were failing due to invalid references.

The cause of the failure wasn't obvious from the beginning, so I went about rechecking and "fixing" the references until I realized what the real cause of the issue was.  So, I changed the build configuration back to Debug and continued working.

I added some new code and tests, and went to the Test View window to run all unit tests in our project.  While most of the tests completed successfully, a few of the test projects failed all their tests with the following errors:

 System.IO.FileLoadException: Could not load file or assembly 'Blahbety.Blah, Version=0.1.0.0, Culture=neutral, PublicKeyToken=1234567890abcdef' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

This was prefixed by a message about the test failing, whether because the exception was thrown or because an unexpected exception was thrown, depending on what test was run.

Unfortunately, Google was mute on the subject.  Most FileLoadExceptions have nothing to do with unit tests, so I couldn't hone in on relevant articles.  The errors did all have to do with the same support DLL, but when I examined the DLL in the test folder against what the error message reported was missing, the assembly's strong names matched.

It got even weirder.  I couldn't get the tests to work in Test View, but I could get them to pass if I ran them from within the test project.  Selecting the project within the solution explorer and then running the tests via the Test Tools Toolbar worked.

After a bit more futzing around, I checked out the errors and warnings report from the test run.  Sure enough, down at the bottom, I got a hint about what was going on:

Conflict during test run deployment: deployment item 'C:\vs2k5\Blabbety\Blabbety.Support\obj\Debug\Blabbety.Support.dll' cannot be deployed to 'Blabbety.Support.dll' because otherwise it would overwrite deployment item 'C:\vs2k5\Blabbety\Blabbety.Tests.Job\bin\Release\Blabbety.Support.dll'.

Firstly, I have no idea why the test was trying to copy a DLL from the obj directory and not the bin directory.  And, to go along with this weirdness, a release binary (which was of course not the expected build) was being used to run tests against.  I deduced that one of the projects was referencing an incorrect assembly, possibly through someone browsing to a binary when adding a reference instead of using the Projects tab in the Add Reference dialog.

Examining all references to the Support project I found that one of the test projects referenced the release build of the DLL.  I re-created that reference using the Projects tab, but the tests still failed.  The last step I had to do was refresh the tests in Test View, which finally solved the problem.

TL;DR version:  If your tests throw a FileNotFound exception, your references are screwed up.  Do the following:

1. Determine the DLL that cannot be loaded
2. Find all projects in your solution (including test projects) that reference this DLL
3. Check the properties of the reference to make sure it points to the correct build type (most likely Debug), and if not
4. Delete the reference and re-create it using the Projects tab of the Add Reference dialog.  DO NOT BROWSE TO THE DLL!

So I have my lovely little DotNetKicks-based website up and running (its LOLKicks, by the way).  Took me a week to get it working properly, primarily because of URL Rewriting.

What is URL Rewriting, you ask?  TL;DR version:  It makes ugly URLs like

http://foo.com/bar/default.aspx?user=123&fail=true

into nice looking URLs like

http://foo.com/user/123/fail

This is primarily used for search engine optimization, and to look all cool and stuff.

Anyhow, DotNetKicks makes extensive use of URL rewriting through a nice little project called UrlRewriting.NET.  It generally works perfect, but apparently in my case it has a weakness...

My server is a virtual machine running the 64 bit version of Windows Server 2003.  Now, as it comes, the server has pretty much everything you need to host an ASP.NET web site.  However, it is preconfigured with some nonsense that requires IIS to run in 32bit compatability mode.  Usually, that isn't an issue.  Hell, it still might not be.

Because its a 64 bit box, it doesn't come with Frontpage 2002 Extensions installed.  FPE help make modifying websites easier by providing extensions that programs like Visual Studio and Expression Web can use to directly modify files on the web server over the internet.  That's a nice thing; something I would like to take advantage of, moreso now because I want to skin my DNK site. 

It seems pretty obvious what you do at this point:  You download the Frontpage 2002 Extensions and install them on the web server.  The 32bit version won't install on a 64 bit machine, so you have to install the 64 bit version, even though IIS is running in 32bit compat mode.  Fine.

Installing FPE is quick and easy and it appears to work.  Great.  Except for one problem...  Once you install them on a web server, UrlRewriting.NET won't work.  Not even if you uninstall FPE.

I've learned that UrlRewriting.NET won't work if you install FPE 64bit before you create your website, after you create your website, and if you uninstall FPE in some vain hope of fixing your broken website.

Currently, I have found no solution other than wiping the machine to fix the issue.  I have a post about it over at the UrlRewriting.NET discussion group here.  It kinda sucks because I'm going to end up having to wipe this server, most likely, in order to fix my error. 

Update:  Restoring IIS' configuration to a previous state did not fix the break.  I'm going to have to wipe tomorrow.  Not that I don't normally wipe, I'm just sayin'...