Geek Answers Handbook

PostSharp problems and debugging?

I made a very simple aspect and found a problem when debugging it (see code). I set a breakpoint on the output of the method and actually gets inside the input method. 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"); } }
+4
source share
4 answers

This usually happens when debugging symbols are outdated or do not match the executable executable.

I use PostSharp and have not seen anything like it before ... Have you tried rebuilding? Or delete the output folder and then create?

Edit:

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

Without the applied aspect, this does not happen. So yes, it looks like something in the post-compiled step is causing the problem.

I will leave this answer here as a clarification of the question. If you think this is not useful, I can also remove it ...

Edit 2: As for the workaround: set a breakpoint on the previous line (and not on the closing shape), and then go to the last line of code in the method ...

+3
source

It could be a PostSharp error. You can report this at http://www.postsharp.org/tracker .

0
source

when searching for solutions to this problem, I came across this topic. I had the same problem and found out something about it.

he LOOK (I really DO NOT KNOW him) that he is connected with the order of things that happen during the assembly process. my idea is this: what happens during build / rebuild (cleaning in my case doesn't matter):

  • assembly assembly
  • create .pdb for them
  • create again, apply postsharp code
  • .pdb are not created again (I think !!)

which would mean: .pdb does not match the code being debugged. why do i think so? well, if I disable postharp on the assembly, everything will be fine. when it is turned on, simple code such as "string str =" test "; are, as Nader Shirazi said," not related to the executable code ". which I cannot agree to.

I'm still looking for a “real” solution. my current workaround, by disabling postharp for the build, is not really satisfactory since I also want to debug aspects. maybee is just a simple setup. I can’t imagine a tool like postharp, which should improve performance and quality, make debugging unsuccessful ... any?

I may be wrong, but how it looks in my case ...

amuses, jens

0
source

It is like PostSharp “injects” code into your methods when compiling a project, so that the line break lines and all line numbers of exceptions are all disabled by the number of lines “X”. You can look at the decompiled .dll and see all the code that PostSharp injected into your code base, which leads to the .pdb files not being synchronized with .dll

0
source

More articles:


All Articles