The post I referred to was about profiling unit-tests, but what I meant was that the approach for doing so was quite similar to what you could use. Here is how:
You have a dll X with code that you would want to profile.
The way to do this is simply to instrument ("Build") that dll with the profiler and then make sure to have that
dll X2 be executed instead of the original X. (The profiler can re-sign dlls so that's not a problem). This may involve manually copying the dll to somewhere else, regasm it or whatever. The profiler doesn't know and it doesn't care. In any case, you just have to make sure that X2 is being used instead of the original X in your VS scenario. Are you with me so far? The profiler builds X2. You must make sure X2 is the one being executed, not X.
When any code in X2 executes then the added timing-code will kick in and start profiling the methods. I doesn't matter how X2 gets executed, not one bit: as soon as code in it does
get executed, it will start recording timing data. Yes, it is X2 itself that does the profiling of itself, not the profiler - it's job is just to build the instrumented X2 version and later display the results.
Now the tricky part is how to get that data out
of X2. The easiest way is to have the profiler running at the same machine, because when X2 starts profiling itself it will attempt to connect to a profiler via a socket connection. When that happens you will see a "X was started" notice in the profiler and then
you can extract profiling information: clean the counters and take a snapshot.
Therefore: if you can just somehow make sure that the instrumented version of your dll is being executed, then profiling will always work.
I hope this works. If not then please write again.