I just recently recorded a ~30 minute piece on the Visual Studio Toolbox site. Consider this video a refresher of the bits ( for those who weren’t familiar with the VS2010 capabilities ), as well as a quick summary of some of the latest features we’ve enabled.

For more in depth video, be sure to check out Chris Lovett’s recent video, which is much more comprehensive.

One of the more significant pieces of technology that we have created in support of the new Visualization and Dependency work in VS11 is known as the “Code Index”. Essentially, a LocalDB database where we house all the information of the assemblies you are trying to understand. Take a look at Jean-Marc’s recent post about the Code Index, and the SDK made available in the Visualization and Modeling SDK.

The teams has focused on fixing numerous bugs as well as addressing a number of performance issues, but has also poured a number of new features into this release:

• Easily turn Debugger Canvas on or off, even in the middle of a debug session
• Quickly navigate up and down the call stack in the canvas using the keyboard or the mouse
• See Multiple threads together on the canvas, each thread identified by its color.
• See recursive calls side by side
• Edit code directly in the code bubbles ( this is now on by default ).

Please take this new release out for a test drive by going over to DevLabs and downloading this new version. And as always, the team welcomes and looks forward to your feedback. Please visit the DevLabs forum and let us hear about it!

Cheers!

Cameron

If you are interested, please send an email to debugcanvsignup@microsoft.com, and take a look at this forum post for more info.

Cheers,

Cameron

Please check out Jason Zander’s blog post about the announcements, and be sure to read this white paper. The white paper goes into quite a bit of information about many of the new features we announced yesterday, such as the new Unit Testing work, the new Storyboarding assistant designed to help manage lightweight requirements, Code Clone analysis, and so on.

It was a blast to demonstrate many of these features during the TechEd keynote with Jason, and it was even better to present at the ALM Futures foundational session immediately following the keynote, to go into a bit more detail and show a few other items we didn’t have time to get to in the keynote.

Exciting times!

Try this out. Go to msdn.microsoft.com, then click the library tab ( or go directly there by clicking this link ). Now, type “Hashtable” in the search text box. You should see something like this as the first entry in the results:

The main thing I like about this is the quick access to the source code. Notice to the right of the C# and VB code, there is a little icon. Go ahead and click that. That will bring up a “text” window in the middle of your browser, allowing you to select that code, copy, and paste into your code. Very nice!

This is a new approach to search results within MSDN, and the amount of content that is ready for this new format is limited, but I think these folks are really doing a great job to make the content as accessible as possible.

What do you think? What do you like about it? Anything you’d change?

Cameron

Check out Willy’s post for more details, or go and download it directly here. A bunch of great prescriptive guidance on how to use the modeling and visualization capabilities present in Visual Studio 2010 Ultimate.

Cheers!

Cameron

This is going to be another great convention, with tons of new content, learnings, and simple collaboration guaranteed.

One of the things I’m very excited about at this years Tech Ed is the fact that we will be introducing many of the new Application Lifecycle Management ( ALM ) capabilities that will be in the *next* version of Visual Studio.

Jason Zander will be sharing the keynote message with CVP Robert Wahbe, and will be introducing the new capabilities. He and I will demo a few of them during that keynote, then I will continue the conversation in a Foundational session immediately after the keynote. All about the demos, with a few surprises along the way!

Hope you can make it out to Atlanta!

Cameron

Adding Your Symbols

Adding your symbols to the symbol server is a great practice, as it gives you a better chance of debugging one of your own executables or dlls without having to have that exact version of the image available. The typical use case here of course is support of a previously deployed app. You’re currently heads down working on V3 of your app but some customer out there is currently using V1 and reports some crashing or other bug with that version. How to maximize your chances of debugging the issue? Symbols server will certainly help, as long as you have added your PDBs to the server.

How do you add your own symbols to the server? There’s an “easy” way, and then a “hard” way.

The Easy Way

The “easy” way is to use the support built into Team Foundation Server 2010’s Team Build. All you need to do is tell TFS where to drop your PDBs ( it must have permission to write to that directory ) and it will handle all the rest! You do that in your build definition file. Just set the “Path to Publish Symbols” to a public UNC share, and your golden. Here’s an example:

Behind the scenes, TFS is actually handling the steps you can manually do, which I’ll describe now.

The Hard Way

You can manually add your PDBs to a symbol server by making use of the symstore.exe, which is part of the “Debugging Tools for Windows” package. Of course, since this is just a command line tool, you can incorporate the following steps into any MSBuild process.

Here’s an example of the command line options that I used to push my symbols to my store:

symstore add /f DebuggingSeries.* /s \\camerons4\Symbols\MySymbols /t "My Version 1" /v "1.0.0.0" /c "Manually adding"

This simply takes the exe and the PDB from my output directory ( the directory I ran symstore in ), and copied the symbols to the UNC folder specified.

Check out this page in the MSDN docs for more details, and here for all the details around the command line options.

If you take a look at the folder where the PDBs and exe get pushed, it should look something like this:

But what does this now do for me? Easiest to show through an example.

Symbols In Action

As I mentioned earlier, the classic case where use of a symbol server can really help is during a post-mortem debug session, where you have received a mini-dump of your application. So let’s simulate that use case by running the following bit of code on one machine, produce a mini-dump of that running exe, then take that dump over to another machine that does *not* have the source to the exe, load it into VS 2010, and see what we see.

1. Here’s the code I’m using for this example:
   
   
   This code will run and break on the 50th iteration, allowing you to get a mini-dump in a later step.
2. Build that in Release mode, choosing “Any CPU” as the configuration.
3. Add the new symbols from your release directory to your build server, using the symstore.exe command I described above.
4. Run the app by hitting Ctrl-F5 in the Visual Studio. This will run your app without launching the debugger.
5. If you’re using the code above, you’ll see a console window appear and then an apparent “crash” dialog:
   
6. At this point, bring up the Task Manager by hitting Ctrl-Shift-Esc. Find your app in the process list, right click, and select “Create Dump File”:
   
   A dialog will appear after a second telling you the location and name of the dump file that was just created. Keep that dialog up and handy, as you’ll be copying that dump file over to another machine next.
7. Copy the dump file over to another machine.
8. Open up Visual Studio 2010 and open the dump file.
9. Ensure that you have enabled all the symbol server settings in Visual Studio as described in my last post, as well as turned off “Just My Code”.
10. Add a new entry into the list of Symbol file locations that points at the UNC share that you enabled for your application symbols. My dialog looks like this:
    
    
    NOTE:
    There is a bug when attempting to open up a mini-dump for managed code in VS 2010 SP1. The workaround is to make a couple dlls available from the machine that the dump was generated to the machine that wants to analyse a dump. Details here. That’s what the last entry in the above image is doing, making those dlls available.
11. Now open the dump file in VS. You should see something like this in the VS doc well:
    
12. Click the “Debug with Mixed” link, outlined in read in the above image.
    ( I think mixed-mode debugging is worthy of its own post, so I’m not going to go into details on mixed-mode debugging right now.  )
13. Visual Studio will go into a debug-like state. After a couple moments, take a look at your call stack and “Locals” windows. You should see your code showing up in the stack, as well as the value of your variables in the Locals window. Mine looks like this:
    
    And my Locals like this:
    
14. Very cool! Now if you didn’t turn off “Just My Code” and were not using a symbol server, you would be presented with this dialog after clicking the “Debug with Mixed” link:
    
    After hitting the “OK” button on that, your call stack would look something like this:
    
    Not real useful.

Next Steps

I hope that gives you a good sense of how proper use of symbol servers can help you. In my next post, I’ll talk about a sister technology to symbols servers: Source Server. That will give you the added benefit of automatically opening the actual source code in the above scenario, in addition to the added data in the call stacks.

Stay tuned!

Cameron

Symbol Server

What is it? Essentially, a symbol server is way to expose the symbols ( PDBs ) of your applications to the debugger in a way discoverable by the debugger regardless of where the debugger is run. This same thing is also true for system symbols as well. Not only that, it is a way to handle the versioning of those PDBs so that the debugger understands how to find version one of your symbols, vs. version two, and so on.

That’s all well and good, but why is this a good thing for the developer? Let’s look at what things look like when you *don’t* have a symbol server established.

Without Symbol Server

Here’s some sample code you have undoubtedly seen a zillion times by now:

using System;

namespace DebuggingSeries
{
   class Program
   {
      static void Main( string[] args )
      {
         Console.WriteLine( "Hello World" );
      }
   }
}

After a moment, you will hit the breakpoint. Now, open up the Modules window ( while in the debugger, select the Debug->Windows->Modules menu item ):

While will open a tool window that looks something like the one below:

The “Modules” tool window shows you all the images ( dlls, etc. ) that are loaded in order to run the executable you are currently debugging. ( NOTE: This is a very useful tool window that many folks don’t know is available in the product, and has many uses which we won’t have a chance to go through today, but more some other time. )

You’ll notice in the image above that there is a Column called “Symbol Status”. Assuming you are running with default debugging settings that Visual Studio 2010 has shipped with, you’ll also notice that almost all the rows in the tool windows except the one I highlighted have the value “Skipped loading symbols.”. The one highlighted is the actual executable itself, which contains the symbols associated with the code you typed in. You’ll also notice that the “User Code” column is “No” for everything except for this last entry as well. More on this later.

Now bring up the “Call Stack” toolwindow ( Debug->Windows->Call Stack ). You should see something like this:

Cool, now let’s see what changes once you start using a Symbol Server, but there is actually one other thing you’ve gotta do before you see the goodness of the Symbol Server. You’ll need to turn off the “Just My Code” feature in Visual Studio.

Turn Off Just My Code

By default, Visual Studio 2010 has the “Just My Code” option turn on. This on on by default as it tends to reduce the amount of information a new user has to deal with when initially debugging inside Visual Studio. It tries to protect you by not drowning you in information.

I struggle with this option, as the intent of it is quite good, but in practice, I tend to always turn this off. ( I would love to hear your thoughts on whether or not this option should be on or off by default. Please fill the comment section with those thoughts! )

For the purposes of this post on this series, please turn off this option. Here’s how:

Go into “Tools-Options…” dialog, find the “Debugging” option on the left side of the dialog, and notice the “Enable Just My Code” option on the right:

Uncheck that box so that your dialog looks like this:

Now your ready to see the effects of the Symbol Server option.

With Symbol Server

Go back into the “Tools->Options…” dialog, and expand the “Debugging” option, and select the “Symbols” option:

Go ahead and click the check box next to “Microsoft Symbol Servers”. You should see a dialog box popup that you can safely ignore for now.

If you hit OK at this point, VS will automatically fill in a default directory that it will use for PDBs it pulls down from a public Microsoft site that contains the PDBs tied to the various versions of the framework DLLs.

If you are on a team of developers, it is a good idea to establish a common file share that all members of your team can use to house these symbols so that you don’t have to wait for the download of those images while you debug. The first developer who needs them would feel that delay, but everyone else on the team would simply pull from the common share.

For now, take the defaults and hit F5 again. You should be in the debugger waiting at the breakpoint.

Take a look at your Modules window now:

Notice how everything is loaded ( Symbol Status column reads “Symbols loaded.” ) and the User Code column reads “N/A”, ‘cause we disabled the “Just My Code Feature”

Now take a look at your call stack window:

Compare this with the image of the call stack with the one I previously showed you above. Notice how much more information is now available to you?

And therein lies the point of all this:

When you are debugging, you need as much information as you can get in order to figure out the task at hand. You never know what little piece of information will be the clue that drives you towards the final solution.

Next Steps

This post is just scratching the surface. Next post in this series, I’ll dig a little further into some more of the benefits of the symbol server, and why making your own symbols available to your team in this manner will benefit you.

Cheers!

Cameron

This is a great place to start for folks who haven’t done any WP7 development yet but want to. It covers almost all the major areas that a typical app would need to do. A notable topic that is *not* included is any information about the Push Notification Services, but more is on the way.

The guidance focuses on the following development tasks:

· Designing the user interface (UI) and choosing appropriate controls, icons, and graphics. · Using the application bar and back button, and handling navigation between pages. · Storing and retrieving data using isolated storage. · Display data in controls, enabling user edits, and performing validation. · Handling application deactivation, tombstoning, and reactivation. · Publishing your application in the Windows Phone Marketplace.