I have a large code base that takes advantage of AOP (aspect oriented programming). I would like to hide the impact of a particular method.

As I'm currently showing just "Methods with source", I'm hoping there's some way to compile my solution such that the profiler cannot find the source for that particular project. I've attempted compiling just that project in release mode, to no avail.

It's an interesting one this - usually people are concerned when the Profiler *can't* find their source code!

There's no option I can think of to not show source for any specific method.

The Profiler utilises the PDB's to try to locate the source, so removing these may help - but that's global to each assembly rather than giving you any level of control, and in any case, the latest version offers integrated decompilation so you could reconstruct the source even where it not available anywhere (useful for 3rd party DLLs for example)

Indeed. I'm sure mine's not the normal case. I'm mainly just interested as it showing up as: "Collapsed methods without source. To view these methods, [blah, blah]".

Building in release mode took care of the .pdb file not being built, anymore. Even with that, it's still showing the source. It's not just showing the decompiled source; it's showing the source code (with comments, and everything).

I was under the impression that with no .pdb files, it would treat it as it would any other 3rd-party dll (e.g. NHibernate). However, it's somehow being really smart (good for it; bad for me) in locating the source files.

So somehow it's figuring out where the source code is located. Perhaps the dll has references to where it was compiled.

I renamed the folder that the project is in and re-ran the profiler. Now the profiler doesn't list the methods in the project.

I appreciate the tenacity of the profiler when it goes to find source. I would appreciate it more if I could tell it to ignore certain items. Now that I can "hack" to tell it not to look at something, it's not such a big deal. It would be a great feature to add, though.

I don't think we cache the PDB's anywhere - but if there's a copy in your PATH anywhere, or they've been added to the GAC somehow it'll probably still find them. Also if you're profiling directly from the build output it /may/ (I'd need to check) automatically find the source code there.

Hitting a method that it can find source for gives [say] the following:
F:\\source\\classlibrary\\foo.cs

This happens for both dll's that have associated pdb's and those that don't. The only way [I've found] to stop that is to delete the original source directory. If i were a betting man, I'd say that one of the dll's with pdb's is storing the path to the non-pdb'd one.

The current Early Access Program (EAP) builds for the Performance Profiler implement filtering that can be defined by the user.
When viewing the Call-Tree or Method Grid, right-click on a method and the context menu will show some options for defining filters (e.g. Show Only Blah, Hide BlahFoo).