Announcing .NET Core 3.0 Preview 7
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.
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 System||Installer Size (change)||On-disk Size (change)|
|Windows||164MB (-440KB; 0%)||441MB (-968MB; -68.7%)|
|Linux||115MB (-55MB; -32%)||332MB (-1068MB; -76.2%)|
|macOS||118MB (-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).
|Distro||2.2 Compressed Size||3.0 Compressed Size|
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.
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.
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.
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.
Should it be RC instead of preview?
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).
“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.
You can consider Preview 7 the first RC.
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.
No Windows Forms Designer yet?
Yea stil missing :-(:-(:-(
I supposed that WinForms Designer is a Visual Studio functionality (and is the case of it’s updates), isn’t it?
No, it’s deeply tied on components (controls) implementation.
Still working on it. It’s a big project since we’re need to make (half of) the designer out-of-process. We’re not hosting .NET Core within th devenv process. it’s the same project for the WPF/Xaml designer.
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.
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?
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…
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.
Please provide ApiDiff from the 2.2
We’ll do that for Previerw 8.
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
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 🙂
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.
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
Can you please give any clarity around support for C++ / CLI, even if its only for Windows. Thanks!
It’s coming (for Windows), as part of .NET Core 3.0. I’ll include content on that in the Preview 8 blog post.