Does anyone use dbgclr? Or even know what it is?
My third blog entry in a row which is a question, and its becease we really want your input on these things.
Do you use dbgclr? If you dont even know what it is, then the answer is clearly no. For those folks, dbgclr is a GUI managed debugger that ships with the .NET Framework SDK (and hence with Visual Studio since 7.0). It looks and feels like a tiny version of VS, which is funny because that is exactly what it is. You can debug managed code, edit text files (in black & white), Attach to processes, and well that's about it.
dbgclr is an appid, which is a customized version of Visual Studio, which we, the debugger team, happen to own. 98% of its binaries are taken from the regular VS drop, its only unique bits are its exe and main menu resource table. Most of the bugs we fix for "proper" VS will automagically fix the same issue in dbgclr, but very occasionally we get dbgclr-only bugs (usually Setup-related).
Of course its free, because it ships with the SDK (which you can download). It ships along with cordbg (a command-line managed-only debugger) and, soon, mdbg, yet another managed debugger, but with UI and its own source code (its a C# sample).
Why am I asking? Well we've just had some dbgclr-specific bugs, and I really dont like putting valuable resources on it when almost no-one uses it. I actually tried to kill it several times during the Whidbey product cycle, but failed, so yes, there is a .NET 2.0-matching version.
As the SDK will soon ship with a cmdline managed debugger, a UI one (with its source) I really dont see the point of shipping yet another one, but of course my real reason is to get out of the business of maintaining it, and keeping it alive when we start on the next release.
So if you do actually use it, please tell me why.
A Digression: dbgw64
Have you ever used dbgw64? Well that particular VS appid was created specifically to debug IA64 native code, and was first released sometime in the previous millenium. It was built much like dbgclr, except it included only native-debugger components, and could only debug IA64 code. It was important as there was no other UI debugger for 64-bit around (well except windbg, if you could call that vintage edition a UI debugger). The really unique thing about dbgw64 was it was built in native IA64 code. All of it. Including core bits of Visual Studio. It was also built from a very early Whidbey source tree, so early that it predates the Everett (7.1 source tree): we originally started on Whidbey before Everett was a twinkle in a VP's eye. dbgw64 was the first IA64 Windows native code that shipped (outside of Windows and its SDK). Its no good any more because it cannot read PDB format 8 files, and because the OS changed the context record since we shipped it. Its a shame there is no native-64 bit version of VS for Whidbey, it would be a screamer.
Comments
Anonymous
February 21, 2005
We've been using it during the early phase of the 2.0 preview cycle, when there wasn't a VS.NET around; it does make things a heck of a lot easier to deal with at that stage, but we really couldn't care if it was nixed at the actual shipping stage.Anonymous
February 21, 2005
Yes I have used DbgClr extensively because it seems to use fewer resources and doesnt need the full VS to use it. If MDbg is as good (haven't tried it yet) it can be replaced otherwise please keep it. It aso useful not to have to learn another keyboard accelerator set.Anonymous
February 21, 2005
I must confess that I use it quite a bit. Maybe it's must the way my brain works, but I find it handy when all of the complexity of VS isn't required. That being said, if the debug UI thingy that's going to ship is equally "light" and reasonably easy to use, I'll be perfectly happy.Anonymous
February 21, 2005
The comment has been removedAnonymous
February 21, 2005
I use almost nothing but the dbgclr, though I'm the only one in my group who does use it. I don't think anyone else even knows it's there as I get quite a few "what happened to your VS install" when they see me using it. Then again, I'm also pretty much the only one writing Windows services and ASP.NET applications and I prefer to "attach to process" with dbgclr over the full VS. For the few winform apps I've had a part in, I do use VS. If MDbg is almost equivalent though, it won't bother me if dbgclr is gone.Anonymous
February 21, 2005
Andy,
i know it exists. i have never used it. i see no point in doing so in the future.
WM_CHEERS
thomas woelferAnonymous
February 21, 2005
I've used it once or twice out of curiosity when asked to pick a debugger.Anonymous
February 21, 2005
I second the "great for deployment boxes" - web server or client - to reproduce issues without a vs.net license and install.
However, even though it is useful, it's not essential. If you can put more resources into VS.NET (Whidbey, Orcas, etc) go for it.
I'd much rather no dbgclr and have the Whidbey post-release bugs fixed in a gasp service pack, then have the same situation as vs2003 where we have dbgclr, but getting hotfixes for known issues requires 30-60 minutes per client talking to PSS.Anonymous
February 22, 2005
I third the "useful occasionally on deployment boxes" comments, but in my case it's on the occasions when I have a bug on a client site that we can't reproduce on the test machines.
That's not often, but when it does happen, it's really nice to have around.Anonymous
February 23, 2005
I'm using it to debug nemerle (http://nemerle.org) assemblies, and it is quite cool.Anonymous
February 23, 2005
A little digression: does anybody knows how to install the DbgClr only (not the full SDK)? I've tried to xcopy the files but it does not work (pop-up asking me to reinstall).Anonymous
February 26, 2005
The comment has been removedAnonymous
June 12, 2006
The comment has been removedAnonymous
July 14, 2006
The comment has been removedAnonymous
February 17, 2009
Could you make hint how to install C# editor to dbgclr? Overall debugging is cool, but plain text editor is annoying a little bit...Anonymous
February 17, 2009
nch: The C# editor requires the C# project system, which requires the VS project system, which requires... Use VS.Anonymous
February 17, 2009
andypennell: Thanks, I've tried but unsuccessfully. The reason is that application utilizes .net framework 1.1. VS 2003 hangs without any slight reason during debugging, maybe due to the application complexity. VS 2005 doesn't support debugging of such applications (.net 1.1). So I use dbgclr from vs 2005 - it consumes less memory and hangs much lesser :) But why "C# editor requires the C# project system"? Doesn't editor should be provided by a language service for VS? I mean, maybe a chain "x requires y requires z" will be not so long?Anonymous
February 18, 2009
The C# language service requires a real project in order to work (parsing projects and building the class hierarcy), hence the dependency tree. Suggest upgrading your app to use Net FX 2.0 at least: 1.1 is six years old now. You can always edit your C# in VS2005, while debugging in dbgclr: get the best of both worlds.Anonymous
April 18, 2009
Greetings, I use the CLR debugger frequently, my budget doesn't afford VS standard or professional editions, I use the express edition, so dbgclr is important to me. The second reason is to debug software at the production environment as the above comments pointed. My question: Is the visual CLR debugger (DbgCLR.exe) available with the windows SDK v6.1? or I must install the .net framework 2 SDK to have it?Anonymous
May 15, 2009
The comment has been removed