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.
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.
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.
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.
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.
<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!
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.
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