Yeah I know it's old news, but being able to step into and debug the .NET Framework source code really does rock my world. I had a customer today who was getting a FileIOPermission exception caused by code like this:

FileInfo fi = new FileInfo(uploadedFile.PostedFile.FileName); // Exception thrown here
string fileExt = fi.Extension.ToLower();

He was creating a FileInfo object just to get at the file extension of a file he was uploading in ASP.NET, he should really have been using Path.GetExtension(string filename) instead, but that's by the by.

Anyhow I was pretty certain as to the cause of the issue, and he explained that this all worked fine on his machine, which I guessed was running at full trust, whereas we operate ASP.NET in partial trust. I suspected that because he was just passing the filename and not a full path, a path was being pre-pended with some location that he had no rights to access i.e. the location where the w3wp.exe is launched from.

Enter .NET Framework Reference source....after some minor fiddling about it was quite neat to be able to step right into the FileInfo constructor and confirm my suspicions:

The call to Path.GetFullPathInternal(filename) returns a fully qualified path to C:\windows\system32\inetsrv which is where the app pool worker process exe resides.  A FileIOPermission Demand is requested for Read access to this file which of course fails because we configure the FileIOPermission Read/Write/Append and PathDiscovery properties as $AppDir$ only.

Prior to this capability I'd have disassembled mscorlib and manually walked through the code to see what was going on, no big hassle, but just being able to step through the code and skip stuff I didn't really need to read and see it 'living' during execution is totally neat.

Nice one MS.