Announcing .NET Core 3.0 Release Candidate 1

Rich Lander [MSFT]

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.

29 comments

Discussion is closed. Login to edit/delete existing comments.

  • Erik Ejlskov Jensen 0

    In reality, any bugs now will be fixed in 3.1, scheduled for November.

    • Richard LanderMicrosoft employee 0

      True! You are doing a good job of reading the tea leaves.

  • Carlos Villegas 0

    Kudos!

  • Trust Mutemasango 0

    How many internal Microsoft projects have migrated to .Net Core 3? and how many are in the pipeline to migrate to .net Core 3?
    It dose not inspire confidence when you are trying to install a Microsoft product example SQL Server Management Studio and its requires an older framework. I think the more we you use the more we will.

    • Richard LanderMicrosoft employee 0

      We are working with many teams across Microsoft for .NET Core 3.0 adoption. There was limited adoption of .NET Core at Microsoft during the 1.x period, a little more for 2.x and now the flood gates have opened. Bing is the most public example, but there are lots of teams in Office 365 and Azure using .NET Core or working towards adopting it. We also have a couple people on the team that focus entirely on working with other Microsoft teams, to help them with adoption. Their apps are typically enormous, and have many active customers, so we help them come up with a good plan.

      We had an internal “.NET Core Conference” on campus in the summer. That was very well attended, and was almost entirely Microsoft teams presenting, telling about their journey to adopt .NET Core and about the benefits they saw.

      Naturally, no Microsoft client applications (like SQL Server Management Studio) use .NET Core because we are only just making 3.0 available now, which is the first version to support Windows desktop apps.

      Check out this video about Bing: https://twitter.com/mjsabby/status/1172237992024576001

  • John H 0

    Will Visual Studio eventually be ported to .NET Core / .NET 5 / future ?

    • Daniel Smith 0

      I wish they’d just have a clean break in the next version of Visual Studio (2020?), and go fully .NET 5 and 64-bit. Anyone that needs to use classic .NET could just stick with VS2019 or below.

    • Richard LanderMicrosoft employee 0

      That’s a real possibility, however that’s up the Visual Studio team. For our part, we’re ensuring that we have the right features built to enable Visual Studio (and other apps with similar characteristics) to use .NET Core if they choose to.

    • Uwe Keim 0

      Better they finally provide a 64-bit version before switching frameworks. I care a lot about having a 64-bit version. Not so much about which framework it uses.

  • Jon 0

    Recently the preview installers were changed so that each new one would replace earlier previews. Will the 3.0 release also replace previews or will we need to manually remove the preview or RC versions? (I try to keep the clutter to a minimum…)

    • Kathleen DollardMicrosoft employee 0

      Jon,

      Yes! It will replace the previews with the RTM.

      The new design for the SDK installation is to remove the previous previews and patches within the “feature band”. The feature band is the first two digits (“3.0”) and the first (hundreds) position of the last set of digits. All .NET Core SDKs in the form 3.0.1**, including lower patches, previews, RCs, etc. will overwrite each other.

      If you see any different behavior, you may have encountered a bug and we’d like to know about it.

      Kathleen

  • Sanan Fataliyev 0

    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’.

    • Jefferson Motta 0

      LOL. Open Source for Microsoft means: “Free work force”. Microsoft sells Visual Studio, just like that.

      • Jack B 0

        Lol

    • Fakhrulhilal Maktum 0

      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.

      • Alexandre Dias Simões 0

        Just like that.

    • Richard LanderMicrosoft employee 0

      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).

  • Tony Henrique 0

    Awesome!

  • Maytham Fahmi 0

    Looking forward to it. I am existed to make the first real project with Blazor 🙂 IMO, Blazor with Core 3 has brilliant future.

    • Richard LanderMicrosoft employee 0

      Nice. We think Blazor has a brilliant future, too. It will be really fun to see what everyone builds with it.

  • Zsolt Molnár 0

    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?

Feedback usabilla icon