Today, we’re announcing .NET Core 3.0 Release Candidate 1. Just like with Preview 9, we’ve focused on polishing .NET Core 3.0 for a final release. We are now getting very, very close. We intend to release the final version on September 23 at .NET Conf.
Download .NET Core 3.0 RC1 on Windows, macOS, and Linux, available now.
Details:
Why RC1?
The .NET Core 3.0 Preview 9 post stated that Preview 9 would be the last release before the final GA one. We, or at least the tireless writer of these blog posts, were mistaken. And now for the explanation.
For technical and historical reasons, the .NET toolset (compilers, NuGet client, MSBuild, …) is duplicated between Visual Studio and the .NET Core SDK. Important changes were made in the toolset as part of Visual Studio 2019 16.3 Preview 4, also released today. It is critical that the .NET Core SDK version that is part of any Visual Studio release includes the same toolset in order to deliver a compatible experience in all scenarios.
We should have realized that there was a high likelihood that we might need to release changes to accomodate another Visual Studio preview. Making fixes in the .NET toolset like this is standard operating procedure. We could have released a new .NET Core SDK and only delivered it via Visual Studio, however, we’ve broken people in the (now distant) past with that approach. As a result, when we release a new .NET Core SDK, we make it available for everyone in all the places.
Visual Studio Support
.NET Core 3.0 is supported with Visual Studio 2019 16.3 Preview 4 and Visual Studio for Mac 8.3, which were also released today. Please upgrade to it for the best (and supported) experience with .NET Core 3.0 Preview RC1. See Visual Studio 2019 16.3 release notes for more information.
The C# Extension for Visual Studio Code is always updated to support new .NET Core versions. Make sure you have the latest version of the C# extension installed.
Go Live
NET Core 3.0 Preview RC1 is supported by Microsoft and can be used in production. We strongly recommend that you test your app running on Preview RC1 before deploying into production. If you find an issue with .NET Core 3.0, please file a GitHub issue and/or contact Microsoft support.
Closing
The .NET Core 3.0 release is coming close to completion, and the team is solely focused on stability and reliability now that we’re no longer building new features. Please tell us about any issues you find, ideally as quickly as possible. We want to get as many fixes in as possible before we ship the final 3.0 release.
The Windows Forms designer is working in this RC ?
Awesome updates, thanks Richard!
Is there an ETA for Razor support in Visual Studio for Mac? Would love to adopt Blazor for a project, and getting parity with Windows for .razor file support would accelerate adoption.
.Net core 3 RC1 is working very well for me. I have a WPF app ported to RC1.
Suggestion: Could you blog, create sample code or a tool that explains how to use PublishTrimmed = true with a WPF app.
It blows up when trimmed with Exception code: 0xe0434352 in KERNELBASE.dll. There are comments to exclude certain dlls, classes etc from trimming. Is there as easy way or tool to do this for us?
@Richard … can’t believe .NET Core 3.0 is just around corner…
Are there any plans to improve WPF (on .NET Core) for .NET Core 5.0 release; or will WPF stay “as is”?
When will the final version of Visual Studio 2019 16.3 be released? Will it be along with the .Net Core 3.0 release?
“.NET Core 3.0 is supported with Visual Studio 2019 16.3 Preview 4”
Given that release VS 2019 is currently at 16.2.5, how can you claim this is an RC ?
https://visualstudio.microsoft.com/ru/vs/preview/
Actually if you are trying to use Azure Function with Dependency Injection described here: Use dependency injection in .NET Azure Functions and using one of these packages:
Microsoft.EntityFrameworkCore (version 3.0.0-rc1.19456.14)
Microsoft.Extensions.Http.Polly (version 3.0.0-rc1.19456.10)
Then if fails to start and throws an exception:
Method not found: ‘Microsoft.Extensions.DependencyInjection.IServiceCollection Microsoft.Azure.Functions.Extensions.DependencyInjection.IFunctionsHostBuilder.get_Services()’.
Value cannot be null.
Parameter name: provider
It produces the same exception when I use IWebJobStartup directly instead of FunctionStartup.
In order to be able to start to use these packages (of course) you need to update the TargetFramework to netcoreapp3.0.
By default Azure Function projects are created with reference to netcoreapp2.1 in the TargetFramework. The reason why I changed it to netcoreapp3.0 is that I would like to use .NET Core 3.0 RC1 Polly and I have a referenced project where EF Core 3.0 RC1 is referenced.
I could not reference projects that has NuGet packages of .NET Core 3.0 RC1 from a netcoreapp2.1 app because of compatibility issue of .NETStandards,
Is that mean .NET Core 3.0 will be partially supported within Azure Function?
Looking forward to it. I am existed to make the first real project with Blazor 🙂 IMO, Blazor with Core 3 has brilliant future.
Nice. We think Blazor has a brilliant future, too. It will be really fun to see what everyone builds with it.
Awesome!
Hello Richard. I’m happy for this release. But why are you trying to keep .NET Core and Visual Studio IDE tightly closed? In development and even in blogs..
It’s free to choose Visual Studio or sublime text editor or Rider or even command line/vim to develop .NET Core apps.
Title is “Announcing .NET Core 3.0 Release Candidate 1”, but the content repeats “Visual Studio” phrase at least 10 times.
I think Visual Studio shouldn’t be special enough to come up in almost every content about .NET Core.
Most people, including me loved .NET Core because it’s open source, command-line friendly and it doesn’t work only on Windows.
I’m a linux user and it really annoys me. Just spend time on improving CLI for .NET Core. There’s no way to update .NET Core with command line. One have to download it from internet, double click, next..next..
BTW, required disk space to install Visual Studio is more than for mainsteam games’.
Fair comment. There are three reasons (which all boil down to the same thing) why the blog is so Visual Studio centric, some of which is explained in the body of the post:
– It’s not obvious which .NET Core and Visual Studio versions go together, so we need to explain it. This is, in part, based on our policy, on the .NET Team, not to support .NET Core 3.0 with older Visual Studio 2019 dot releases, like 16.2, only 16.3 and forward.
– A significant part of our larger team provides the C#, F# and VB experiences in Visual Studio. We make changes across the whole product (runtime, framework, compiler, toolset, and Visual Studio) that all need to line up in order to make those experiences work correctly. Folks using .NET Core 3.0 in Visual Studio 2019 16.3 are likely enjoying all of these improvements working in concert (potentially without realizing it) .
– The .NET toolset is duplicated between the .NET Core SDK and Visual Studio. If they do not match, then bad things can happen. We have discussed moving to a different model that would make this issue less of an issue, but that’s not reality today, so we need to very clearly describe the requirement to stay at Visual Studio 2019 tip in order to use .NET Core 3.0.
The simple message is that we are very much intending and putting a large effort into making .NET Core and Visual Studio work well together. At the same time, we want .NET Core to work well with any editor/IDE that supports it, and to enable developers to have plenty of choice on the tools and operating systems they use (while still having a great .NET development experience).
Visual studio is the commercial product that they sell. If their product doesn’t support the latest .net core, their customer will complaint. The support for other IDE (like VS code) is separated. You’re free to choose VS or other IDE or event cli version.
Just like that.
LOL. Open Source for Microsoft means: “Free work force”. Microsoft sells Visual Studio, just like that.
Lol