If the custom addins development for VS.NET is not looking appealing for you (with all the COM stuff), DxCore is the way to go. Especially if you download thier Diagnostics plugins that hook into VS.NET and allow you visually to explore and sense things. These plugins are available at http://downloads.devexpress.com/IDETools/DiagnosticTools/IDEDiagnosticTools-2.1.3.zip Do not forget to extract to "<Developer Express Inc>\DXCore for Visual Studio .NET\2.0\Bin\Plugins\" folder. Or just read https://www.devexpress.com/issue=CB43835

"So you know the wing commander Gutsy?..." If you do, then step inside. Debugging an assembly in GAC should be simple, after you go through hell, reading numerous blogs and posts. I will try to cover the whole process, including several how-to's:

1. Strongly name an assembly in a modern way (ie easy)
2. Publish to GAC and access the folder directly
3. Debug a release mode compiled assembly with all source code available, without the project available on your machine.
4. Have intelisense from a GAC assembly
5. Enable VS.NET to show the assembly in the .NET references tab

I. Strongly naming an assembly is easy. Do not try to use the AssemblyKeyFile attribute in AssemblyInfo.cs file. Useless. Instead, access the project properties, select the Signing tab, and do it there. Once you have done that, your assembly is ready to be published to the GAC. (Note: generate the XML documentation as well, we will need it later for intelisense).

II. Prior to publishing, decide on a "fixed" location where your physical assemblies will be published from. We will need this later. Publishing is done with the gacutil.exe tool. (Note: if the tool is not available in the prompt, try to run it in the Visual Studio 2005 Command Prompt). To install an assembly into the GAC, use gacutil /i "drive:\FullPath\AssemblyName.dll". To uninstall, use gacutil /u AssemblyName". When assembly is installed into the GAC, a special folder is created for the AssemblyName and a sub-folder for the version-key. This is where you will find the assembly. The trick is how to get to that folder. By just navigating to that folder with explorer will not help much, but from Start->Run->%windir%\assembly\GAC_MSIL\ will be effective. What you will find is something like c:\WINDOWS\assembly\GAC_MSIL\AssemblyName\1.0.0.0__d9e3acb149fe132c. (2007-04-13 Correction: PDB will give you the symbols information, but not the source code. For source code you can use a shadowed copy of the project from VSS)

III. Okay, how do I debug this thing? Patience. You have done this long way not for free. The location we saw in the previous how-to will allow you to debug your GAC assembly. Just throw beside the .DLL your .PDB file. Once .PDB file is there, the whole source code is there. (Note: .PDB is created even when you compile in release mode)

IV. Are you kidding me - where is the promised land? InteliSense? No worries. Follow the same procedure as in step iii for the .XML file (aaaa, don't tell me you were not asked to create it). This will ensure you precious comments do not vanish.

V. You are a fake - I don't see the assembly in GAC when adding a reference in VS.NET 2005! Do not hurry, this will require a little extra procedure. VS.NET 2005 has to be tough where the "user assemblies" in GAC are "actually residing". An example would be "c:\GacAssemblies". What you will need to do is "teach" VS.NET 2005 where to look for this folder. For that you will learn a trick #2. Your registry will have to grow by another entry (like it wasn't big enough before)[HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\MyAssemblies]@="c:\\GacAssemblies" That's it. From now on, VS.NET will scan the folder and show the assemblies in it.

References you might find useful (well, I did):

• How to display an assembly in the Add Reference dialog box
• Demystifying the .NET Global Assembly Cache
• Using Strong Name Signatures

PS: If this blog did / did not help you - don't be lazy, leave a note.