Colin Thomsen's Microsoft Blog : dev

Tech-Ed 2008 Demos

colinth — Tue, 03 Jun 2008 06:25:50 GMT

Last year my boss took a trip to sunny Orlando to present at Tech-Ed and to offer help and suggestions in the Technical Learning Center (TLC). This year I'm lucky enough to be attending with a couple of other folks (Habib and Tim) and since I'm not an official Speaker I'll be spending most of my time hanging out in the Application Lifecycle Management (ALM) demo station for Visual Studio 2008 Team System, Development Edition.

We've prepared a few demos covering things like:

Profiling using Instrumentation Mode on a Virtual PC image.
Collecting Allocation and Object Lifetime information.
Analyzing Performance Reports.
Using Code Analysis to improve your code.
Enabling Code Analysis Check-In Policies.

We're also looking forward to discussing your specific scenarios so if you're at Tech-Ed and interested in diagnostic tools and solving performance problems we'd love to chat with you.

Sysinternals is Live

colinth — Fri, 30 May 2008 19:28:00 GMT

I use a bunch of Sysinternals tools for diagnosing problems while developing. My two favorites are:

Process Explorer, a more fully-featured version of Task Manager that can report environment variables for running processes, show loaded DLLs and even display callstacks. It can also tell you which process is currently accessing a certain file or DLL, which is useful if you're trying to delete a file and getting a 'file is in use and cannot be deleted' error.
Process Monitor, which can record all accesses to files, disks and the registry. Very useful for diagnosing complicated scenarios with multi-process development.

Recently the Sysinternals tools have been hosted on a new live site that can be accessed via the web, or as a file share. Now I can easily run a Sysinternals tool and be sure that it is the newest version:

I can also update my own local cache of useful tools by periodically copying from the file share.

Performance: Inserting Marks Using Code

colinth — Thu, 01 May 2008 17:55:00 GMT

Ian previously covered using the VS 2008 Data Collection Control to choose when to collect data. The Data Collection Control can also be used to insert marks into the performance report, but sometimes it is convenient to modify the source code to do this automatically.

Consider a typical application (PeopleTrax) where I am interested in gathering profiler data only between when a button is clicked and when data is displayed. The application is shown below.

After the 'Get People' button is clicked, data is displayed after just over 6 seconds. This seems a little excessive so I want to focus my performance investigation in this area.

To filter the data so that it only shows information collected between those two points, I could use the Data Collection Control, but maybe I'm planning to run a complicated scenario and don't want to have to remember to insert the marks manually. Instead, it is possible to modify the original code to request the profiler insert marks in the required locations.

The Profiler API is available for managed code in an assembly that can be added directly to the project from \Program Files\Microsoft Visual Studio 9.0\Team Tools\Performance Tools.

After adding the reference it shows up in the 'References' list for the PeopleTrax project.

I can then use functions in the Profiler API to control the profiler. This might include starting or stopping data collection or in this case, inserting marks into the datastream. This is easily achieved as shown below.

I can then profile the application and when I open the Performance Report and switch to Marks View I see that the marks have been correctly inserted. We can also see that the time elapsed between the marks is about 6.5 seconds, which corresponds with the measurement that is already displayed in the PeopleTrax UI.

I can use the marks to filter the report to only show profiling data for the time between the two inserted marks and then start my performance investigation.

Scripting for C#

colinth — Tue, 01 Jan 2008 02:29:00 GMT

Have you ever wanted to quickly run a C# application without having to setup a new project in Visual Studio and configure all the settings? A fellow developer here at Microsoft has written a tool called Code Runner .NET that allows just that. It isn't scripting exactly because the code is still compiled before being run instead of being interpreted, but you don't have to maintain project or solution files or worry about binaries.

To try it out I downloaded the tool and installed it to c:\temp\csr. I created a file test.csr after referring to the Getting Started Guide:

   1: using System;

   2: using Microsoft.Tools.CodeRunner;

3:

   4: public class Program

   5: {

   6:     public static int Main(string[] args)

   7:     {

   8:         if (args.Length == 0)

   9:         {

  10:             // TODO: Fill out usage information

  11:             Console.WriteLine("Usage: {0}", ScriptEnvironment.ScriptPath.FileAndExtension);

  12:             return 0;

  13:         }

14:

  15:         // TODO: Script code goes here...

16:

  17:         return 0;

  18:     }

  19: }

My directory was completely empty aside from this file:

C:\temp\cr\mytest>dir /b
test.csr

I could then run the file as follows:

C:\temp\cr\mytest>..\csr test.csr
Usage: test.csr

That's it. The directory was still clean after the run:

C:\temp\cr\mytest>dir /b
test.csr

You can also debug your code in Visual Studio using a a nifty tool called scaffold which makes the requisite csproj and sln files and conveniently cleans up after we're done:

C:\temp\cr\mytest>..\Scaffold.exe test.csr
Response file 'C:\temp\cr\csc.rsp' processed
File 'C:\temp\cr\mytest\Scaffold_78D592CA\test.csproj' created
File 'C:\temp\cr\mytest\Scaffold_78D592CA\test.csproj.user' created
File 'C:\temp\cr\mytest\Scaffold_78D592CA\test.sln' created
Starting Visual Studio
Waiting for Visual Studio to exit

We can now debug as usual:

When Visual Studio closes:

Sub-directory 'C:\temp\cr\mytest\Scaffold_78D592CA\' was deleted

Code Runner .NET has already been updated to support Visual Studio 2008 so download it from CodePlex now.

Visual Studio Team System Chat – December 5th

colinth — Wed, 21 Nov 2007 22:04:00 GMT

Join members of the Visual Studio Team System product group to discuss features available in Team Foundation Server, Team Suite, Architecture Edition, Development Edition, Database Edition, and Test Edition. In addition, discuss what's new for these editions for Visual Studio 2008.

We will be holding two sessions:

Join the chat on Wednesday, December 5th, 2007 from 10:00am - 11:00am Pacific Time. Add to Calendar | Additional Time Zones

-and-

Join the chat on Wednesday, December 5th, 2007 from 4:00pm - 5:00pm Pacific Time. Add to Calendar | Additional Time Zones

---

I'll be in the Wed 4 pm - 5 pm chat to answer any questions related to profiling. Another member of the profiler team will be online for the earlier chat.

---

Microsoft Blogs I Read

colinth — Tue, 16 Oct 2007 21:50:00 GMT

There are a lot of Microsoft bloggers, literally thousands of them. When I first joined Microsoft I wasn't sure who to read. I've gradually built up a list based on interesting product and feature announcements and people I've met. Here they are:

Profiling

Our Team Blog
IanWho's Blog. Written by a fellow dev on the profiler team, Ian has probably written the most about profiling across the team.
joc's bLog. Written by my bosses' boss.
mgoldin's blog. Written by a senior dev on my team. Find out about the difference between different types of samples etc.
My Code Does What?!. A relatively new blog about profiling by another fellow dev.
scarroll's Blog. Written by my boss.

Technical

bharry's WebLog. Written by a Technical Fellow (read more about this) with a huge amount of experience who has a big focus on TFS.
Greggm's Weblog. Written by a senior dev on the Debugger team. Has many advanced debugger tips.
Mark Russinovich. Mark wrote some cool Sysinternals tools and now blogs some fascinating posts about his investigation into problems he finds everyday just using his PC.
Rico Mariani's Performance Tidbits. Written by a senior Microsoftie who has been here for a long time. Gives tips for analyzing performance and provides guidelines to use in writing .NET code.
ScottGu's Blog. Find out about LINQ, ASP.NET AJAX etc. etc. This blog has many examples including screenshots and source code.
Somasegar's WebLog. As the corporate VP of DevDiv, Soma covers a lot of Visual Studio features and other developer tools.

Other

Microsoft International Tech Jobs. I keep an eye on Microsoft's international opportunities here.
Microsoft's JobsBlog. Discusses many aspects of Microsoft's recruiting. Covers the Vancouver office developments and has tips for prospective Microsofties.

That's just some of the Microsoft blogs I read. Are there other 'must-reads' that I'm missing?

Tools of the Trade

colinth — Thu, 16 Aug 2007 03:38:00 GMT

I've been thinking about what some of the most important tools are for me while coding. Here's a few:

Good IDE - syntax highlighting, integrated builds, source control integration, search facility, debugger and profiler built-in. I use VSTS.
Source control/bug tracking system. I use TFS (typically a dogfood version of TFS).
Windows Task Manager.

I use task manager to:
- View CPU usage
- Kill processes
- Start a new explorer.exe if I ever kill explorer.exe. Do this from the Applications tab.
Process Explorer.

I use Process Explorer like task manager, but it can also:
- Find what process has a handle (e.g. a file) open. This can be handy if you want to delete a file but a process has it locked.
- Find out what DLLs a process has loaded
- List the environment variables for a running process
Process Monitor

I use Process Monitor to record file, registry and process activity. This is very useful when debugging issues in complex programs like VSTS which have a lot of registry interactions.
DebugView

Display debugging output from programs without having to attach a debugger. This is very useful if you want to run your program outside a debugger and still want to see all those debug prints.
Media Player. I like to listen to music while I code.
Outlook. It is somewhat sad that I spend a fair percentage of my day reading emails, scheduling or checking up on meetings and writing notes in an Outlook journal, but I do and so I have Outlook open all the time.
Internet Explorer. I need to use MSDN a lot and do web searches. I also read RSS feeds of relevant blogs with IE.
Regedit.
Remote Desktop. I work on different machines pretty regularly and Remote Desktop makes switching between machines easy.