Windows 10: Introducing .NET Multi-platform App UI

Brink · May 19, 2020

You can build anything with .NET. Itâs one of the main reasons millions of developers choose .NET as the platform for their careers, and companies invest for their businesses. With .NET 5 we begin our journey of unifying the .NET platform, bringing .NET Core and Mono/Xamarin together in one base class library (BCL) and toolchain (SDK).

As we consider what building device applications will look like in a unified .NET, we see many devices across multiple platforms used, from Android and iOS to Windows and macOS. To address this need we are excited to announce a new first-class UI framework for doing just that: .NET Multi-platform App UI, affectionately call MAUI.

Let us introduce you to what .NET MAUI is, the MAUI single project developer experience, modern development patterns, and a look at the journey ahead.

What is .NET MAUI

MAUI is an evolution of the increasingly popular Xamarin.Forms toolkit that turns 6 years old this month. For years companies such as UPS, Ernst & Young, and Delta have been leveraging the mobile expertise of Xamarin atop .NET to power their businesses; some since the very beginning. It has also been very successful in helping small businesses maximize their development investment sharing upwards of 95% of their code, and beating their competitors to market. MAUI extends this success on mobile to embrace the desktop making it the best way to build multi-platform applications across both, especially our new devices such as the new Surface Duo.

MAUI simplifies the choices for .NET developers, providing a single stack that supports all modern workloads: Android, iOS, macOS, and Windows. The native features of each platform and UI control are within reach in a simple, cross-platform API for you to deliver no-compromise user experiences while sharing even more code than before.

Single Project Developer Experience

MAUI is built with developer productivity in mind, including the project system and cross-platform tooling that developers need. MAUI simplifies the project structure into a single project to target multiple platforms. This means you can easily deploy to any target that you wish including your desktop, emulators, simulators, or physical devices with a single click. With built-in cross-platform resources you will be able to add any images, fonts, or translation files into the single project, and MAUI will automatically setup native hooks so you can just code. Finally, you will always have access the native underlying operating system APIs and it will be easier than ever with new platform specific integrations. Under platforms you can add source code files for a specific operating system and access the native APIs. With MAUI everything is in one place where you need it to keep you productive.

This delivers:

One project targeting multiple platforms and devices

One location to manage resources such as fonts and images

Multi-targeting to organize your platform-specific code

You master one way to build client apps, the MAUI way, and all platforms are within your reach. Today, Scott Hanselman and I will demo it in action at Build, The Journey to One .NET.

Modern App Patterns

Part of the vision for one .NET is providing developer choice in the areas of personal preferences so you can be most productive using .NET. This manifests in which IDE you use whether Visual Studio 2019, Visual Studio for Mac, or even Visual Studio Code. MAUI will be available in all of those, and support both the existing MVVM and XAML patterns as well as future capabilities like Model-View-Update (MVU) with C#, or even Blazor.

MVVM

Model-View-ViewModel (MVVM) and XAML, the predominant pattern and practice among .NET developers for decades now, are first-class features in MAUI. This will continue to grow and evolve to help make you productive building and maintaining production apps.

Code:

<StackLayout>
<Label Text="Welcome to MAUI!" />
<Button Text="{Binding Text}"
Command="{Binding ClickCommand}" />
</StackLayout>
Click to expand...

Code:

public Command ClickCommand { get; }

public string Text { get; set; } = "Click me";

int count = 0;

void ExecuteClickCommand ()
{
count++;
Text = $"You clicked {count} times.";
}
Click to expand...

MVU

In addition, we are enabling developers to write fluent C# UI and implement the increasingly popular Model-View-Update (MVU) pattern. MVU promotes a one-way flow of data and state management, as well as a code-first development experience that rapidly updates the UI by applying only the changes necessary. For more information about MVU as a pattern, check out this Elm Programming guide and this blog from Thomas Bandt.

Below is a basic counter example in the MVU style written in MAUI.

readonly State<int> count = 0;

Code:

[Body]
View body() => new StackLayout
{
new Label("Welcome to MAUI!"),
new Button(
() => $"You clicked {count} times.",
() => count.Value ++)
)
};
Click to expand...

This pattern is ideally suited for hot reload as you can see below with added styling, gradients, and fonts with instant hot reload from C#.

Both MVVM and MVU deliver the same native applications, performance, and platform fidelity. Developers will be able to choose which style best suits their preference and use case.

Transitioning from Xamarin.Forms to .NET MAUI

Xamarin.Forms developers will hit the ground running with new projects in .NET MAUI, using all the same controls and APIs they have grown to know and love. As we get closer to the MAUI launch, In order to help developers make a smooth transition of existing apps to .NET MAUI we intend to provide try-convert support and migration guides similar to what we have today for migrating to .NET Core.

The .NET MAUI Timeline

We will begin shipping .NET MAUI previews later this year, and target general availability with .NET 6 in November of 2021. MAUI will ship on the same 6 week cadence that Xamarin.Forms has been on. We have published the MAUI roadmap on GitHub and invite you to join us there today!

Whatâs Next for Xamarin and Xamarin.Forms

As part of our .NET unification, Xamarin.iOS and Xamarin.Android will become part of .NET 6 as .NET for iOS and .NET for Android. Because these bindings are projections of the SDKs shipped from Apple and Google, nothing changes there, however build tooling, target framework monikers, and runtime framework monikers will be updated to match all other .NET 6 workloads. Our commitment to keeping .NET developers up-to-date with the latest mobile SDKs is foundational to .NET MAUI and remains firm. When .NET 6 ships, we expect to ship a final release of Xamarin SDKs in their current form that will be serviced for a year. All modern work will at that time shift to .NET 6.

Xamarin.Forms will ship a new major version later this year, and continue to ship minor and service releases every 6 weeks through .NET 6 GA in November 2021. The final release of Xamarin.Forms will be serviced for a year after shipping, and all modern work will shift to .NET MAUI.

Get Involved Today

Join us on this journey to MAUI at our brand new repository dotnet/maui. Be sure to star and watch to get notifications, then join in the discussion of proposals describing how we want to evolve the code base. This is the very beginning of a long journey welding Xamarin and Xamarin.Forms directly into the heart of .NET, and we are excited to do this in the open with you.

Scott Hunter
Director Program Management, .NET
Click to expand...

Source: https://devblogs.microsoft.com/dotne...atform-app-ui/

Tweet

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

:)

Brink · May 19, 2020

Introducing XAML Standard and .NET Standard 2.0

XAML Standard

We are pleased to announce XAML Standard, which is a standards-based effort to unify XAML dialects across XAML based technologies such as UWP and Xamarin.Forms.

XAML Standard is a specification that defines a standard XAML vocabulary. With that vocabulary, frameworks that support XAML Standard can share common XAML-based UI definitions. The goal is for the first version, XAML Standard 1.0, to be available later this year.

Post-specification plans include support of XAML standard in Xamarin.Forms and UWP. You can continue developing your UWP and Xamarin.Forms apps as you do today. When XAML Standard support is enabled, you will be able to reuse and share between the frameworks and expand into more platforms.

To visualize what this support would look like, here’s a side-by-side comparison between today’s XAML in Xamarin.Forms and in UWP:

In the above example – once XAML Standard is supported by Xamarin.Forms, you can use <TextBlock /> and have it supported in a Xamarin.Forms app targeting iOS and Android instead of needing to know and use <Label /> as shown above. In addition to a TextBlock, here are some of the currently proposed items for standardization.

We are at the beginning of a journey that makes it easy for you to reuse your XAML source files between some simple Xamarin.Forms and UWP views. For example – a Settings.xaml page, where you typically have some text, toggle switches and some buttons. You’d only need to design and create one XAML file to describe this UI and that can be used everywhere.

Nothing changes for existing developers – you can continue to use the same APIs you have always used in both frameworks. XAML Standard will help you reuse/share any common UI code that you wish to share between end points.

The XAML Standard v1 draft spec is being defined in the open, we encourage you to start a discussion or give us direct feedback in the GitHub repo here.

.NET Standard 2.0

We are also happy to announce .NET Standard 2.0! .NET Standard is the set of APIs which work in all .NET implementations. A good way to think about it is how HTML5 is today. There are many different browsers which implement HTML parsing and rendering, but the HTML standard is the common glue that holds the web together and allows for interoperability.

.NET Standard was introduced in June of 2016 to bring consistency to the .NET ecosystem. With the .NET Framework, Xamarin & Mono, .NET Core and then UWP, there were many different implementations of .NET and it was very difficult to write code or a library that could work across all of them. Using .NET Standard, and the tooling in Visual Studio, makes it possible to build libraries and NuGet packages that work literally everywhere .NET runs.

The feedback we received on after .NET Standard’s introduction last year was generally phrased as “We like the direction you’re going in, but the set of APIs isn’t large enough to be useful.” The goal with .NET Standard 2.0 is to respond to that feedback and add a large set of .NET’s “greatest hits” into .NET Standard. To do this, we looked at the intersection of APIs between the .NET Framework and Mono. This lead to the 2.0 definition including over 20,000 new APIs and those APIs enable the top 70% of existing NuGet packages to work.

With the addition of .NET Standard 2.0 support for UWP with the Fall Creators Update, .NET developers will be able to share code across all Windows 10 devices, in the cloud and through the rest of the .NET ecosystem. This will also make it easier to reuse existing WinForms and WPF code as many of the most frequently used APIs like DataSet/DataTable, and popularly requested APIs like SqlClient, are now part of .NET Standard 2.0.

You can learn more about .NET Standard here.

Forming the shape of the future

We invite you, the .NET community, to join the discussion and help shape the future of XAML Standard and .NET Standard. You can provide your feedback, both suggestions and issues, at the following locations; .NET Standard on Github and XAML Standard on Github.

Resources:

Github

.NET Standard

XAML Standard

Microsoft Docs

.NET Standard Documentation

Build 2017

Session Video (Presentation Slides)

Ch9 Interview with Tim Heuer, Scott Hunter and Miguel de Icaza

All online Build 2017 Sessions, Presentations and Labs

Click to expand...

Source: Introducing XAML Standard and .NET Standard 2.0 - Building Apps for Windows

Brink · May 19, 2020

Introducing .NET 5

Today, we’re announcing that the next release after .NET Core 3.0 will be .NET 5. This will be the next big release in the .NET family.There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more.

We will introduce new .NET APIs, runtime capabilities and language features as part of .NET 5.

From the inception of the .NET Core project, we’ve added around fifty thousand .NET Framework APIs to the platform. .NET Core 3.0 closes much of the remaining capability gap with .NET Framework 4.8, enabling Windows Forms, WPF and Entity Framework 6. .NET 5 builds on this work, taking .NET Core and the best of Mono to create a single platform that you can use for all your modern .NET code.

We intend to release .NET 5 in November 2020, with the first preview available in the first half of 2020. It will be supported with future updates to Visual Studio 2019, Visual Studio for Mac and Visual Studio Code.

.NET 5 = .NET Core vNext

.NET 5 is the next step forward with .NET Core. The project aims to improve .NET in a few key ways:

Produce a single .NET runtime and framework that can be used everywhere and that has uniform runtime behaviors and developer experiences.

Expand the capabilities of .NET by taking the best of .NET Core, .NET Framework, Xamarin and Mono.

Build that product out of a single code-base that developers (Microsoft and the community) can work on and expand together and that improves all scenarios.

This new project and direction are a game-changer for .NET. With .NET 5, your code and project files will look and feel the same no matter which type of app you’re building. You’ll have access to the same runtime, API and language capabilities with each app. This includes new performance improvements that get committed to corefx, practically daily.

Everything you love about .NET Core will continue to exist:

Open source and community-oriented on GitHub.

Cross-platform implementation.

Support for leveraging platform-specific capabilities, such as Windows Forms and WPF on Windows and the native bindings to each native platform from Xamarin.

High performance.

Side-by-side installation.

Small project files (SDK-style).

Capable command-line interface (CLI).

Visual Studio, Visual Studio for Mac, and Visual Studio Code integration.

Here’s what will be new:

You will have more choice on runtime experiences (more on that below).

Java interoperability will be available on all platforms.

Objective-C and Swift interoperability will be supported on multiple operating systems.

CoreFX will be extended to support static compilation of .NET (ahead-of-time – AOT), smaller footprints and support for more operating systems.

We will ship .NET Core 3.0 this September, .NET 5 in November 2020, and then we intend to ship a major version of .NET once a year, every November:

We’re skipping the version 4 because it would confuse users that are familiar with the .NET Framework, which has been using the 4.x series for a long time. Additionally, we wanted to clearly communicate that .NET 5 is the future for the .NET platform. Calling it .NET 5 makes it the highest version we’ve ever shipped.

We are also taking the opportunity to simplify naming. We thought that if there is only one .NET going forward, we don’t need a clarifying term like “Core”. The shorter name is a simplification and also communicates that .NET 5 has uniform capabilities and behaviors. Feel free to continue to use the “.NET Core” name if you prefer it.

Runtime experiences

Mono is the original cross-platform implementation of .NET. It started out as an open-source alternative to .NET Framework and transitioned to targeting mobile devices as iPhone/iOS and Android devices became popular. Mono is the runtime used as part of Xamarin.

CoreCLR is the runtime used as part of .NET Core. It has been primarily targeted at supporting cloud applications, including the largest services at Microsoft, and now is also being used for Windows desktop, IoT and machine learning applications.

Taken together, the .NET Core and Mono runtimes have a lot of similarities (they are both .NET runtimes after all) but also valuable unique capabilities. It makes sense to make it possible to pick the runtime experience you want. We’re in the process of making CoreCLR and Mono drop-in replacements for one another. We will make it as simple as a build switch to choose between the different runtime options.

The following sections describe the primary pivots we are planning for .NET 5. They provide a clear view on how we plan to evolve the two runtimes individually, and also together.

High throughput and high productivity

From the very beginning, .NET has relied on a just-in-time compiler (JIT) to translate Intermediate Language (IL) code to optimized machine code. Since that time, we’ve built an industry-leading JIT-based managed runtime that is capable of very high throughput and also enabled developer experiences that make programming fast and easy.

JITs are well suited for long-running cloud and client scenarios. They are able to generate code that targets a specific machine configuration, including specific CPU instructions. A JIT can also re-generate methods at runtime, a technique used to JIT quickly while still having the option to produce a highly-tuned version of the code if this becomes a frequently used method.

Our efforts to make ASP.NET Core run faster on the TechEmpower benchmarks is a good example of the power of JIT and our investments in CoreCLR. Our efforts to harden .NET Core for containers also demonstrates the runtime’s ability to dynamically adapt to constrained environments.

Developer tools are another good example where JIT shines, such as with the dotnet watch tool or edit and continue. Tools often require compiling and loading code multiple times in a single process without restarting and need to do it very quickly.

Developers using .NET Core or .NET Framework have primarily relied on JIT. As a result, this experience should seem familiar.

The default experience for most .NET 5 workloads will be using the JIT-based CoreCLR runtime. The two notable exceptions are iOS and client-side Blazor (web assembly) since both require ahead-of-time (AOT) native compilation.

Fast startup, low footprint, and lower memory usage

The Mono Project has spent much of its effort focused on mobile and gaming consoles. A key capability and outcome of that project is an AOT compiler for .NET, based on the industry-leading LLVM compiler project. The Mono AOT compiler enables .NET code to be built into a single native code executable that can run on a machine, much like C++ code. AOT-compiled apps can run efficiently in small places, and trades throughput for startup if needed.

The Blazor project is already using the Mono AOT. It will be one of the first projects to transition to .NET 5. We are using it as one of the scenarios to prove out this plan.

There are two types of AOT solutions:

solutions that require 100% AOT compilation.

solutions where most code is AOT-compiled but where a JIT or interpreter is available and used for code patterns that are not friendly to AOT (like generics).

The Mono AOT supports both cases. The first type of AOT is required by Apple for iOS and some game consoles, typically for security reasons. The second is the preferred choice since it offers the benefits of AOT without any of its drawbacks.

.NET Native is the AOT compiler we use for Windows UWP applications and is an example of the first type of AOT listed above. With that particular implementation, we limited the .NET APIs and capabilities that you can use. We learned from that experience that AOT solutions need to cover the full spectrum of .NET APIs and patterns.

AOT compilation will remain required for iOS, web assembly and some game consoles. We will make AOT compilation an option for applications that are more appliance-like, that require fast startup and/or low footprint.

Fundamentals and overlapping experiences

It is critical that we continue to move forward as an overall platform with startup, throughput, memory use, reliability, and diagnostics. At the same time, it also makes sense to focus our efforts. We’ll invest more in throughput and reliability in CoreCLR while we invest more in startup and size reduction with the Mono AOT compiler. We think that these are good pairings. Throughput and reliability go together as do startup and size reduction.

While there are some characteristics where it makes sense to make different investments, there are others that do not.

Diagnostics capabilities need to be the same across .NET 5, for both functional and performance diagnostics. It is also important to support the same chips and operating systems (with the exception of iOS and web assembly).

We will continue to optimize .NET 5 for each workload and scenario, for whatever makes sense. There will be even greater emphasis on optimizations, particular where multiple workloads have overlapping needs.

All .NET 5 applications will use the CoreFX framework. We will ensure that CoreFX works well in the places it is not used today, which is primarily the Xamarin and client-side Blazor workloads.

All .NET 5 applications will be buildable with the .NET CLI, ensuring that you have common command-line tooling across projects.

C# will move forward in lock-step with .NET 5. Developers writing .NET 5 apps will have access to the latest C# version and features.

The birth of the project

We met as a technical team in December 2018 in Boston to kick off this project. Design leaders from .NET teams (Mono/Xamarin and .NET Core) and also from Unity presented on various technical capabilities and architectural direction.

We are now moving forward on this project as a single team with one set of deliverables. Since December, we have made a lot of progress on a few projects:

Defined a minimal layer that defines the runtime <-> managed code layer, with the goal making >99% of CoreFX common code.

MonoVM can now use CoreFX and its class libraries.

Run all CoreFX tests on MonoVM using the CoreFX implementation.

Run ASP.NET Core 3.0 apps with MonoVM.

Run MonoDevelop and then Visual Studio for Mac on CoreCLR.

Moving to a single .NET implementation raises important questions. What will the target framework be? Will NuGet package compatibility rules be the same? Which workloads should be supported out-of-the-box by the .NET 5 SDK? How does writing code for a specific architecture work? Do we still need .NET Standard? We are working through these issues now and will soon be sharing design docs for you to read and give feedback on.

Closing

The .NET 5 project is an important and exciting new direction for .NET. You will see .NET become simpler but also have broader and more expansive capability and utility. All new development and feature capabilities will be part of .NET 5, including new C# versions.

We see a bright future ahead in which you can use the same .NET APIs and languages to target a broad range of application types, operating systems, and chip architectures. It will be easy to make changes to your build configuration to build your applications differently, in Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps or at the command line.

Richard Lander,
Program Manager, .NET Team
Click to expand...

Source: Introducing .NET 5 | .NET Blog

Tweet

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

Brink · May 19, 2020

Introducing .NET 5

Today, we’re announcing that the next release after .NET Core 3.0 will be .NET 5. This will be the next big release in the .NET family.There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more.

We will introduce new .NET APIs, runtime capabilities and language features as part of .NET 5.

From the inception of the .NET Core project, we’ve added around fifty thousand .NET Framework APIs to the platform. .NET Core 3.0 closes much of the remaining capability gap with .NET Framework 4.8, enabling Windows Forms, WPF and Entity Framework 6. .NET 5 builds on this work, taking .NET Core and the best of Mono to create a single platform that you can use for all your modern .NET code.

We intend to release .NET 5 in November 2020, with the first preview available in the first half of 2020. It will be supported with future updates to Visual Studio 2019, Visual Studio for Mac and Visual Studio Code.

.NET 5 = .NET Core vNext

.NET 5 is the next step forward with .NET Core. The project aims to improve .NET in a few key ways:

Produce a single .NET runtime and framework that can be used everywhere and that has uniform runtime behaviors and developer experiences.

Expand the capabilities of .NET by taking the best of .NET Core, .NET Framework, Xamarin and Mono.

Build that product out of a single code-base that developers (Microsoft and the community) can work on and expand together and that improves all scenarios.

This new project and direction are a game-changer for .NET. With .NET 5, your code and project files will look and feel the same no matter which type of app you’re building. You’ll have access to the same runtime, API and language capabilities with each app. This includes new performance improvements that get committed to corefx, practically daily.

Everything you love about .NET Core will continue to exist:

Open source and community-oriented on GitHub.

Cross-platform implementation.

Support for leveraging platform-specific capabilities, such as Windows Forms and WPF on Windows and the native bindings to each native platform from Xamarin.

High performance.

Side-by-side installation.

Small project files (SDK-style).

Capable command-line interface (CLI).

Visual Studio, Visual Studio for Mac, and Visual Studio Code integration.

Here’s what will be new:

You will have more choice on runtime experiences (more on that below).

Java interoperability will be available on all platforms.

Objective-C and Swift interoperability will be supported on multiple operating systems.

CoreFX will be extended to support static compilation of .NET (ahead-of-time – AOT), smaller footprints and support for more operating systems.

We will ship .NET Core 3.0 this September, .NET 5 in November 2020, and then we intend to ship a major version of .NET once a year, every November:

We’re skipping the version 4 because it would confuse users that are familiar with the .NET Framework, which has been using the 4.x series for a long time. Additionally, we wanted to clearly communicate that .NET 5 is the future for the .NET platform. Calling it .NET 5 makes it the highest version we’ve ever shipped.

We are also taking the opportunity to simplify naming. We thought that if there is only one .NET going forward, we don’t need a clarifying term like “Core”. The shorter name is a simplification and also communicates that .NET 5 has uniform capabilities and behaviors. Feel free to continue to use the “.NET Core” name if you prefer it.

Runtime experiences

Mono is the original cross-platform implementation of .NET. It started out as an open-source alternative to .NET Framework and transitioned to targeting mobile devices as iPhone/iOS and Android devices became popular. Mono is the runtime used as part of Xamarin.

CoreCLR is the runtime used as part of .NET Core. It has been primarily targeted at supporting cloud applications, including the largest services at Microsoft, and now is also being used for Windows desktop, IoT and machine learning applications.

Taken together, the .NET Core and Mono runtimes have a lot of similarities (they are both .NET runtimes after all) but also valuable unique capabilities. It makes sense to make it possible to pick the runtime experience you want. We’re in the process of making CoreCLR and Mono drop-in replacements for one another. We will make it as simple as a build switch to choose between the different runtime options.

The following sections describe the primary pivots we are planning for .NET 5. They provide a clear view on how we plan to evolve the two runtimes individually, and also together.

High throughput and high productivity

From the very beginning, .NET has relied on a just-in-time compiler (JIT) to translate Intermediate Language (IL) code to optimized machine code. Since that time, we’ve built an industry-leading JIT-based managed runtime that is capable of very high throughput and also enabled developer experiences that make programming fast and easy.

JITs are well suited for long-running cloud and client scenarios. They are able to generate code that targets a specific machine configuration, including specific CPU instructions. A JIT can also re-generate methods at runtime, a technique used to JIT quickly while still having the option to produce a highly-tuned version of the code if this becomes a frequently used method.

Our efforts to make ASP.NET Core run faster on the TechEmpower benchmarks is a good example of the power of JIT and our investments in CoreCLR. Our efforts to harden .NET Core for containers also demonstrates the runtime’s ability to dynamically adapt to constrained environments.

Developer tools are another good example where JIT shines, such as with the dotnet watch tool or edit and continue. Tools often require compiling and loading code multiple times in a single process without restarting and need to do it very quickly.

Developers using .NET Core or .NET Framework have primarily relied on JIT. As a result, this experience should seem familiar.

The default experience for most .NET 5 workloads will be using the JIT-based CoreCLR runtime. The two notable exceptions are iOS and client-side Blazor (web assembly) since both require ahead-of-time (AOT) native compilation.

Fast startup, low footprint, and lower memory usage

The Mono Project has spent much of its effort focused on mobile and gaming consoles. A key capability and outcome of that project is an AOT compiler for .NET, based on the industry-leading LLVM compiler project. The Mono AOT compiler enables .NET code to be built into a single native code executable that can run on a machine, much like C++ code. AOT-compiled apps can run efficiently in small places, and trades throughput for startup if needed.

The Blazor project is already using the Mono AOT. It will be one of the first projects to transition to .NET 5. We are using it as one of the scenarios to prove out this plan.

There are two types of AOT solutions:

solutions that require 100% AOT compilation.

solutions where most code is AOT-compiled but where a JIT or interpreter is available and used for code patterns that are not friendly to AOT (like generics).

The Mono AOT supports both cases. The first type of AOT is required by Apple for iOS and some game consoles, typically for security reasons. The second is the preferred choice since it offers the benefits of AOT without any of its drawbacks.

.NET Native is the AOT compiler we use for Windows UWP applications and is an example of the first type of AOT listed above. With that particular implementation, we limited the .NET APIs and capabilities that you can use. We learned from that experience that AOT solutions need to cover the full spectrum of .NET APIs and patterns.

AOT compilation will remain required for iOS, web assembly and some game consoles. We will make AOT compilation an option for applications that are more appliance-like, that require fast startup and/or low footprint.

Fundamentals and overlapping experiences

It is critical that we continue to move forward as an overall platform with startup, throughput, memory use, reliability, and diagnostics. At the same time, it also makes sense to focus our efforts. We’ll invest more in throughput and reliability in CoreCLR while we invest more in startup and size reduction with the Mono AOT compiler. We think that these are good pairings. Throughput and reliability go together as do startup and size reduction.

While there are some characteristics where it makes sense to make different investments, there are others that do not.

Diagnostics capabilities need to be the same across .NET 5, for both functional and performance diagnostics. It is also important to support the same chips and operating systems (with the exception of iOS and web assembly).

We will continue to optimize .NET 5 for each workload and scenario, for whatever makes sense. There will be even greater emphasis on optimizations, particular where multiple workloads have overlapping needs.

All .NET 5 applications will use the CoreFX framework. We will ensure that CoreFX works well in the places it is not used today, which is primarily the Xamarin and client-side Blazor workloads.

All .NET 5 applications will be buildable with the .NET CLI, ensuring that you have common command-line tooling across projects.

C# will move forward in lock-step with .NET 5. Developers writing .NET 5 apps will have access to the latest C# version and features.

The birth of the project

We met as a technical team in December 2018 in Boston to kick off this project. Design leaders from .NET teams (Mono/Xamarin and .NET Core) and also from Unity presented on various technical capabilities and architectural direction.

We are now moving forward on this project as a single team with one set of deliverables. Since December, we have made a lot of progress on a few projects:

Defined a minimal layer that defines the runtime <-> managed code layer, with the goal making >99% of CoreFX common code.

MonoVM can now use CoreFX and its class libraries.

Run all CoreFX tests on MonoVM using the CoreFX implementation.

Run ASP.NET Core 3.0 apps with MonoVM.

Run MonoDevelop and then Visual Studio for Mac on CoreCLR.

Moving to a single .NET implementation raises important questions. What will the target framework be? Will NuGet package compatibility rules be the same? Which workloads should be supported out-of-the-box by the .NET 5 SDK? How does writing code for a specific architecture work? Do we still need .NET Standard? We are working through these issues now and will soon be sharing design docs for you to read and give feedback on.

Closing

The .NET 5 project is an important and exciting new direction for .NET. You will see .NET become simpler but also have broader and more expansive capability and utility. All new development and feature capabilities will be part of .NET 5, including new C# versions.

We see a bright future ahead in which you can use the same .NET APIs and languages to target a broad range of application types, operating systems, and chip architectures. It will be easy to make changes to your build configuration to build your applications differently, in Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps or at the command line.

Richard Lander,
Program Manager, .NET Team
Click to expand...

Source: Introducing .NET 5 | .NET Blog

Tweet

— Twitter API (@user) View on Twiiter

Windows 10: Introducing .NET Multi-platform App UI

Introducing .NET Multi-platform App UI

Introducing .NET Multi-platform App UI

Introducing .NET Multi-platform App UI

Introducing .NET Multi-platform App UI - Similar Threads - Introducing NET Multi

20H1 continues the proud tradition of introducing UI bugs.

Introducing .NET 5

Introducing WinAppDriver UI Recorder

Introducing Microsoft’s new Ad Monetization Platform

NET Framework - NET Core Preview Any developer, any app, any platform

Introducing Unified Update Platform (UUP) for Windows 10

Introducing Unified Update Platform (UUP)

Introducing #EdgeBug: File web platform bugs with a Tweet

Introducing the Microsoft Edge Platform Issue Tracker