I have tried .NET Reflector, and the built in VS feature of unchecking “Enable Just My Code” and using the Microsoft symbols server.
Both don’t seem to work properly.
I end up coming across methods where pressing F11 just skips over the line.When I view the variable’s value in the Watch window, it says:
Cannot obtain value of local variable or argument as it is not available at this instruction pointer, possibly because it has been optimized away
I have checked the “Suppress JIT optimizations” but this didn’t help.
I’ve set the config to debug.
I’m using IIS express.
I’m trying to debug the methods in Microsoft.AspNetCore.Internal.DefaultAntiforgery.
Has anyone been able to successfully debug ASP.NET Core source code, if so, how do you do it?
I was just trying to step through the exact same code a couple months ago trying to debug an issue, and having the exact same experience 🙂
Pretty much what Alikont says – some things are optimized away. I was able to figure out what I needed essentially by strategically placing breakpoints when F10/F11 didn’t work, and learning which specific lines of code did not lend themselves to being able to inspect variables (not at a GC safe point) – and just moving the breakpoint, or cautiously pressing F10 a couple times until I could get to a point where I could see the variables.
Maybe it’s possible to somehow swap out and use the debug builds of .net core and all its libraries? Hopefully someone else could chime in on how easy/difficult that would be. I haven’t tried.
On the off chance you’re trying to debug the exact same issue we were having where it says HTTP headers are read only and can no longer be modified – that can happen if you have a form with an anti-forgery token somewhere far down the page, with more than 16KB (I think) of content before it. When the internal buffer ASP.NET Core uses to build the response reaches capacity (again, I think it was something like 16KB, but could be off), it will start streaming the response to the client, at which point it will have streamed the HTTP headers already (putting them in a read-only state). If it encounters a form with an anti-forgery token at that point, it will attempt to write the anti-forgery token as a cookie, but it’s too late since the headers are out the door already. In our case, we were running into it because we usually put modal windows (which occasionally have forms) at the bottom of the page.
You could put the forms earlier, but the more reliable solution which we eventually decided to go with was to generate the anti-forgery token statically by simply calling IAntiforgery.GetAndStoreTokens in the request pipeline middleware, which ensures that an antiforgery token is available on every request. There are some examples of this in their doc where they show how to integrate antiforgery with AngularJS (though we aren’t using it).
If .net assembly is built into “Release” mode some information is lost permanently even before JIT optimizations kick in. The local variable may not even exist in the IL.
You need another path to see the value, e.g. try inspecting this._tokenStore, class fields are not optimizable.
Is it a release build ?
Are you attaching to iis or casini ?
Have you tried this before ?
I’ve just updated the question. I’m using the debug config and IIS express. I haven’t used casini before.
you can always add more lines to the source code. you can serialize the entire variable to JSON or something explicitly at the time you want to see its values and inspect them that way. or log them individually, print them to the console, show them in a pop-up dialog. whatever works best for your situation.
edit: let me back up… you’re manually copying the source into your project from like: https://github.com/aspnet/Antiforgery/blob/master/src/Microsoft.AspNetCore.Antiforgery/Internal/DefaultAntiforgery.cs/ in the first place, right? not trying to debug the references to compiled libraries. if not, start from the real source. recompile the library code yourself so you have full access to it. that’s what it’s there for!
I was using .NET Reflector and then I tried Microsoft symbol server which downloads the .pdb files at runtime as you need them.
I’ll try using the source code itself now.
Best you can do here is to capture the log statements from from .net core. Attach Ilogger to your favorite logging framework and the library will probably tell you what’s wrong.
Would [MethodImpl(MethodImplOptions.NoInlining)] attribute help?
The method cannot be inlined. Inlining is an optimization by which a method call is replaced with the method body.
Or [MethodImpl(MethodImplOptions.NoOptimization)]?
The method is not optimized by the just-in-time (JIT) compiler or by native code generation (see Ngen.exe) when debugging possible code generation problems.
Haven’t actually used it but I’m reading a book “high performance .net code” and the chapter about JIT says use NoInlining if you need to leave a method intact for debugging.
Just log everything to a text document I guess. You can then follow along the code and check what the values were from the log. It’s a hacky solution but it fixes your problem.
Heh, this one is tricky because VS must be bent a bit to do it. Do you have “load all modules, unless excluded” in “Debugging/Symbols” set?
The real problem here is that the documentation is not sufficient, so you actually need to debug framework code. I have been checking the source code too many times, because the documentation was bad or non existing, like just the signature. Microsoft the signature of some methods is not documentation!
if this is important to you, then you can always bring the asp.net core source code locally, and reference the source code directly, like you would a project of yours, not the compiled dlls.
C# devs
null reference exceptions