Windows 10: .NET Core 3 for Windows Desktop

Brink · Nov 5, 2019

Intro

In September, we released .NET Core support for building Windows desktop applications, including WPF and Windows Forms. Since then, we have been delighted to see so many developers share their stories of migrating desktop applications (and controls libraries) to .NET Core. We constantly hear stories of .NET Windows desktop developers powering their business with WPF and Windows Forms, especially in scenarios where the desktop shines, including:

UI-dense forms over data (FOD) applications

Responsive low-latency UI

Applications that need to run offline/disconnected

Applications with dependencies on custom device drivers

This is just the beginning for Windows application development on .NET Core. Read on to learn more about the benefits of .NET Core for building Windows applications.

Why Windows desktop on .NET Core?

.NET Core (and in the future .NET 5 that is built on top of .NET Core) will be the future of .NET. We are committed to support .NET Framework for years to come, however it will not be receiving any new features, those will only be added to .NET Core (and eventually .NET 5). To improve Windows desktop stacks and enable .NET desktop developers to benefit from all the updates of the future, we brought Windows Forms and WPF to .NET Core. They will still remain Windows-only technologies because there are tightly coupled dependencies to Windows APIs. But .NET Core, besides being cross-platform, has many other features that can enhance desktop applications.

First of all, all the runtime improvements and language features will be added only to .NET Core and in the future to .NET 5. A good example here is C# 8 that became available in .NET Core 3.0. Besides, the .NET Core versions of Windows Forms and WPF will become a part of the .NET 5 platform. So, by porting your application to .NET Core today you are preparing them for .NET 5.

Also, .NET Core brings deployment flexibility for your applications with new options that are not available in .NET Framework, such as:

Side-by-side deployment. Now you can have multiple .NET Core versions on the same machine and can choose which version each of your apps should target.

Self-contained deployment. You can deploy the .NET Core platform with your applications and become completely independent of your end users environment – your app has everything it needs to run on any Windows machine.

Smaller app sizes. In .NET Core 3 we introduced a new feature called linker (also sometimes referred to as trimmer), that will analyze your code and include in your self-contained deployment only those assemblies from .NET Core that are needed for your application. That way all platform parts that are not used for your case will be trimmed out.

Single .exe files. You can package your app and the .NET Core platform all in one .exe file.

Improved runtime performance. .NET Core has many performance optimizations compared to .NET Framework. When you think about the history of .NET Core, built initially for web and server workloads, it helps to understand if your application may see noticeable benefits from the runtime optimizations. Specifically, desktop applications with heavy dependencies on File I/O, networking, and database operations will likely see improvements to performance for those scenarios. Some areas where you may not notice much change are in UI rendering performance or application startup performance.

By setting the properties <PublishSingleFile>, <RuntimeIdentifier> and <PublishTrimmed> in the project file you’ll be able to deploy a trimmed self-contained application as a single .exe file as it is shown in the example below.

Code:

<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.0</TargetFramework>
<PublishSingleFile>true</PublishSingleFile>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
<PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>
Click to expand...

Differences between .NET Framework desktop and .NET Core desktop

While developing desktop applications, you won’t notice much difference between .NET Framework and .NET Core versions of WPF and Windows Forms. A part of our effort was to provide a functional parity between these platforms in the desktop area and enhance the .NET Core experience in the future. WPF applications are fully supported on .NET Core and ready for you to use, while we are working on minor updates and improvements. For Windows Forms the runtime part is fully ported to .NET Core and the team is working on the Windows Forms Designer. We are planning to get it ready by the fourth quarter of 2020 and for now you can check out the Preview version of the designer in Visual Studio 16.4 Preview 3 or later. Don’t forget to set the checkbox in the Tools->Options->Preview Features->Use the Preview of Windows Forms designer for .NET Core apps and restart the Visual Studio. Please keep in mind that the experience is limited for now since the work on it is in progress.

Breaking changes

There are a few breaking changes between .NET Framework and .NET Core but most of the code related to Windows Forms and WPF areas was ported to Core as-is. If you were using such components as WCF Client, Code Access Security, App Domains, Interop and Remoting, you will need to refactor your code if you want to switch to .NET Core.

Another thing to keep in mind – the default output paths on .NET Core is different from on .NET Framework, so if you have some assumptions in your code about file/folder structure of the running app then it’ll probably fail at runtime.

Also, there are changes in how you configure the .NET features. .NET Core instead of machine.config file uses <something>.runtimeconfig.json file that comes with an application and has the same general purpose and similar information. Some configurations such as system.diagnostics, system.net, or system.servicemodel are not supported, so an app config file will fail to load if it contains any of these sections. This change affects System.Diagnostics tracing and WCF client scenarios which were commonly configured using XML configuration previously. In .NET Core you’ll need to configure them in code instead. To change behaviors without recompiling, consider setting up tracing and WCF types using values loaded from a Microsoft.Extensions.Configuration source or from appSettings.

You can find more information on differences between .NET Core and .NET Framework in the documentation.

Getting Started

Check out these short video tutorials:

Getting started with WPF on .NET Core

Getting started with Windows Forms on .NET Core

Differences between .NET Core and .Net Framework and what to choose for your application

Porting from .NET Framework to .NET Core

First of all, run the Portability Analyzer and if needed, update your code to get a 100% compatibility with .NET Core. Here are instructions on using the Portability Analyzer. We recommend to use a source control or to backup your code before you make any changes to your application in case the refactoring would not go the way you want, and you decide to go back to your initial state.

When your application is fully compatible with .NET Core, you are ready to port it. As a starting point, you can try out a tool we created to help automate converting your .NET Framework project(s) to .NET Core – try-convert.

It’s important to remember that this tool is just a starting point in your journey to .NET Core. It is also not a supported Microsoft product. Although it can help you with some of the mechanical aspects of migration, it will not handle all scenarios or project types. If your solution has projects that the tool rejects or fails to convert, you’ll have to port by hand. No worries, we have plenty of tutorials on how to do it (in the end of this section).

The try-convert tool will attempt to migrate your old-style project files to the new SDK-style and retarget applicable projects to .NET Core. For your libraries we leave it up to you to make a call regarding the platform: weather you’d like to target .NET Core or .NET Standard. You can specify it in your project file by updating the value for <TargetFramework>. Libraries without .NET Core-specific dependencies like WPF or Windows Forms may benefit from targeting .NET Standard:

<TargetFramework>netstandard2.1</TargetFramework>

so that they can be used by callers targeting many different .NET Platforms. On the other hand, if a library uses a feature that requires .NET Core (like Windows desktop UI APIs), it’s fine for the library to target .NET Core:

<TargetFramework>netcoreapp3.0</TargetFramework>

try-convert is a global tool that you can install on your machine, then you can call from CLI:

C:\> try-convert -p <path to your project>

or

C:\> try-convert -w <path to your solution>

As previously mentioned, if the try-convert tool did not work for you, here are materials on how to port your application by hand.

Videos

Simple porting case

Advanced porting case

Documentation

Simple porting case

Advanced porting case (Part 1, Part 2)

Overview of the porting process

Olia Gavrysh
Program Manager, .NET
Click to expand...

Source: https://devblogs.microsoft.com/dotne...ndows-desktop/

Tweet

— Twitter API (@user) View on Twitter
Click to expand...

:)

Brink · Nov 5, 2019

.NET Core 3 and Support for Windows Desktop Applications

At Microsoft Build Live today, we are sharing a first look at our plans for .NET Core 3. The highlight of .NET Core 3 is support for Windows desktop applications, specifically Windows Forms, Windows Presentation Framework (WPF), and UWP XAML. You will be able to run new and existing Windows desktop applications on .NET Core and enjoy all the benefits that .NET Core has to offer.

We are planning on releasing a first preview of .NET Core 3 later this year and the final version in 2019. We will be looking for developers to partner with us, to give us feedback, and to release versions of your applications in the same timeframe as our releases. We think that .NET Core 3.0 will be one of the most exciting .NET releases we’ve ever released.

ASP.NET Core will continue to move forward in parallel and will have a release with .NET Core 3.0. Our commitment to web and cloud applications remains unchanged. At the same time, it’s time to add Windows desktop applications as another supported workload for .NET Core. We have heard many requests for desktop applications with .NET Core and are now sharing our plan to deliver on that. Let’s take a look at that.

Benefits of .NET Core for Desktop

There are many benefits with .NET Core that are great for desktop apps. There are a few that are worth calling out explicitly:

Performance improvements and other runtime updates that will delight your users

Super easy to use or test a new version of .NET Core for just one app on a machine

Enables both machine-global and application-local deployment

Support for the .NET Core CLI tools and SDK-style projects in Visual Studio

We’re also announcing a set of improvements that we’ll be adding to both .NET Core 3.0 and .NET Framework 4.8:

Access to the full Windows 10 (AKA “WinRT”) API.

Ability to host UWP XAML controls in WPF and Windows Forms applications.

Ability to host UWP browser and media controls, enabling modern browser and media content and standards.

.NET Framework 4.8

We’re also announcing our plans for .NET Framework 4.8. after shipping .NET Framework 4.7.2 only a week ago. We expect the next version to be 4.8 and for it to ship in about 12 months. Like the past few releases, the new release will include a set of targeted improvements, including the features you see listed above.

Visualizing .NET Core 3

Let’s take a look at .NET Core 3 in pictorial form.

Support for Windows desktop will be added as a set of “Windows Desktop Packs”, which will only work on Windows. .NET Core isn’t changing architecturally with this new version. We’ll continue to offer a great cross-platform product, focused on the cloud. We have lots of improvements planned for those scenarios that we’ll share later.

From a 1000-meter view, you can think of WPF as a rich layer over DirectX and Windows Forms as thinner layer over GDI Plus. WPF and Windows Forms do a great job of exposing and exercising much of the desktop application functionality in Windows. It’s the C# code in Windows Forms and WPF that we’ll include as a set of libraries with .NET Core 3. Windows functionality, like GDI Plus and DirectX, will remain in Windows.

We’ll also be releasing a new version of .NET Standard at the same time. Naturally, all new .NET Standard APIs will be part of .NET Core 3.0. We have not yet added Span<T>, for example, to the standard. We’ll be doing that in the next version.

C#, F# and VB already work with .NET Core 2.0. You will be able to build desktop applications with any of those three languages with .NET Core 3.

Side-by-side and App-local Deployment

The .NET Core deployment model is one the biggest benefits that Windows desktop developers will experience with .NET Core 3. In short, you can install .NET Core in pretty much any way you want. It comes with a lot of deployment flexibility.

The ability to globally install .NET Core provides much of the same central installation and servicing benefits of .NET Framework, while not requiring in-place updates.

When a new .NET Core version is released, you can update one app on a machine at a time without any concern for affecting other applications. New .NET Core versions are installed in new directories and are not used by existing applications.

For cases where the maximum isolation is required, you can deploy .NET Core with your application. We’re working on new build tools that will bundle your app and .NET Core together as in a single executable, as a new option.

We’ve had requests for deployment options like this for many years, but were never able to deliver those with the .NET Framework. The much more modular architecture used by .NET Core makes these flexible deployment options possible.

Using .NET Core 3 for an Existing Desktop Application

For new desktop applications, we’ll guide everyone to start with .NET Core 3. The more interesting question is what the experience will be like to move existing applications, particularly big ones, to .NET Core 3. We want the experience to be straightforward enough that moving to .NET Core 3 is an easy choice for you, for any application that is in active development. Applications that are not getting much investment and don’t require much change should stay on .NET Framework 4.8.

Quick explanation of our plan:

Desktop applications will need to target .NET Core 3 and recompile.

Project files will need to be updated to target .NET Core 3.

Dependencies will not need to retarget and recompile. There will be additional benefits if you update dependencies.

We intend to provide compatible APIs for desktop applications. We plan to make WPF and Windows Forms side-by-side capable, but otherwise as-is, and make them work on .NET Core. In fact, we have already done this with a number of our own apps and others we have access to.

We have a version of Paint.NET running in our lab. In fact, we didn’t have access to Paint.NET source code. We got the existing Paint.NET binaries working on .NET Core. We didn’t have a special build of WPF available, so we just used the WPF binaries in the .NET Framework directory on our lab machine. As an aside, this exercise uncovered an otherwise unknown bug in threading in .NET Core, which was fixed for .NET Core 2.1. Nice work, Paint.NET!

We haven’t done any optimization yet, but we found that Paint.NET has faster startup on .NET Core. This was a nice surprise.

Similarly, EF6 will be updated to work on .NET Core 3.0, to provide a simple path forward for existing applications using EF6. But we don’t plan to add any major new features to EF6. EF Core will be extended with new features and will remain the recommended data stack for all types of new applications. We will advise that you port to EF Core if you want to take advantage of the new features and improved performance.

There are many design decisions ahead, but the early signs are very good. We know that compatibility will be very important to everyone moving existing desktop applications to .NET Core 3. We will continue to test applications and add more functionality to .NET Core to support them. We will post about any APIs that are hard to support, so that we can get your feedback.

Updating Project Files

With .NET Core projects, we adopted SDK-style projects. One of the key aspects of SDK-style projects is PackageReference, which is a newer way of referencing NuGet packages. PackageReference replaces packages.config. PackageReference also make it possible to reference a whole component area at once, not just a single assembly at a time.

The biggest experience improvements with SDK-style projects are:

Much smaller and cleaner project files

Much friendlier to source control (fewer changes and smaller diffs)

Edit project files in Visual Studio without unloading

NuGet is part of the build and responsive to changes like target framework update

Supports multi-targeting

The first part of adopting .NET Core 3 for desktop projects will be migrating to SDK-style projects. There will be a migration experience in Visual Studio and available at the command line.

An example of an SDK-style project, for ASP.NET Core 2.1, follows. .NET Core 3 project files will look similar.

[table][tr][td][/td] [td]<Project Sdk="Microsoft.NET.Sdk.Web">[/td] [/tr] [tr][td][/td] [td][/td] [/tr] [tr][td][/td] [td] <PropertyGroup>[/td] [/tr] [tr][td][/td] [td] <TargetFramework>netcoreapp2.1</TargetFramework>[/td] [/tr] [tr][td][/td] [td] </PropertyGroup>[/td] [/tr] [tr][td][/td] [td][/td] [/tr] [tr][td][/td] [td] <ItemGroup>[/td] [/tr] [tr][td][/td] [td] <PackageReference Include="Microsoft.AspNetCore.App" />[/td] [/tr] [tr][td][/td] [td] </ItemGroup>[/td] [/tr] [tr][td][/td] [td][/td] [/tr] [tr][td][/td] [td]</Project>[/td] [/tr] [/table]

Controls, NuGet Packages, and Existing Assembly References

Desktop applications often have many dependencies, maybe from a control vendor, from NuGet or binaries that don’t have source any more. It’s not like all of that can be updated to .NET Core 3 quickly or maybe not even at all.

As stated above, we intend to support dependencies as-is. If you are at the Build conference, you will see Scott Hunter demo a .NET Core 3 desktop application that uses an existing 3rd-party control. We will continue testing scenarios like that to validate .NET Core 3 compatibility.

Next Steps

We will start doing the following, largely in parallel:

Test .NET Framework desktop application on .NET Core to determine what prevents them from working easily. We will often do this without access to source code.

Enable you to easily and anonymously share dependency data with us so that we can collect broad aggregate data about applications, basically “crowd voting” on the shape of what .NET Core 3 should be.

Publish early designs so that we can get early feedback from you.

We hope that you will work with us along the way to help us make .NET Core 3 a great release.

Closing

We have been asking for feedback on surveys recently. Thanks so much for filling those out. The response has been incredible, resulting in thousands of responses within the first day. With this last survey, we asked a subset of respondents over Skype for feedback on our plans for .NET Core 3 with (unknown to them) our Build conference slides. The response has been very positive. Based on everything we have read and heard, we believe that the .NET Core 3 feature set its characteristics are on the right track.

Todays news demonstrates a large investment and commitment in Windows desktop applications. You can expect two releases from us in 2019, .NET Core 3 and .NET Framework 4.8. A number of the features are shared between the two releases and some others are only available in .NET Core 3. We think the commonality and the differences provide a great set of choices for moving forward and modernizing your desktop applications.

It is an exciting time to be a .NET developer.
Click to expand...

Source: .NET Core 3 and Support for Windows Desktop Applications | .NET Blog

Brink · Nov 5, 2019

.NET Core 3 and Support for Windows Desktop Applications

At Microsoft Build Live today, we are sharing a first look at our plans for .NET Core 3. The highlight of .NET Core 3 is support for Windows desktop applications, specifically Windows Forms, Windows Presentation Framework (WPF), and UWP XAML. You will be able to run new and existing Windows desktop applications on .NET Core and enjoy all the benefits that .NET Core has to offer.

We are planning on releasing a first preview of .NET Core 3 later this year and the final version in 2019. We will be looking for developers to partner with us, to give us feedback, and to release versions of your applications in the same timeframe as our releases. We think that .NET Core 3.0 will be one of the most exciting .NET releases we’ve ever released.

ASP.NET Core will continue to move forward in parallel and will have a release with .NET Core 3.0. Our commitment to web and cloud applications remains unchanged. At the same time, it’s time to add Windows desktop applications as another supported workload for .NET Core. We have heard many requests for desktop applications with .NET Core and are now sharing our plan to deliver on that. Let’s take a look at that.

Benefits of .NET Core for Desktop

There are many benefits with .NET Core that are great for desktop apps. There are a few that are worth calling out explicitly:

Performance improvements and other runtime updates that will delight your users

Super easy to use or test a new version of .NET Core for just one app on a machine

Enables both machine-global and application-local deployment

Support for the .NET Core CLI tools and SDK-style projects in Visual Studio

We’re also announcing a set of improvements that we’ll be adding to both .NET Core 3.0 and .NET Framework 4.8:

Access to the full Windows 10 (AKA “WinRT”) API.

Ability to host UWP XAML controls in WPF and Windows Forms applications.

Ability to host UWP browser and media controls, enabling modern browser and media content and standards.

.NET Framework 4.8

We’re also announcing our plans for .NET Framework 4.8. after shipping .NET Framework 4.7.2 only a week ago. We expect the next version to be 4.8 and for it to ship in about 12 months. Like the past few releases, the new release will include a set of targeted improvements, including the features you see listed above.

Visualizing .NET Core 3

Let’s take a look at .NET Core 3 in pictorial form.

Support for Windows desktop will be added as a set of “Windows Desktop Packs”, which will only work on Windows. .NET Core isn’t changing architecturally with this new version. We’ll continue to offer a great cross-platform product, focused on the cloud. We have lots of improvements planned for those scenarios that we’ll share later.

From a 1000-meter view, you can think of WPF as a rich layer over DirectX and Windows Forms as thinner layer over GDI Plus. WPF and Windows Forms do a great job of exposing and exercising much of the desktop application functionality in Windows. It’s the C# code in Windows Forms and WPF that we’ll include as a set of libraries with .NET Core 3. Windows functionality, like GDI Plus and DirectX, will remain in Windows.

We’ll also be releasing a new version of .NET Standard at the same time. Naturally, all new .NET Standard APIs will be part of .NET Core 3.0. We have not yet added Span<T>, for example, to the standard. We’ll be doing that in the next version.

C#, F# and VB already work with .NET Core 2.0. You will be able to build desktop applications with any of those three languages with .NET Core 3.

Side-by-side and App-local Deployment

The .NET Core deployment model is one the biggest benefits that Windows desktop developers will experience with .NET Core 3. In short, you can install .NET Core in pretty much any way you want. It comes with a lot of deployment flexibility.

The ability to globally install .NET Core provides much of the same central installation and servicing benefits of .NET Framework, while not requiring in-place updates.

When a new .NET Core version is released, you can update one app on a machine at a time without any concern for affecting other applications. New .NET Core versions are installed in new directories and are not used by existing applications.

For cases where the maximum isolation is required, you can deploy .NET Core with your application. We’re working on new build tools that will bundle your app and .NET Core together as in a single executable, as a new option.

We’ve had requests for deployment options like this for many years, but were never able to deliver those with the .NET Framework. The much more modular architecture used by .NET Core makes these flexible deployment options possible.

Using .NET Core 3 for an Existing Desktop Application

For new desktop applications, we’ll guide everyone to start with .NET Core 3. The more interesting question is what the experience will be like to move existing applications, particularly big ones, to .NET Core 3. We want the experience to be straightforward enough that moving to .NET Core 3 is an easy choice for you, for any application that is in active development. Applications that are not getting much investment and don’t require much change should stay on .NET Framework 4.8.

Quick explanation of our plan:

Desktop applications will need to target .NET Core 3 and recompile.

Project files will need to be updated to target .NET Core 3.

Dependencies will not need to retarget and recompile. There will be additional benefits if you update dependencies.

We intend to provide compatible APIs for desktop applications. We plan to make WPF and Windows Forms side-by-side capable, but otherwise as-is, and make them work on .NET Core. In fact, we have already done this with a number of our own apps and others we have access to.

We have a version of Paint.NET running in our lab. In fact, we didn’t have access to Paint.NET source code. We got the existing Paint.NET binaries working on .NET Core. We didn’t have a special build of WPF available, so we just used the WPF binaries in the .NET Framework directory on our lab machine. As an aside, this exercise uncovered an otherwise unknown bug in threading in .NET Core, which was fixed for .NET Core 2.1. Nice work, Paint.NET!

We haven’t done any optimization yet, but we found that Paint.NET has faster startup on .NET Core. This was a nice surprise.

Similarly, EF6 will be updated to work on .NET Core 3.0, to provide a simple path forward for existing applications using EF6. But we don’t plan to add any major new features to EF6. EF Core will be extended with new features and will remain the recommended data stack for all types of new applications. We will advise that you port to EF Core if you want to take advantage of the new features and improved performance.

There are many design decisions ahead, but the early signs are very good. We know that compatibility will be very important to everyone moving existing desktop applications to .NET Core 3. We will continue to test applications and add more functionality to .NET Core to support them. We will post about any APIs that are hard to support, so that we can get your feedback.

Updating Project Files

With .NET Core projects, we adopted SDK-style projects. One of the key aspects of SDK-style projects is PackageReference, which is a newer way of referencing NuGet packages. PackageReference replaces packages.config. PackageReference also make it possible to reference a whole component area at once, not just a single assembly at a time.

The biggest experience improvements with SDK-style projects are:

Much smaller and cleaner project files

Much friendlier to source control (fewer changes and smaller diffs)

Edit project files in Visual Studio without unloading

NuGet is part of the build and responsive to changes like target framework update

Supports multi-targeting

The first part of adopting .NET Core 3 for desktop projects will be migrating to SDK-style projects. There will be a migration experience in Visual Studio and available at the command line.

An example of an SDK-style project, for ASP.NET Core 2.1, follows. .NET Core 3 project files will look similar.

[table][tr][td][/td] [td]<Project Sdk="Microsoft.NET.Sdk.Web">[/td] [/tr] [tr][td][/td] [td][/td] [/tr] [tr][td][/td] [td] <PropertyGroup>[/td] [/tr] [tr][td][/td] [td] <TargetFramework>netcoreapp2.1</TargetFramework>[/td] [/tr] [tr][td][/td] [td] </PropertyGroup>[/td] [/tr] [tr][td][/td] [td][/td] [/tr] [tr][td][/td] [td] <ItemGroup>[/td] [/tr] [tr][td][/td] [td] <PackageReference Include="Microsoft.AspNetCore.App" />[/td] [/tr] [tr][td][/td] [td] </ItemGroup>[/td] [/tr] [tr][td][/td] [td][/td] [/tr] [tr][td][/td] [td]</Project>[/td] [/tr] [/table]

Controls, NuGet Packages, and Existing Assembly References

Desktop applications often have many dependencies, maybe from a control vendor, from NuGet or binaries that don’t have source any more. It’s not like all of that can be updated to .NET Core 3 quickly or maybe not even at all.

As stated above, we intend to support dependencies as-is. If you are at the Build conference, you will see Scott Hunter demo a .NET Core 3 desktop application that uses an existing 3rd-party control. We will continue testing scenarios like that to validate .NET Core 3 compatibility.

Next Steps

We will start doing the following, largely in parallel:

Test .NET Framework desktop application on .NET Core to determine what prevents them from working easily. We will often do this without access to source code.

Enable you to easily and anonymously share dependency data with us so that we can collect broad aggregate data about applications, basically “crowd voting” on the shape of what .NET Core 3 should be.

Publish early designs so that we can get early feedback from you.

We hope that you will work with us along the way to help us make .NET Core 3 a great release.

Closing

We have been asking for feedback on surveys recently. Thanks so much for filling those out. The response has been incredible, resulting in thousands of responses within the first day. With this last survey, we asked a subset of respondents over Skype for feedback on our plans for .NET Core 3 with (unknown to them) our Build conference slides. The response has been very positive. Based on everything we have read and heard, we believe that the .NET Core 3 feature set its characteristics are on the right track.

Todays news demonstrates a large investment and commitment in Windows desktop applications. You can expect two releases from us in 2019, .NET Core 3 and .NET Framework 4.8. A number of the features are shared between the two releases and some others are only available in .NET Core 3. We think the commonality and the differences provide a great set of choices for moving forward and modernizing your desktop applications.

It is an exciting time to be a .NET developer.
Click to expand...

Source: .NET Core 3 and Support for Windows Desktop Applications | .NET Blog

Brink · Nov 5, 2019

Announcing .NET Core 3 Preview 2

.NET Core 3.0 Preview 2 is now available and it includes a bunch of new updates to ASP.NET Core.

Here's the list of what's new in this preview:

Razor Components

SignalR client-to-server streaming

Pipes on HttpContext

Generic host in templates

Endpoint routing updates

Get started

To get started with ASP.NET Core in .NET Core 3.0 Preview 2 install the .NET Core 3.0 Preview 2 SDK

If you're on Windows using Visual Studio, you'll also want to install the latest preview of Visual Studio 2019.

Upgrade an existing project

To upgrade an existing an ASP.NET Core app to .NET Core 3.0 Preview 2, follow the migrations steps in the ASP.NET Core docs.

Add package for Json.NET

As part of the work to tidy up the ASP.NET Core shared framework, Json.NET is being removed from the shared framework and now needs to be added as a package.

To add back Json.NET support to an ASP.NET Core 3.0 project:

Add a package reference to Microsoft.AspNetCore.Mvc.NewtonsoftJson

Update your ConfigureServices method to include a call to AddNewtonsoftJson().

services.AddMvc()
.AddNewtonsoftJson();

Runtime compilation removed

As a consequence of cleaning up the ASP.NET Core shared framework to not depend on Roslyn, support for runtime compilation of pages and views has also been removed in this preview release. Instead compilation of pages and views is performed at build time. In a future preview update we will provide a NuGet packages for optionally enabling runtime compilation support in an app.

Other breaking changes and announcements

For a full list of other breaking changes and announcements for this release please see the ASP.NET Core Announcements repo...
Click to expand...

Read more:

Announcing .NET Core 3 Preview 2 | .NET Blog

ASP.NET Core updates in .NET Core 3.0 Preview 2 | ASP.NET Blog

Tweet

— Twitter API (@user) View on Twiiter[/quote]

Tweet

— Twitter API (@user) View on Twiiter
Click to expand...

Windows 10: .NET Core 3 for Windows Desktop

.NET Core 3 for Windows Desktop

.NET Core 3 for Windows Desktop

.NET Core 3 for Windows Desktop

.NET Core 3 for Windows Desktop - Similar Threads - NET Core Desktop

Net core 3.1

Announcing .NET Core 3.1 Preview 3

Announcing .NET Core 3 Preview 4

Announcing .NET Core 3 Preview 3

Announcing .NET Core 3 Preview 2

.NET Core 3 Preview 1 and Open Source Windows Desktop Frameworks

Announcing .NET Core 2.2 Preview 3

.NET Core October 2018 Update - NET Core 1.0 and 1.1

.NET Core 3 and Support for Windows Desktop Applications