I had a number of problems using VS2008’s profiler today so I thought I’d share my finding to lesson the suffering for others!

I’m working on a solution with a large number of projects all starting from a web project. All of the projects are strongly named. I wanted to use ‘instrumentation’ in order to get the most accurate statistics I could gather.

Problem 1.
When I first tried to launch the profiler it complained that my project was signed. The problem is that instrumentation requires the profiler to inject code into my DLL therefore changing the DLL, thus breaking the signature of the code. Happily it tells you that you can use an instrumentation step to re-sign the DLL.

Problem 2.
Ok, now luckily I’d been here before (and blogged how) so I added the re-sign code and tried again. So it launched (using IIS rather than Cassini) and I navigated around the site and finished the session. However the report was gibberish and contained hex numbers and guids where function and DLL names should be, not good. So it looks like a problem with the pdbs. After setting a number of pdb locations and ensuring the pdbs were serialized correctly I finally decided that the injection of code was upsetting the pdb so I switched off signing for every project.

Problem 3.
Still gibberish. Odd. I went to the ASP net temporary files and delete the lot. Re ran it and hurray something that looks like a profile.

A quick post about a couple of potential gotcha’s with remote debugging in VS2008.

First off, you need to use the remote debugging monitor that ships with VS2008, although they look identical the VS2005 monitor won’t work with VS2008. Next problem is where to find the monitor. In VS2005 it was a separate install on the VS2005 setup disks, in VS2008 it’s installed into the common IDE folder under VS2008 (…Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86). You simply copy the files from there to the machine you want to monitor. As for getting it to use breakpoints and the like then it’s back to the old tricks of remote debugging. Basically to make life easy it’s much better to just rebuild the DLLs you’re interested in and ship them to the target…saves a lot of hassle.

One of my colleagues "recently" converted a win exe tool I use from Visual Studio to be a OneClick install application. This is great since I get the latest version whenever I run the exe. However, when you add an external tool to Visual Studio you only get the choice of a very limited number of extensions. The problem is that OneClick applications are installed using an application link rather than an exe, that’s hidden away from view. To solve this problem I simply created a batch/command file that launches the link, and then added the batch file as the external tool, job done.

Every now and again I rediscover a tip when using Visual Studio, this time I was in SQL Management Studio but the tip is the same nonetheless. If you want to select a column of text (in my case it was a column of periods) then hold down ALT+SHIFT and move your mouse. It may not seem very useful now but I guarantee you’ll need it at some point!

Why is something that is so good, be so bad? My misfortune with this profiler continued today when I wanted to test a DLL…I know whoa don’t try anything too tricky 😉 The DLL in question is signed but the profiler must be injecting code or something because it failed complaining that DLL wasn’t signed. A quick look on the web and sure enough it does de-sign it, and you’re supposed to re-sign in a post instrumentation step. Ok, but what does that mean. Well to save the next person the hassle I had it is this…
<path>sn.exe -R <path to assembly> <path to key file>

I can’t believe this isn’t the de facto way people would performance test so why isn’t that step just built in?

The next problem had me shacking my head in disbelief. I wanted to add a new project to instrument, so I clicked add and a huge non-scrolling dialog opened where my project was about 2 miles below the screen. Good grief, what a rookie error. Luckily I managed to count the number of projects and press the down arrow the corresponding number of times, press space then enter. Come on Microsoft, please test Visual Studio with decent sized projects, please!

I thought I’d share a couple of VS tips related to file paths:

1. Copy full path from the tab
The simplest way to get the full path to a source file is to open the file in the editor and the right-click the source panes tab. One of the options is to copy the full path
2. Quick way to open another file located in the same folder as an existing  source file
When you have a number of source files opened from various locations it can be frustrating to go through the File->Open and navigation process time and again. One trick is to keep open an existing project file located in the folder you want to navigate to. When you select File->Open it will start in the same folder location as the active file in the editor.

Team System is a great suite of tools, providing you can afford it, for developing software. However, it does represent a significant investment to move an existing team of developers onto it. Rather than moving in a "Big bang" approach my current team are progressing in a steady rate by using all Team System editions for development and we’re about to use Foundation Server’s source control. What we didn’t want to do was take all the process guidance, at least not yet. After some annoying problems installing the software, if ever you need to slavishly follow a readme this is it, I finally got the server running. I had been told that you cannot easily use the Source Control without taking the process guidance. Well this is true, but to a lesser extent. To use the Source Control you must create a Team Project and yes that does involve selecting a process. However, once selected you don’t have to switch on any of the policies. What does that mean? Well when you check code in you do get a dialog that allows you to type in extra details, assign work items, etc but since the policies for the process aren’t on, it doesn’t nag or even prompt you. So effectively you have Source Control like Visual Source Safe but with all the juicy advantages of Team System’s Source Control. Now to get someone else to edit my demo project and see how easy it is to work in the, "don’t lock files when checked out" mode. Sounds like utopia but will probably be more like hell!

Visual Studio (VS2005) doesn’t comes with a fair bit of Source Safe integration but it also has some annoying traits.
The default behaviour of checking out a single project is to also check out all the files within it.  Ok it only takes a few mouse clicks to stop this but it’s annoying. However, this is really frustrating when you’re working on a solution with 10s or 100s of projects. So I wrote a quick macro to avoid these issues, and it goes something like this…

Dim currentProject as EnvDTE.Project
for each currentProject in DTE.Solutions.Projects
    DTE.SourceControl.CheckOutItem(currentProject.FullName)
next