tags:

views:

134

answers:

2

I'm looking for a free code profiler (performance profiler, not a memory profiler) which works for VSTO applications (specifically Excel in my case, but I gather that if it works for one, it should work for all).

I have tried Eqatec Profiler, but it can't seem to launch the application from the profiler (The Run app button is greyed out, which I'm gathering is because the VSTO application is compiled into a dll which runs in-process with Excel.exe).

If anyone has successfully used Eqatec or another free code profiler to profile a VSTO application, I'd be interested to hear how you did it.

A: 

Have you tried Microsoft's CLR Profiler?

I have used it with great success many times.

AMissico
Thanks for your response. I was actually after a performance profiler rather than a memory profiler. I will update the question accordingly.Out of interest, how would one use CLR Profiler to memory profile a VSTO application as there is no exe to run (it compiles to a dll which is launched from excel).
Teevus
The *CLR Profiler* has three components; an GUI executable that reads a log file, a COM component called ProfileObj that generates the log file, and CLR Profiler Control that allows you to control profiling (logging through PInvoke into ProfileObj) through you application. See the Demos folder of the CLRProfilerControl.
AMissico
+1  A: 

What you're doing should be possible with EQATEC Profiler.

When you're simply instrumenting one or more DLLs then there is no distinct "application to run": you simply have some instrumented DLLs, but the profiler doesn't know in what way you intend to use them.

However, the instrumented assemblies are (along with the runtime-module, EQATEC.Profiler.RuntimeFullNet.dll) always completely "self-contained", meaning that they perform the timing themselves as soon as the methods within them are used. So you simply need to have your VSTO app load the DLL as usual and voila, the DLL will itself start accumulating timing information and start listening for a connection from the profiler with which you can then take snapshots etc.

So to summarize:

  1. Build you DLL and keep the profiler running
  2. Have your VSTO app load the DLL (however you do that)
  3. The profiler and instrumented DLL should now be connected (see the Run-tab)
  4. From within the profiler you can now take snapshots

I hope this helps. If not then let me know.

Richard Flamsholt
Apologies for taking so long to respond to your answer... I was moved onto some unrelated tasks and have only just come back to this.I have tried it out using the instructions you have given and it works perfectly.Just to clarify for anyone else reading this, a "snapshot" is not a snapshot of the current state of the application (which is what initially confused me). Rather, it is a snapshot of the measurements that the profiler has taken up to that point. Each snapshot report contains profiling of all method calls from the time of the last snapshot.
Teevus