Announcing .NET Core 3.0 Preview 7

Avatar

Richard

Today, we are announcing .NET Core 3.0 Preview 7. We’ve transitioned from creating new features to polishing the release. Expect a singular focus on quality for the remaining preview releases.

Download .NET Core 3.0 Preview 7 right now on Windows, macOS and Linux.

ASP.NET Core and EF Core are also releasing updates today.

Visual Studio users need Visual Studio 2019 16.3 Preview 1 to use .NET Core 3.0 Preview 7.

The Microsoft .NET Site has been updated to .NET Core 3.0 Preview 7 (see the version displayed in the website footer). It’s been running successfully on Preview 7 for over two weeks, on Azure WebApps (as a self-contained app). We will likely move the site to Preview 8 builds in a couple of weeks.

ICYMI, check out the improvements we released in .NET Core 3.0 Preview 6 and the June Update on WPF, both from last month.

Go Live

NET Core 3.0 Preview 7 is supported by Microsoft and can be used in production. We strongly recommend that you test your app running on Preview 7 before deploying Preview 7 into production. If you find an issue with .NET Core 3.0, please file a GitHub issue and/or contact Microsoft support.

We intend to make very few changes after Preview 7 for most APIs. Notable exceptions are: WPF, Windows Forms, Blazor and Entity Framework. Any breaking changes after Preview 7 will be documented.

We are working to ensure a high degree of compatibility with .NET Core 1.x and 2.x apps, making it straightforward to upgrade existing apps to .NET Core 3.0.

.NET Core SDK Size Improvements

The .NET Core SDK is significantly smaller with .NET Core 3.0. The primary reason is that we changed the way we construct the SDK, by moving to purpose-built “packs” of various kinds (reference assemblies, frameworks, templates). In previous versions (including .NET Core 2.2), we constructed the SDK from NuGet packages, which included many artifacts that were not required and wasted a lot of space.

You can see how we calculated these file sizes in the .NET Core 3.0 SDK Size Improvements gist. Detailed instructions are provided so that you can run the same tests in your own environment.

.NET Core 3.0 SDK Size (size change in brackets)

Operating SystemInstaller Size (change)On-disk Size (change)
Windows164MB (-440KB; 0%)441MB (-968MB; -68.7%)
Linux115MB (-55MB; -32%)332MB (-1068MB; -76.2%)
macOS118MB (-51MB; -30%)337MB (-1063MB; -75.9%)

The size improvements for Linux and macOS are dramatic. The improvement for Windows is smaller because we have added WPF and Windows Forms as part of .NET Core 3.0. It’s amazing that we added WPF and Windows Forms in 3.0 and the installer is still (a little bit) smaller.

You can see the same benefit with .NET Core SDK Docker images (here, limited to x64 Debian and Alpine).

Distro2.2 Compressed Size3.0 Compressed Size
Debian598MB264MB
Alpine493MB148MB

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.

We recommend that you start planning to adopt .NET Core 3.0. This recommendation is stronger if you are using containers. The 3.0 improvements for containers are critical for anyone using docker resource limits directly or via an orchestrator.

If you install daily builds, please read an important PSA on .NET Core master branches.

Avatar
Richard Lander

Program Manager, .NET Team

Follow Richard   

38 comments

  • Avatar
    Max Mustermueller

    We can use and build .NET Core WPF and Winforms app even when a third party control dependency targets .NET Framework. But now as we have a “go live” build of .NET Core I wonder how it works with self contained publishing.
    Would it run by itself or does the .NET Core 3 application still requires .NET Framework installed only because a third party dependency has target it. That’s currently my biggest blocker, not many companies provide .NET Core binaries of their control suites yet.

    • Avatar
      Richard Lander

      No .NET Core scenarios require .NET Framework to be installed, including the one you mention. As you say, .NET Core enables you to use .NET Framework assemblies (as an opt-in scenario). This doesn’t use .NET Framework in any way. Give it a try! Look in process explorer to see which binaries are loaded in your app process. It should settle the issue for you.

      • Avatar
        Max Mustermueller

        Nice, I’ve tested it on Windows 7 now after uninstalled .NET Framework 4.7 and self contained WPF .NET Core 3 apps are running out of the box (although they have dependencies on binaries targeting .NET Framework 4.7) But as you said, it looks like they are running on .NET Core anyway.
        So third party depedencies don’t have to target .NET Core specifically. That’s pretty cool.

    • Avatar
      Richard Lander

      We decided to stop using value-oriented terms like RC some time back. The problem is that we have to make the change to “rc” in our build relatively early before we’ve established that it is indeed an RC. There are three things at play: a date, a quality level and avoiding late changes … pick 2. We prioritized the first and the last and then can make a judgement late in a given preview release what the quality level is. We often need to align with a conference or another product so having a fluid date isn’t an option (unless something really bad is discovered).

  • Avatar
    Alexey Leonovich

    “We will likely move the site to Preview 8 builds in a couple of weeks.” – it will be in August 2019.. But .NET Core RC was promised in July 2019 – what is current schedule?
    And BTW: Any plans for making possible to do PublishReadyToRun and PublishTrimmed in Publish window? I mean, we do not use the command line and get inside Visual Studio without editing project file.

      • Avatar
        Alexey Leonovich

        Thx.
        Any plans for making possible to do PublishReadyToRun and PublishTrimmed in Publish window? I mean, we do not use the command line and get inside Visual Studio without editing project file.

  • Avatar
    Max Mustemann

    Any details on why .NET Core 3.0 Preview 7 requires VS 16.3 Preview? When .NET Core 3.0 Preview 7 is “Go Live” and can be used for production, I still would need to use a preview version of Visual Studio that is *not* supported for writing production code.
    However, I tested the .NET Core 3.0 Preview 7 SDK with Visual Studio 16.2 Preview 4 and did not notice any problem, so I’m wondering why that 16.3 requirement is.

    • Avatar
      David Hunter

      I was wondering this as well. If there is some corner case issue with using 16.2 Preview would it be possible to make it give and error and refuse to let you build?

    • Avatar
      Ramon de Klein

      You can compile .NET Core 3.0 preview 7 applications with the toolchain that is supplied with the SDK, so there is no need for VS preview to actually building the code. Writing code with a preview version is no problem for production. If VS preview fails, you can always fall back to Notepad (or any other text editor). It’s just editing text files…

    • Avatar
      Richard Lander

      We expect that almost everything works with VS 16.2 but we don’t test that scenario. .NET Core 3.0 and VS 16.3 will ship together, so that’s the scenario we are focussed on. I’ll clarify that in the Preview 8 blog post.

      New featues like nullable reference types only work correctly in 16.3. We made a lot of changes for Preview 7. There are other features like that.

      We don’t believe that there is any risk in using VS 16.3 Preview from the standpoint of working on production apps. It would be a very special Visual Studio bug that would someone incorrectly change your code, but that would pass through the compiler w/o warnings or errors. Note that the compilers (and other tools like NuGet and MSBuild) in VS 16.3 are the same exact versions as the ones in .NET Core 3.0 Preview 7. Independent of either VS or .NET Core being Preview, unit tests on your side would play an important role in building up your confidence for deploying into production.

  • Behnam Emamian
    Behnam Emamian

    It is good to document the changes: 1)Json librarySystem.Text.Json.Serialization => System.Text.Json 2)JsonSerializer.Parse => JsonSerializer.Deserialize 3) JsonSerializer.ToString => JsonSerializer.Serialize

  • Mark Adamson
    Mark Adamson

    It sounds like we won’t be able to build WPF apps on Linux build servers due to the SDK bundle not including the Desktop SDK. Is that correct? The rest sounds great 🙂

    • Avatar
      Richard Lander

      Right. We did not enable that scenario and we are not testing it. We expect parts of the desktop SDK depends on Windows APIs for build. We understand why people would want this, but it’s not a 3.0 deliverable and not currently on our roadmap.

      • Mark Adamson
        Mark Adamson

        Understood, I hope you can support it in the future, but I’m really looking forward to using .net core 3 anyway. We have other windows build dependencies at the moment anyway, such as Wix for installers

  • Avatar
    Byron Adams

    Is there a documentation of ‘breaking changes’. The api changes do not seem to help.  My app had 0 errors/warnings. Now I get a ton.  I even removed the obj folders, did a restore and rebuild.Here are some:  <NullableContextOptions>enable</NullableContextOptions> in the project file, does it still work. I get CS8627 A nullable type parameter… errorsCS1069 Icon could not be in System.DrawingCS0234 The type or namespace name ‘Forms’ does not exist in the namespace ‘System.Windows’…

    • Avatar
      Raja Venkatesh

      This happened to me too. I had updated VS2019 from 16.1.x to 16.2.0.  That was the issue.
      Solution:
      In VS2019 go to Tools\Options\Environment\Preview Features and select “Use previews of the .NET core SDK (requires restart)” check box.  I had done this in the previous minor version of VS2019 but the new version resets it back.  After checking this option on, the project uses .NET Core 3.0 Preview 7 and compiles fine without any changes in the code.  My code targets WPF apps built using VB.NET.

    • Avatar
      Byron Adams

      I changed <NullableContextOptions> is now <Nullable>, but no change in compiling and no fix suggestions like before.I was able to solve the problem: CS1069: The type name ‘Icon’ could not be found in the namespace ‘System.Drawing’. This type has been forwarded to assembly ‘System.Drawing.Common, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51’ Consider adding a reference to that assembly.After not finding an Add Refenence->Assemblies item. I went to Nuget, but the version is System.Drawing.Common 4.6.0-preview7.19362.9.Now I tried the same with this error: CS0234: The type or namespace name ‘Forms’ does not exist in the namespace ‘System.Windows’ (are you missing an assembly reference?)I thought having <Project Sdk=”Microsoft.NET.Sdk.WindowsDesktop”> and <UseWPF>true</UseWPF> would fix this problem like before.  Went to Nuget and could not find System.Windows.Forms.Should would help if there were some documentation on migrating.

  • Avatar
    Afshin Z

    Any news on the GPIO and IoT stuff? There are tons of boards out there, what boards are supported?
    One more question: Can we use Gamepad/Controllers with .NET Core 3.0? I know UWP supports Xbox One controller, what about .NET Core 3.0?
    Thanks,

Leave a comment