PostSharp and debugging problems?

Question

I've made a very simple aspect, and found a problem when debugging it (see code). I set a breakpoint on the method exit, and it hits inside "entry" method actually. PostSharp 1.5, Visual Studio 2008 SP1
Is this a known bug, are there any workarounds?

class Program
{
    [MyAspect]
    static void Main(string[] args)
    {
        Console.WriteLine("body");
    } // setting breakpoint here
}

[Serializable]
class MyAspect : OnMethodBoundaryAspect
{
    public override void OnEntry(MethodExecutionEventArgs eventArgs)
    { // hits here actually! (debug mode)
        Console.WriteLine("entry"); // hits here actually! (release mode)
    }

    public override void OnExit(MethodExecutionEventArgs eventArgs)
    {
        Console.WriteLine("exit");
    }
}

Answer 1

Usually this happens when the debugging symbols are out of date or don't match the executable being run.

I use PostSharp and haven't seen anything like this before... Have you tried a rebuild? Or deleting your output folder and then building?

Edit:

So I ran your sample. If you move the MyAspect implementation to another file, when you start debugging the code, the breakpoint becomes unavailable with the message: "The breakpoint will not currently be hit. No executable is associated with this line..."

Without the aspect applied, it doesn't happen. So yes, looks like something in post compile step does cause the issue.

I'll leave this answer here as clarification of the question. If you think its not useful, I can delete it too...

Edit 2: As for workaround: Set the breakpoint to the previous line (not on the closing brace), and then step over the last line of code in the method...

Answer 2

This may be a bug of PostSharp. You can report it to http://www.postsharp.org/tracker.

Answer 3

While searching for solutions for this issue, I stumbled upon this thread. I had the same problem and found out something about it.

It SEEMS (i do not really KNOW it) that it has to do with the order things happen in the build process. my idea is the following of what happens when build/rebuild (cleanup doesn't matter in my case):

• build assemblies
• create .pdb for them
• build again, apply postsharp code
• .pdb's are not created again (i guess!!)

which would mean: the .pdb does not match the code being debugged. why do i think this way? well, if i disable postsharp on the assembly, everything works fine. when it is enable, simple code like "string str = "test"; are, as Nader Shirazie mentioned "not associated with executable code". which i cannot agree.

I am still searching for a "real" solution. my current workaround, disabling postsharp for the assembly, is not really satisfying, as I want to debug the aspects, of course, too. maybee it's just a simple setting. i cannot imagine a tool like postsharp, which shall improve productivity and quality, make debugging fail... anyone?

I can be wrong, but that's how it looks like in my case.

Answer 4

This seems to be because PostSharp "injects" code into your methods when you compile the project so the break point lines and all exceptions line numbers are all off by 'X' amount of lines. You can look at the decompiled .dll and see all of the code that PostSharp has injected into your code base that causes the .pdb files to be out of sync with the .dll