by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
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