This post originated from an RSS feed registered with .NET Buzz by Tim Sneath. Original Post: Five .NET Secrets Feed Title: Tim Sneath's Blog Feed URL: /msdnerror.htm?aspxerrorpath=/tims/Rss.aspx Feed Description: Random mumblings on Microsoft, .NET, and other topics. Latest .NET Buzz Posts Latest .NET Buzz Posts by Tim Sneath Latest Posts From Tim Sneath's Blog

Since the ADO.NET Tips and Tricks blog entry seemed to generate some interest, I thought I'd post a few more general .NET tips and tricks.

1. Lots of people know about the basic QuickStart samples included with the .NET Framework SDK, but did you know that we also ship some low-level source samples, including a basic LISP compiler and a code profiler in the SDK? They're included in the Tool Developers Guide subdirectory (on my machine this is at \Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Tool Developers Guide). Also here are the full CLI specifications, including a reference describing MSIL (the intermediate language into which .NET code is initially compiled).
2. Have you ever wondered where assemblies installed into the GAC are physically stored? You'll be able to see them if you navigate to c:\windows\assembly with Explorer, where you'll see a nicely formatted list of assemblies. The shell extension responsible for this view shows not just assemblies in the GAC, but also the native versions of assemblies pre-compiled with ngen.exe. But the files aren't actually stored here - the shell extension simply masks their true location. You can see where the files are really stored by navigating to the same directory via a command prompt. In this location are a number of subdirectories, including one named GAC. Buried here under several layers of hash codes and assembly names resides the physical assemblies, along with an old-fashioned .INI file that contains the strong name amongst other things. It's worth exploring in this uncharted territory just to understand what's going on under the covers, although beware of making changes as the GAC is intended to be opaque.
3. One of the best development utilities you can load on your machine is Lutz Roeder's .NET Reflector (for free!). No matter how much good documentation Microsoft were able to provide, nothing beats looking at source code if you want to see what's really going on, and .NET Reflector allows you to do exactly that. This tool allows you to both disassemble and decompile .NET assemblies to see how they are constructed, and allows you to view the results as both Visual Basic and C#. A positive side-effect of this is that it can help you if you need to port from one language to another. Simply use this tool and then fix up the local variables for their true names (locals are not stored as part of the metadata of an application). I'm not going to get into a discussion about the merits of code obfuscation - I'll simply point you to this location.
4. The first time you browse to an updated ASP.NET website, there's always a couple of seconds pause whilst the ASP.NET worker process does something. But why should there be a wait when you've just built the web application into an assembly using VS.NET? The reason is quite surprising: ASP.NET applications using the code-behind model actually comprise two separate assemblies at runtime. Rather than interpreting the .aspx page, ASP.NET creates a class that dynamically spits out the HTML content when instantiated. This class inherits from the class created in code-behind view, so that both are linked together. The pause when you first browse to the site is caused by this class being generated, compiled and instantiated. On subsequent visits to this page, the class is already compiled (and probably also JITted), so the only step left is to instantiate it. That's why repeated visits to a page are so much faster than the initial visit. (In production this is rarely a problem, since web sites are of course long lived and used by many users.) If you want to see the class that's automatically generated, you can visit a directory called Temporary ASP.NET Files (on my machine stored at \WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files). Buried in here, you'll see an XML file for each page in the site, which contains the name of the automatically generated C# or VB class that implements the dynamic HTML rendering. As with tip #2, this location is deliberately obfuscated to prevent casual tampering, but it's worth looking here just to see what's going on under the covers.
5. My favourite tool in Visual Studio .NET is the command window (press Ctrl+Alt+A to open it). It opens up a whole new level of power when you're building applications. You can use it both as an interactive debug window (for commands like ? myDataSet.GetXml()) or in a command mode both at design-time and run-time. Command mode allows you to execute a command like callstack (to view the call stack), access any of the menu options directly, create aliases (for example, I've created an alias called gac that displays the contents of the GAC in the output window with alias gac shell /output c:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin\gacutil.exe -lr).