jongalloway on master
Update new-projects.md (compare)
onovotny on master
Update RxUI license to reflect … Merge pull request #151 from on… (compare)
Kind of a huge one based on the assumption that you don’t have a bottleneck in your code base
By that I mean that if what is slow is, for example, a hot path using explicit
lock() it won’t save you
But it will be a rather great improuvment for both throughput and memory allocation (so less GC hit => less “freeze the world”)
We just upgraded our dev machines from VS 2017 to VS 2019. Now, during debugging, the "Tasks" View does not work anymore, showing the following message:
Viewing Task information for .NET Core 2.2 is not supported while the process is running. You can either re-target a newer version of the runtime, or view task information for minidumps of .NET Core 2.2.
Actually, the project is targeting .NET Core 2.1 (which is LTS version!), and one of the two affected machines has neither 2.2 SDK nor 2.2 runtime installed.
What's happening here, and how to fix it (except downgrading to VS 2017)?
I ran "Process Explorer" to see what it's doing during this long pause. It appears to be extracting a bunch of DLLs out of my exe? For example it reads from MyApp.exe and then writes to
~\AppData\Local\Temp\.net\MyApp\38d4\PresentationCore.dll (one of the core WPF library DLLs). It does this for all the DLL dependencies of my app.
I'm guessing this is how the new ReadyToRun feature works. I'll go see if I can find more info about it. My app is 180MB, which is large, but not crazy large for an ahead-of-time compiled WPF app I think.
Here's a good quote from the .NET blog:
We expect that some of you will prefer single exe provided by an ahead-of-time compiler, as opposed to the self-extracting-executable approach that we are providing in .NET Core 3.0. The ahead-of-time compiler approach will be provided as part of the .NET 5 release.
@Marv51 As far as I know, Razor is not a runtime. Mono and .NET Core are converging into .NET 5, and Unity is a parallel fork of Mono, so there will be only a single implementation left at the end, so no need for any "net standard" which unifies the implementations.
Libraries like Microsoft.AspNetCore.Authentication.JwtBearer are intentionally released for netcoreapp only, not supporting Net Standard (see aspnet/AspNetCore#16813 for one example), forcing all depending projects to go to netcoreapp instead of supporting netstandard.
netstandard2.1then you target