Debug builds / local debugging?
See original GitHub issueI’m trying to troubleshoot why I’m having authentication issues. For this I need to debug inside the ASP.NET Core libraries. Source link does not suffice because I need to go through many small inlined methods or async methods and the debugger can’t make head or tails of the locals in each method or skips method calls altogether. So I need debug libraries and not the consumable release binaries.
I’m however confused how I can create a local build. I got as far as actually compiling the build and now have a bunch of 2.2.0-rtm-[number] NuGet packages, but how do I consume them from my project which uses the App metapackage which does not specify a version?
Perhaps this is an XY problem. Can I use builds from MyGet instead, are they not optimised?
In the netframework
era it was easy, just compile the aspnetwebstack repo, disable strong name verification and copy the binaries to the local packages solution folder. In netcoreapp1.1
you would simply check out the ASP.NET Core repositories you need and add the projects in the same solution or modify the global.json. Now we got the shared framework and metapackages, but I can’t find any docs how I do the same.
You can’t just point NuGet to the local packages folder because it simply does not find the package, while nuget.exe lists the packages nicely:
MyProject.csproj : warning NU1603: MyProject depends on Microsoft.AspNetCore.App (>= 2.2.0-rtm-190413-99) but Microsoft.AspNetCore.App 2.2.0-rtm-190413-99 was not found. An approximate best match of Microsoft.AspNetCore.App 2.2.0 was resolved.
This appears to be because it is probably looking into that shared-framework directory for this particular version (which it cannot find).
Using and asking for ASP.NET Core 2.2.0 here but I’m also interested in how this will work in netcoreapp3.0 and FrameworkReference based projects.
Issue Analytics
- State:
- Created 4 years ago
- Comments:14 (8 by maintainers)
Glad you got it working. You make an interesting point about publishing debug builds. Currently we only release optimized binaries and symbols.
@Eilon @DamianEdwards @davidfowl what do you think about also producing and making available “debug” binaries/symbols for customers who want a better step-in experience with aspnetcore? Personally, I’ve run into the same issues. Source-link is good, but you can’t set debug points on code that has been optimized away by the compiler.
There doesn’t seem to be any pending action items in this issue left and there hasn’t been any recent activities.