Just because your assemblies are GAC'ed does not mean that they automatically appear in the .NET tab of "Add Reference" in Visual Studio 2003/2005. You can make your assemblies appear here by a registry tweak. First, decide which directory you want to store your assemblies. For example, say your projects copy the built assemblies to d:\build\output

Open the registry editor and navigate to the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders

Create a new key beneath AssemblyFolders. The name is arbitrary, so give it a name that applies to the assemblies in the directory, perhaps "INITECH UI 1.0" Next, single click this new key, and in the right pane you'll see (Default) with no value. Set the default value to your directory, d:\build\output

Here's a screenshot of what this looks like for the already-present "SQL Server Assemblies" on my machine.

Also note that this can be set on a per-user basis by performing the same action in the HKCU hive, specifically HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders

If you want multiple directories, create multiple keys.

[Add standard registry disclaimer here] Back up your registry before making changes if you're not used to editing the registry directly.

There are a wide variety of software tools that I use regularly in software development. I will semi-regularly introduce a tool that I actively use in a series called "Focus on Tools." Some tools are complex enough that I will go into deeper detail over time, showing various scenarios where certain aspects of a tool are best used. Obviously, to those already in-the-know, these tool introductions will be old news. But to those not in-the-know, learning about these tools can save you significant time. For example, the catch all solution to problems on a Windows system is "reboot Windows." I'll grant that sometimes this is necessary, but in many cases it isn't, and a reboot is costly time wise. I see this as burning down the house in order to kill a single rat. Effective? Yes. Overkill? You tell me.

Someone recommended rebooting recently when a piece of software wasn't working. In reality a registry setting by the application was incorrect. I've encountered other cases where resources are locked, such as a file or a DLL, and though rebooting would free this locked resource, it's much easier if you can find the source of the lock and then properly address it. Finding problems along these lines in the software we develop is vitally important. In the case of the registry setting that was wrong, I used a tool from http://www.sysinternals.com to monitor registry access. For general resource issues, I use Process Explorer from the same site. I'll introduce both these tools in their own entries soon.

There are many aspects of our job that tools help speed up, many cases where tools get us the information we need. Hopefully you'll find something you didn't know about here.

In my current life I'm a consultant contributing to design and development of software for a health care company. At the moment my work consists primarily of ASP.NET 2.0 and SQL Server 2005, though plenty of other technology is involved (Oracle; .NET 1.1; etc.). I'm also currently in charge of evaluating and demonstrating Visual Studio Team System internally. This gives you an idea of topics you'll see on this blog. I enjoy digging deep into technology so expect some material not covered often by others.

I started on .NET 1.0 when it was in pre-release, before it had any IDE support. I knew it would soon be big and I managed to get a couple articles published in Software Development magazine, but I foolishly did not keep up the publishing momentum, something I hope to rectify. Unfortunately the company I was at took a major financial hit and let roughly 80% of the company go. For my next job, I wound up in the Java world, taking the position to maintain a paycheck. After coming to grips with reality in a post-.COM era, this company downsized and although they kept me on, I soon decided to leave. I was a bit disillusioned with the software world and took some time off. I jumped back in eventually, again in a Java shop, working for a government contractor. Around this time I was given an opportunity to contribute to a Java book, Professional Java Programming with JDK 5, a book that is highly regarded based on feedback at amazon.com. We just finished the next edition of the book, Professional Java Programming with JDK 6, which should be in bookstores early 2007.

So I was a Java developer in my previous life, sandwiched between the Microsoft work of the past (VS 6, MFC, COM, a dash of .NET) and the Microsoft work of the present (mostly .NET, but I jump at a chance to do C++). I'm ecstatic to have the position I do now, getting to use Microsoft technology and truly utilize my skills. I'm passionate about software development - both getting down and dirty and spending late nights hacking, and also reeling in this inclination and focusing on the users of the software, the customer and what makes good business sense.

This is primarily a Microsoft blog, however if Java or other technologies make a guest appearance, don't be surprised. If you are a reader of either PJP book or in general have suggestions for topics or questions, please e-mail me at suggestions AT artofcoding DOT net. For all other correspondence please e-mail me at jeff AT artofcoding DOT net.

Thank you, and welcome!

P.S. The pun in the domain name is both intentional and serendipitous because the domain name was available.

P.P.S. I do ask that conversation in comments stay civil. No flame wars please. I have no desire to censor comments, but any comment I consider excessively harsh will be deleted without notice.