Shaykatc's WebLog : Visual Studio 2003 Tips

VS 2003 Tip #16: Free debuggers

shaykatc — Thu, 29 Apr 2004 23:08:00 GMT

Life at MS got busy all of a sudden so as a result I blogged less this week. To continue on my last post, the free debuggers we provide are Dbgclr and the command line cordbg. Windbg with sos.dll is a great third one too.

The advantages of these debuggers is mostly their lightweight size. Cordbg was initially a sample developed by the CLR team to make sure they didnt break their code as they developed the debugging API's. The code for it is shipped in the Framework - you can find it under the Tools Developers Guide\Samples folder. Most of cordbg's functionality is available in the Everett debugger, but every now and then we find differences. The $exception feature in Everett was a feature that cordbg had initially - the ability to find the last exception thrown by a thread.

Dbgclr is more of a visual debugger that also ships in the Framework SDK. It can be found in the Guidebug folder in the SDK. It is pared down - but is a very good managed debugger. And its lightweight.

Questions? Let me know.

VS 2003 Tip #16: Part I - Free debuggers

shaykatc — Wed, 21 Apr 2004 23:46:00 GMT

Quick - what are the two free managed debuggers that you can get in Everett (not counting VS 2003)? And if you do know the answer (which I'm fairly certain most do) why do you use them over VS 2003? Let me know what scenarios or why!

VS 2003 Tip #15: Attaching devenv to a process from the command line.

shaykatc — Mon, 19 Apr 2004 20:59:00 GMT

Ziv posted: “I've often wondered how to do the equivalent of "windbg -pn ProcessName" in VS.NET. Is it possible?”

I dont know of a way to attach a devenv via a command line to a process by name, but I do know how to do it by Process ID (PID). Just run the following command from a command shell: vs7jit.exe -p PID. Click “Yes” to debug with a new instance of VS7.1. Then follow through the events to attach your Everett shell to the process to debug it natively or with managed code.

I just spoke to Gregg about this too, and he got that maniacal look in his eye and started telling me ways to script this or use an exe project to do this. When Gregg gets that look, I normally step away, clear the decks so that his brain can operate at full speed with no distractions and pretty much let him say or do what he wants. His net net was that he was going to blog about it, so check out http://weblogs.asp.net/greggm soon for more info on this.

Hope that helps.

VS 2003 Tip #14: Impress your friends with these two arcane tips :-)

shaykatc — Fri, 16 Apr 2004 16:54:00 GMT

Todays tips are more on the arcane side, but when used effectively at a demo, will elevate you to a semi-godlike status in they eyes of the audience:-)

The first deals with attaching to an application to debug it. Sometimes you need to attach to an app to debug it. So you go to Debug.Processes, find the process in the window and select Attach. You then get the dialog that asks you what Debug engines you want to attach with. Say you want to debug C++ (or native code as we call it) only. Well you select the Native option and go on. If you do native only debugging. There is a shortcut here to stop you from doing the two step attach. Just hit the Ctrl key and double click on the process, or select the process, hold down the Ctrl key and click attach. You will automatically attach with the native debugger. No two dialog requirement! Sorry, I don't know of a shortcut for managed.

The second deal with text selection. Normally when you select multiple lines of text in the IDE its done in a flow pattern. Lets say you start selection and go from the beginning of line 1 to the middle of line 3. All of line 1 and 2 and half of line 3 get selected. Well you can select in a different way. Hold down the Alt key and select text. That will do a block select. Its kind of cool to see. I've found it useful when you have for e.g a series of declarations that are all lined up (Say int foo on line 1, int bar on line 2 etc..). You want to delete all the type declarations. Just use this selection method to select all the ints and then hit delete!

VS 2003 Tip #14: What are the requirements to debug a managed application?

shaykatc — Wed, 14 Apr 2004 22:55:00 GMT

Every now and then we get a question about debugging managed code with Visual Studio. It is a little confusing so I thought I'd shed some light on it in this post. A canonical example to use here is where you have a web server on some remote machine running ASP.NET code. Something goes wrong on it and you want to debug it.

To debug using Visual Studio 2003, you need to put remote debugging components on the web server. Insert the main VS disc and on the screen that says 1,2,3- at the bottom is a link for remote component install. Click that and install the managed remote debugging components.

Now when you go to attach to the aspnet_wp.exe process on the remote machine to managed debug it, there are two things that need to happen before you can do so.

The first: Visual Studio uses a service to do debugging called the MDM or Machine Debug Manager. This is one of the components installed by the remote debugging components. This is needed only by Visual Studio - so if you have the framework on your machine, or cordbg you this doesnt apply. The MDM is the first gatekeeper - only two people are allowed to talk to it. Admins on the machine + members of the Debugger Users group (a group created on the machine when the mdm installs). The Debugger Users group is often misunderstood. It serves one function only - its members are allowed access to the MDM. It gives no other permission or privelige to you.

So lets say you add yourself to the Debugger users group and you are'nt an admin on the machine. Now comes the second test - the runtime rule for managed debugging. The rule is simple - if the managed process is running as you, or you are an admin on the machine, you can managed debug it. So now the debugger tries to attached to aspnet_wp.exe (which almost always runs as ASPNET user). You are'nt an admin so that check fails. You arent ASPNET so that check fails too and you cant attach. The trick is to get Admin on the machine, or change the config file for aspnet_wp.exe to run as you. Both have security implications so be careful when you do this.

I hope that helps you better understand what it takes to managed debug an application. For other remote ASP.NET debugging pains, Min keeps an excellent troubleshooting document at http://weblogs.asp.net/mkpark/articles/86872.aspx

VS 2003 Tip #13: Getting a connection string quickly

shaykatc — Tue, 13 Apr 2004 21:47:00 GMT

Often I will be writing some quick code to access a database, and I'll need to add a connection string to get this. Heres a quick way to get the connection string using VS:

Open Server Explorer. Right click on Data connections and select “Add new connection”. Pass the information that you want to connect with to the dialog. Hit ok. Once this connection gets added to your Data Connection, right click on it and select Properties. The properties window opens up and one of the fields in it (conveniently) is Connect String. Copy and Paste it into your code. You can trim it down further if you happen to know more details about it. Voila!

VS 2003 Tip #12: Better view of data in the debugger windows

shaykatc — Mon, 12 Apr 2004 21:15:00 GMT

In VS 2003 we did some things in C# to make viewing of data in the debugger easier.

The first problem we had was that if you expanded a type, in the watch window, you would get an unsorted list of members. This was a pain if you were searching for a particular member. So we sorted that to begin with.

The second thing we did was that we made the displays of Hashtables and Arraylists easier - sort of more natural. We made it so that when you expand a Hashtable object in the watch window, you see the key value pairs. For an ArrayList we show you what the elements in the list are. This was a big difference from VS7 where you had to root around in the member nodes to find this information.

Are there other data structures that you use regularly that you believe should be easy to see? Let us know.

VS 2003 Tip #11: Autocomplete on new class creation

shaykatc — Mon, 29 Mar 2004 23:43:00 GMT

In Everett we made a small change to Intellisense to lessen the code you had to type. Often you will new up a class and write something like:

Foo x = new Foo();

In VS7 you had to type out the whole thing. In Everett we had Intellisense pop up after the new, to autocomplete the class name. This is one of those small features which just makes Everett (to me) so much more enjoyable to use.

As a side note, once we did this, one of the first bugs we saw was that if we declared x to be of type Foo higher up in the file, and then later on declared “x = new“, we didnt autocomplete. I am deeply appreciative of our QA team :-)

VS 2003 Tip #10: Run pre and post build commands from the C# projects

shaykatc — Fri, 26 Mar 2004 18:44:00 GMT

Vs7 customers complained to us that they wanted pre and post build commands that could be run from the project system. Its pretty reasonable to want to automate some tasks that you would do before or after builds, so in Everett we added this in.

To get to this feature take any C# project, and check out the project properties (Project->Properties). Then select Common Properties->Build Events and you should see the property page for custom build steps.

This syntax can include any command that is valid at the command line or in a .bat file. The name of a batch file should be preceded by call to ensure that all subsequent commands will be executed. There are also a handy set of macros to help with the commands. For more information, check out the VS help on this.

For those who might ask, VB doesnt support this in Everett.

Vs 2003 Tip#9: Turning off Dynamic Help

shaykatc — Thu, 18 Mar 2004 20:00:00 GMT

Joen blogs about this here

VS 2003 Tip #8: Exception information in the Object browser

shaykatc — Tue, 16 Mar 2004 21:17:00 GMT

One of the complaints we received from VS7 was that you couldnt tell the exceptions that a particular method could throw. We scratched our heads thinking of ways to do this, as the xml docs did contain this informattion about the class libraries. Ideally we would have liked to have put this information into intellisense, but this request came up after we had done our coding for the milestone. The thing that pushed us off the edge was a usability test we saw, where a guy remarked how painful it was not to have that information.

We ended up adding this information to the object browser. To view it, try something like - Open Object Browser. Open System.IO.File and select the Open method in the right pane. At the bottom of the Object Browsers information pane (where they have method signatures and summary etc), scroll down and you'll see the Exceptions header which should list the exceptions the method can throw.

Addendum #1: This is C#/J# only.

Addendum#2: If you create a dll and put its xml comments file next to it and then view it through the Object browser in a C# project, you should see this for your exceptions too. The equivalent xml tags should be something of the sort:

<paramref name="index" /> is less than zero. <para>-or-</para><para><paramref name="index" /> is greater than <see langword="Count" />.</para></exception>

VS 2003 Tip #7: Implementing interface stubs automatically

shaykatc — Wed, 10 Mar 2004 23:06:00 GMT

In Everett, we added a feature to add interface stubs to your code automatically, when you wanted to derive from an interface. To do this simply type out “:” after your class name, type your interface to derive from and you should see a little tooltip pop up that says “Press TAB to implement stubs for interface Ifoo”. Hit Tab and enjoy VS putting in the stubs for you. If you happen to delete the interface and retype a newer one, you might not see the tooltip again. To get it, erase all the way to the “:”. Enjoy...

VS 2003 Tip #6: Keyboard shortcuts

shaykatc — Thu, 04 Mar 2004 19:47:00 GMT

I'm a keyboard shortcut junkie. I love keyboard shortcuts for tasks. I've been known when speaking to devs to say stuff like “Ctrl+alt+l, Select foo.cpp, Ctrl+alt_w+1...no, hit Ctrl+alt...” instead of “ Open the solution explorer, select Foo.cpp, open a watch window...”. A while ago I saw a post where Jason Mauss asked for the keyboard shortcuts to VS.

These are online on MSDN at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsintro7/html/vxurfvisualstudio70defaultshortcutkeys.asp
Or you can see them in VS 2003 documentation at: ms-help://MS.VSCC.2003/MS.MSDNQTR.2003FEB.1033/vsintro7/html/vxurfvisualstudio70defaultshortcutkeys.htm

However, there are some that I find so useful that I thought I would call them out here (note I tend to use the Visual Studio developer profile in Everett. You can change this from Help->Show Start Page and then pick the My Profile tab):

Word wrap. I hate scrolling across the screen to see a really long line of code. Hit Ctrl+R, Ctrl+R instead. Voila - instant word wrap. Hit it again to unwrap. This also works in the output window.
Copy and then cut the current line of code. Oftentimes, you want to move the current line of code you are working on a couple of lines down. Hit Ctrl+C, C. That copies the current line. Hit Ctrl+L to delete the current line of code. Move your cursor down and hit Ctrl+V. That should paste your original line of code.
After a build failure hit F8. F8 takes you through your errors one by one, and highlights them in the code and puts the message in the status bar at the bottom of VS.
Comment and uncomment code quickly. Select your code. Hit Ctrl+K, Ctrl+C. Automatically commented. Select again. Hit Ctrl+K, Ctrl+U. Uncommented.
Auto formatting. Select your code, or hit Ctrl+A if you are lazy like me. Hit Ctrl+K, Ctrl+F. Code is formatted.
Incremental search. I live by this. Hit Ctrl+I and start typing out the word you want to find in the current file. The IDE then matches the word that you've typed. Hit Ctrl+I repeatedly to find the next occurence of that file. Hit Ctrl+Shift+I to go back.
Get Intellisense. Hit Ctrl+Space in your class etc, and you should get an intellisense dropdown that you can complete on.

Got a cool shortcut that you use frequently? Let me know. Spread the love.

VS 2003 Tip #5: Intellisense in the immediate window

shaykatc — Tue, 02 Mar 2004 06:55:00 GMT

Ok, one other new feature we added was to add intellisense to the immediate window.

The immediate window is a window used to evaluate expressions, much like the VB6 one. When debugging and in break mode, you can open it up from Debug->Windows->Immediate. Then type in the expression you need evaluated and voilà, it returns values. Ok, one of the big changes in Everett was that we added intellisense dropdowns to the immediate window so you could just type for e.g. this. and then get a nice dropdown to see the members on the object. So you don't have to type into the watch window to see evaluations, or mistype into it by mistake.

Which brings me to another feedback point. How important is this to you, Mr. C# Developer? VB.NET was the primary customer for this feature in VS2003 - do you happen to use this also? Anyone? Let us know.

VS 2003 Tip #4: Demo better with the toolbox and task list

shaykatc — Fri, 27 Feb 2004 17:19:00 GMT

Two quick simple techniques for people who need to demo code (as I wait for the traffic in front of my house to recede before getting to work).

Oftentimes, you want to demo some code quickly to people and don't want to type it all in. The Toolbox window is very handy for this. Highlight a bunch of code and drag and drop it to the Toolbox window (View->Toolbox). On my machine I generally put this in the General tab on the Toolbox, but you can put it in the User controls tab too. Now when you are demo'ing and need some quick code, just drag and drop it from the Toolbox where you had it previously stored.

Another cool demo tip I've picked up here, is to use the task list. The task list in C# will show you comments for tokens you specify. So lets say you want to demo some feature in File1.cs line 30 and then in File2.cs at line 40. You can navigate back and forth easily using the task list.

Go to Tools->Options->Environment->Task List and type in “Demo” in the Name textbox. Click Add.
Now go to those files locations you want to demo with and add some comments prefixed with Demo like “//DEMO:Show rapid prototyping here”.
Open your task list and right click on your description pane - make sure the Show Tasks option is selected as “All” or “Comments”.

You should now see the task list automatically populate with your comment. Now when doing a demo, you can just open the task list and click to that code block that you want to show.

Now to fight the traffic...