dotnet/corefx

This repo contains the foundational libraries that make up the .NET Core development stack.

Igor Velikorossov

@RussKie

the full source for .NET Framework is not publicly available

Edinei Cavalcanti

@neiesc

@danielo-unity3d maybe is possible with https://github.com/icsharpcode/ILSpy

Joseph Musser

@jnm2

@neiesc This is for a native .cpp file though.

danielo-unity3d

@danielo-unity3d

And now, with dotnet 3.1.300:

dotnet new console
dotnet build
open VS 2019
"Enable native code debugging"
in Options -> Debugging -> Symbols, I have _NT_SYMBOL_PATH (set to symsrv*symsrv.dll*C:\Windows\Symbols*http://referencesource.microsoft.com/symbols*http://msdl.microsoft.com/download/symbols), then "Microsoft Symbol Servers", then "Nuget.org Symbol Servers". I also have other options as specified here: How to configure Visual Studio for debugging .NET framework
step into Main
try to "navigate up the stack" (click on the calling frames in the call stack window, below the one marked Native to Managed Transition)

I am prompted to load the symbols for C:\Program Files\dotnet\shared\Microsoft.NETCore.App\3.1.4\hostpolicy.dll, which is correctly matched and loaded, but then
I am prompted for f:\workspace\_work\1\s\src\corehost\cli\hostpolicy\coreclr.cpp, but I am unable to find coreclr.cpp in either dotnet/coreclr or dotnet/corefx, but I do find it here dotnet/core-setup (which I have just discovered!)
I now have the following stack, and the sources seem to "line up" pretty accurately (I have checked-out tag v3.1.4, but I'm not sure):

test.dll!test.Program.Main(args = {string[0]}) Line 9
  at C:\Users\danielo\test\Program.cs(9)
[Native to Managed Transition]
hostpolicy.dll!coreclr_t::execute_assembly(argc, argv, managed_assembly_path, exit_code=0x000000a8eb1bed14) Line 152
  at f:\workspace\_work\1\s\src\corehost\cli\hostpolicy\coreclr.cpp(152)
hostpolicy.dll!run_app_for_context(context={...}, argc=0, argv) Line 247
  at f:\workspace\_work\1\s\src\corehost\cli\hostpolicy\hostpolicy.cpp(247)
hostpolicy.dll!run_app(argc=0, argv=0x0000026063316a08) Line 276
  at f:\workspace\_work\1\s\src\corehost\cli\hostpolicy\hostpolicy.cpp(276)
hostpolicy.dll!corehost_main(argc, argv=0x0000026063316a00) Line 390
  at f:\workspace\_work\1\s\src\corehost\cli\hostpolicy\hostpolicy.cpp(390)
hostfxr.dll!execute_app(impl_dll_dir, init, argc=1, argv=0x0000026063316a00) Line 146
  at f:\workspace\_work\1\s\src\corehost\cli\fxr\fx_muxer.cpp(146)
hostfxr.dll!`anonymous namespace'::read_config_and_execute(host_command={...}, host_info, app_candidate, opts, new_argc=1, new_argv=0x0000026063316a00, mode=apphost, out_buffer=0x0000000000000000, buffer_size=0, required_buffer_size=0x0000000000000000) Line 502
  at f:\workspace\_work\1\s\src\corehost\cli\fxr\fx_muxer.cpp(502)
hostfxr.dll!fx_muxer_t::handle_exec_host_command(host_command={...}, host_info={...}, app_candidate={...}, opts={...}, argc=1, argv=0x0000026063316a00, argoff=1, mode=apphost, result_buffer=0x0000000000000000, buffer_size=0, required_buffer_size=0x0000000000000000) Line 952
  at f:\workspace\_work\1\s\src\corehost\cli\fxr\fx_muxer.cpp(952)
hostfxr.dll!fx_muxer_t::execute(host_command={...}, argc=1, argv=0x0000026063316a00, host_info={...}, result_buffer=0x0000000000000000, buffer_size=0, required_buffer_size=0x0000000000000000) Line 541
  at f:\workspace\_work\1\s\src\corehost\cli\fxr\fx_muxer.cpp(541)
hostfxr.dll!hostfxr_main_startupinfo(argc=1, argv=0x0000026063316a00, host_path=0x000002606332cf10, dotnet_root=0x0000026063324b50, app_path=0x000002606331bc10) Line 33
  at f:\workspace\_work\1\s\src\corehost\cli\fxr\hostfxr.cpp(33)
test.exe!exe_start(argc=1, argv=0x0000026063316a00) Line 220
  at f:\workspace\_work\1\s\src\corehost\corehost.cpp(220)
test.exe!wmain(argc, argv=0x0000026063316a00) Line 287
  at f:\workspace\_work\1\s\src\corehost\corehost.cpp(287)
[Inline Frame] test.exe!invoke_main() Line 90
  at d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(90)
test.exe!__scrt_common_main_seh() Line 288
  at d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288)
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()

Just wish I could get this for Framework 4.8...

Joseph Musser

@jnm2

@danielo-unity3d https://github.com/dotnet/runtime/blob/master/src/installer/corehost/cli/hostpolicy/coreclr.cpp

.NET Framework isn't open-source, so you might hit a wall.

danielo-unity3d

@danielo-unity3d

Yeah, it can be found in the dotnet/runtime, since it consolidates all the code from dotnet/coreclr, dotnet/corefx, and dotnet/core-setup

Joseph Musser

@jnm2

Guess that's only interesting if you're using the .NET 5 previews

danielo-unity3d

@danielo-unity3d

Thanks for your time and attention, @jnm2 (and @neiesc and @RussKie).
My questions could easily have gone unanswered.

Jan-Willem Spuij

@jspuij

@danielo-unity3d you need sourcelink for .net core for debugging. The source for sourcelink is here, but there is also a small doc here: https://github.com/dotnet/sourcelink

Oh, that is for adding sourcelink to your nugets, which is useful, but also useful is consuming sourcelink: http://www.aaronstannard.com/visual-studio-sourcelink-setup/

Joseph Musser

@jnm2

SourceLink is for .NET assemblies, not native assemblies.

Jan-Willem Spuij

@jspuij

I was under the impression that it supports c++ as well: https://github.com/dotnet/sourcelink#using-source-link-in-c-projects

Source Link is a language- and source-control agnostic system for providing first-class source debugging experiences for binaries

Joseph Musser

@jnm2

@jspuij Oh, I'm sorry. You're quite right!

Jan-Willem Spuij

@jspuij

Never used it with anything else but c# though. I thought I'd check up on the hostpolicy project. They use cmake, which generates the VS project files and I don't see anything in the makefiles regarding sourcelink. So safe bet that they did not enable sourcelink for the hostpolicy project.

Andy Ayers

@AndyAyersMS

@danielo-unity3d what were you debugging that lead you to want those symbols?

Paul M Cohen

@paul1956

What is the #If for Core 5.0 I have tried #If Not NET5_0 unsuccessfully. What I really want is 5.0 or later if possible

Wraith2

@Wraith2

wouldn't it be !NET50 ?

if you've got something building against 5.0 already one thing you can do is add /bl to the msbuild command so it outputs a binary log and then you can trawl through that and get a full list of all the defined constants. I found that there are NETFRAMEWORK and NETCOREAPP defines that aren't in project files doing this

Paul M Cohen

@paul1956

where in Visual Studio to I add /bl and how do I find and search the binary file, seem like this should be documented somewhere.

Wraith2

@Wraith2

not sure about how you do it in visual studio. there's a store app called structured log viewer to look at the contents

Joseph Musser

@jnm2

To get a binlog, you run 'Developer PowerShell for Visual Studio 2019' from the start menu, cd to the project or solution folder, then type msbuild /bl

If you want a log of Visual Studio design-time builds, you need to install a VSIX: https://github.com/dotnet/project-system-tools#project-system-tools

Search for "Project System Tools" in Visual Studio's extension manager.
But it's more steps than using the command line, so I prefer the command line unless the command line doesn't repro but the IDE does.

@paul1956 Last I checked it was NETCOREAPP5_0. Have you tried that?

There's no facility to check "X or later"

The best you can do is lots of ||, or else define your own symbol in the project file.

Joseph Musser

@jnm2

(I think names like SOME_FEATURE are much nicer to read than NETCOREAPP2_1 || NETCOREAPP3_1)

In the vein of making code say what it does.

Jose

@pepone

Is there any support for OCSP in .NET Core?

Jose

@pepone

public static object? Do()
{
    try
    {
        Task.Delay(1).Wait();
        return null;
    }
    catch (AggregateException ex)
    {
        Debug.Assert(ex.InnerException != null);
        ExceptionDispatchInfo.Capture(ex.InnerException).Throw();
    }
}

Why the compiler complains that not all code paths return a value, isn't enough that Throw has DoesNotReturn attribute

Joseph Musser

@jnm2

isn't enough that Throw has DoesNotReturn attribute

No, this was explicitly ruled out.

Jose

@pepone

that sounds surprising what good does to have this attribute?

Joseph Musser

@jnm2

Here are the language design meeting notes where they decided it: https://github.com/dotnet/csharplang/blob/master/meetings/2019/LDM-2019-07-10.md#doesnotreturn

that sounds surprising what good does to have this attribute?

It only affects nullability tracking of variables in the method

This explains how to use it: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/attributes/nullable-analysis#verify-unreachable-code

Jose

@pepone

Second, the compiler marks any code after a call to that method as unreachable,

that is not true

Joseph Musser

@jnm2

It's meeting notes. They can't be untrue by definition because they were written before the C# feature was.

Oh that's from the docs, sorry.

That does look misleading. I'd file a docs issue at the bottom of the page.

It's a little strong to say "not true" because the compiler marks the code unreachable in a very real sense, for null tracking analysis

You have to understand the context. But it could be worded more clearly.

Jose

@pepone

well, that is one way to read it but, that is not what I understand

Third point clearly about nullables, but First and Second are not according to the doc

I guess because is all about nullable static analysis makes sense to not mention it in all the points

Paul M Cohen

@paul1956

NETCOREAPP5_0 it is thanks

Clinton Ingram

@saucecontrol

btw, you don't need binlogs to get the auto-defines. dotnet build [myproject] -v normal will dump the csc/vbc cmdline, where you can see the /define:... switch value

Paul M Cohen

@paul1956

@saucecontrol thanks

Where communities thrive

People

Repo info

Activity