Debug builds / local debugging?

[Sebazzz]

I'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.

[natemcmaster]

Hi @Sebazzz, I'm working on improvements to this repo and Microsoft.AspNetCore.App to make it easier for you to build and debug locally. Unfortunately, I think the 2.2 code is a bit of a mess. If you've managed to get things building so far, that's great, but you'll likely need to do a bit more to get a debug-able shared framework.

Some questions:

• which branch/tag/commit are you building? The state of the 2.2 code has changed significantly over the last few months.
• what does the project file you are trying to debug look like? It might actually be easier to debug your issue if you are not using Microsoft.AspNetCore.App.
• what do you see in the artifacts/ folder so far? If you only have *.nupkg files, more steps are going to be required to build Microsoft.AspNetCore.App

[Sebazzz]

Hi Nate. I did actually get it working somewhat, though it was rather more an art than a science though 🙃 This gist I made up for myself answers most of your questions:
https://gist.github.com/Sebazzz/67c91b04a43531c85ffb4b58b22006e7
I got as far as the NuGet packages and a working sharedfx installer output zip files. I however couldn't find matching symbol files, so I resorted to manually extracting the libs/pdbs from the symbols NuGet packages to the shared framework folder. After that I was able to debug successfully, but did need to modify my project file and suppress the NuGet errors and warnings.

I did checkout the 2.2.0 tag. The Web project is here.

[Sebazzz]

As from the usability perspective: I don't mind checking out code, but I'd rather not build (primarily because of the large number of artifacts generated). I would like to simply point the build process to debug binaries (which would be a separate download, or NuGet version suffix whatever) and debug with that.

[natemcmaster]

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.

[Sebazzz]

In the best case I'd prefer an approach which wouldn't modify your project but rather use some MSBuild property to link to different binaries. This wouldn't help with the shared framework approach, of course unless the assembly loader would also know to look up the binaries at a different location.

But anything that is better than downloading the source and going through dozens of steps to get it working and debug binaries would already go a long way!

[davidfowl]

@natemcmaster If they were on a different feed I would be fine with that.

[Sebazzz]

Yes that's fine. You would use the debug feed as the primary feed in a local NuGet.config file. That would work perfectly. Include the sources and pdbs in the package as well and you got an all-in-one debug package.

…

________________________________ Van: David Fowler <notifications@github.com> Verzonden: Tuesday, April 16, 2019 7:32:15 PM Aan: aspnet/AspNetCore CC: Sebastiaan Dammann; Comment Onderwerp: Re: [aspnet/AspNetCore] Debug builds / local debugging? (#9350) @natemcmaster<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.luolix.top%2Fnatemcmaster&data=02%7C01%7C%7C7052ba6434f14a4e824508d6c2917a26%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636910327399633258&sdata=xoK1fnZqkzR7RRN%2BYD6dooO6Im5f6WCZBnrk4TeRJA8%3D&reserved=0> If they were on a different feed I would be fine with that. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.luolix.top%2Faspnet%2FAspNetCore%2Fissues%2F9350%23issuecomment-483770248&data=02%7C01%7C%7C7052ba6434f14a4e824508d6c2917a26%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636910327399643263&sdata=3Y1xZnX%2FPvZWdF9FAOfW6UROK3PG1c%2F6xNKFOUjSV5I%3D&reserved=0>, or mute the thread<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.luolix.top%2Fnotifications%2Funsubscribe-auth%2FABXCsd0kg3YS12ZkSSjXErn08_MVxsS5ks5vhgkfgaJpZM4cuHMB&data=02%7C01%7C%7C7052ba6434f14a4e824508d6c2917a26%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636910327399653274&sdata=oGq132koCApMrAcfCp0hj3Mic4sxgD2MWkZOtwvYM9E%3D&reserved=0>.

[natemcmaster]

Having a separate feed isn’t sufficient on its own. NuGet cache uses package ID + package version. Unless we also published debug binaries with a unique package version or id, NuGet cached could easily end up with a non-deterministic mix of debug and release binaries. Setting up a separate build chain for debug packages with same sources but unique package versions wouldn’t be prohibitively difficult to set up, but it’s also not trivial and I don’t know if there is sufficient demand for it yet.

[Sebazzz]

Are there other options to make debugging shared frameworks (or ASP.NET at all) more possible? I can't be the only one who needs to step in the sources.

[natemcmaster]

Another option—the one I’m working on for 3.0—is making it easier to build our source code locally. Other than that, I don’t see any. Either we build a debug build or you do.

I can't be the only one who needs to step in the sources.

As far as I’m aware, source link is working well enough for now for most people. As you mentioned, it has limitations when the compiler has optimized the code. But we can leave this open to see if there is sufficient demand for our team to do more to make debugging .NET easier.

[Sebazzz]

Another option—the one I’m working on for 3.0—is making it easier to build our source code locally. Other than that, I don’t see any. Either we build a debug build or you do.

Build was not really the issue, the instructions and process is sufficiently documented.

The problem was actually getting the binaries and symbols in the right place, so the build process and debugger would pick it up while at the same time trying not to mess up my system-wide state (I don't want to replace my 2.2.0 system-wide binaries). One of the advantages of the local packages folder is that you would just overwrite the - for instance ASP.NET MVC - binaries with your own debug build and revert once you publish, or simply rely on your CI to do the publishing.

Some documentation which shows what you can do to getting it build in the correct way and getting the binaries in the correct place would already help.

[natemcmaster]

Discussed in triage. There might be some debugger settings already available in Visual Studio or as an environment variable which would make source-link and debugging locals work better. I don't know what they are, but @Pilchie might.

Aside from this, we're not sure how we would go able releasing debug binaries in a way that is usable. NuGet and the .NET Core runtime don't provide a way for you to easily switch from a release to debug version.

[Pilchie]

The two things are:

1. Set an environment variable: COMPLUS_ReadyToRun to a value of 0. This will prevent the static ahead of time optimizations from being used, forcing every method to be compiled by the JIT. Note: This can be done in a launch profile.
2. Set the VS Option to "Suppress JIT optimizations on module load" at Tools\Options\Debugging\General. If this is set, and the app is launched under the debugger or attached before the module in question loads, then the JIT will try to generate debuggable code.

This unfortunately does not help cases where the C# compiler does optimizations, but those tend to be a bit less of on issue than inlining, etc.

Please give those a try and let us know how it goes.

[JunTaoLuo]

There doesn't seem to be any pending action items in this issue left and there hasn't been any recent activities.