![Rich Lander [MSFT]](https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/letter-avatar/cb895f2fa6fae6447bab144d4f3ec4b3.svg){kind=avatar}
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 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 |
|---|---|---|
| Debian | 598MB | 264MB |
| Alpine | 493MB | 148MB |
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.
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,
Windows Forms is part of the installer on Linux and Mac too?
No, that’s why they are smaller.
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’…
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.
<NullableContextOptions> is now <Nullable>. This is one of the changes we made from preview to preview for the C# 8 preview chain.
I created a GitHub repository with some test code at: https://github.com/AdamsTaiwan/TestCore3
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.
I had the same issue. Was forced to check “Use previews of the .NET core SDK (requires restart)” checkbox again.
Just tried again with 16.2 and no go. At work I have another machine with 16.3, it does not work either.
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.
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
Awesome!
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
Please provide ApiDiff from the 2.2
We’ll do that for Previerw 8.
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.
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.
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…
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?
No Windows Forms Designer yet?
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.
Thanks, Richard.
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.
Yea stil missing :-(:-(:-(