I've not been one to work the newsgroups, answering questions. I probably should.
I'm more of a one on one person, and I tend to go the extra mile when folks (largely
strangers) ask me technical questions. I've had email threads 10-deep with total strangers
on technical questions, and only at the end do I say, "Um, do I know you?"
Anyway, the point of this post was this: People, for crying out loud, debug a few
things before you ask for help. If you don't know how to debug, learn or ask someone
to teach you.
The Hanselman List of .NET Debugging Dos and Don'ts
Don't - Say "Hey, I got a NullReferenceException," what's the problem?
Do - Provide a Stack Trace/Dump with the line number it likely happened
on.
Don't - Get deep into your complicated program, find a bug and insist
it's BillGs fault.
Do - Reproduce the bug in some simple test program and tell the world.
Remember, 9/10 times it's you.
Don't - Decide there's a problem if you don't know the preferred
behavior.
Do - Always Assert your assumptions. If null can happen, check for
it. BUT, if null must never happen it's time for a Debug.Assert
Don't - Move code around blindly, somehow fix your bug, ignore it
and keep coding. Programming by Coincidence!
Do - Understand your program fully. Remember what Andy
and Dave say about lucky folks who step into minefields and don't die. Just because
you didn't die, doesn't mean there aren't mines!
Don't - Reformat or "pave" something because you don't know what's
wrong. If you get a spot on your carpet, fix the spot. Don't lay new carpet.
Do - Know enough about your environment to know what your program's
dependencies are. If your registry settings can get boogered, Debug.Assert that you
are getting good values from the registry.
Don't - Get overly frustrated with Assembly loading/versioning/policy.
At least the Assembly Loader follows clear, set, rules.
Do - Make a folder called C:\FusionLogs, then go to the registry
in HKLM:\Software\Microsoft\Fusion and make a DWORD value LogFailures=1 and string
value LogPath=C:\FusionLogs. Every AppDomain that has a binding failure or weird redirect
will get logged. Know: What assembly you want, what they looked for, what you
got. Know where Assemblies are searched for.
Don't - Avoid debugging. Debugging in .NET is easier than ever before.
Remote debugging and AttachToProcess are gifts. Don't stop at a point in the call
stack if you can keep going by finding PDBs.
Do - Keep your Source and PDBs in the same location. We keep ZIPs
of every build's PDBs. Just today we dug up 9-month old PDBs and source (from CVS)
to debug into some confusion. Not saving those PDBs would have screwed us. Create
a Symbol Server.
Don't - Limit yourself to the QuickWatch. Learn what VS.NET has to
offer.
Do - Use the Immediate Window to test theories. Remember that you
can perform Casts in the Watch Window. Remember that you can drag and drop variables
into the Watch Window. Remember you have 4 Watch Windows, Autos, Locals, not to mention.
Learn how to use Conditional Breakpoints!
Don't - not debug something just because you can't figure out how
to launch the process from the VS.NET Project Properties.
Do - Debug|Processes|Attach to attach to processes that have your
DLL loaded. Use ProcExp from SysInternals as
a better Task Manager to see .NET processes, as well as a system-wide DLL search.
Who's got you loaded?
Previous Topic
