Windows 10: Microsoft Announces .NET Standard 2.1

Brink · Nov 5, 2018

Since we shipped .NET Standard 2.0 about a year ago, we’ve shipped two updates to .NET Core 2.1 and are about to release .NET Core 2.2. It’s time to update the standard to include some of the new concepts as well as a number of small improvements that make your life easier across the various implementations of .NET.

Keep reading to learn more about what’s new in this latest release, what you need to know about platform support, governance and coding.

What’s new in .NET Standard 2.1?

In total, about 3k APIs are planned to be added in .NET Standard 2.1. A good chunk of them are brand-new APIs while others are existing APIs that we added to the standard in order to converge the .NET implementations even further.

Here are the highlights:

Span<T>. In .NET Core 2.1 we’ve added Span<T> which is an array-like type that allows representing managed and unmanaged memory in a uniform way and supports slicing without copying. It’s at the heart of most performance-related improvements in .NET Core 2.1. Since it allows managing buffers in a more efficient way, it can help in reducing allocations and copying. We consider Span<T> to be a very fundamental type as it requires runtime and compiler support in order to be fully leveraged. If you want to learn more about this type, make sure to read Stephen Toub’s excellent article on Span<T>.

Foundational-APIs working with spans. While Span<T> is available as a .NET Standard compatible NuGet package (System.Memory) already, adding this package cannot extend the members of .NET Standard types that deal with spans. For example, .NET Core 2.1 added many APIs that allow working with spans, such as Stream.Read(Span<Byte>). Part of the value proposition to add span to .NET Standard is to add theses companion APIs as well.

Reflection emit. To boost productivity, the .NET ecosystem has always made heavy use of dynamic features such as reflection and reflection emit. Emit is often used as a tool to optimize performance as well as a way to generate types on the fly for proxying interfaces. As a result, many of you asked for reflection emit to be included in the .NET Standard. Previously, we’ve tried to provide this via a NuGet package but we discovered that we cannot model such a core technology using a package. With .NET Standard 2.1, you’ll have access to Lightweight Code Generation (LCG) as well as Reflection Emit. Of course, you might run on a runtime that doesn’t support running IL via interpretation or compiling it with a JIT, so we also exposed two new capability APIs that allow you to check for the ability to generate code at all (RuntimeFeature.IsDynamicCodeSupported) as well as whether the generated code is interpreted or compiled (RuntimeFeature.IsDynamicCodeCompiled). This will make it much easier to write libraries that can exploit these capabilities in a portable fashion.

SIMD. .NET Framework and .NET Core had support for SIMD for a while now. We’ve leveraged them to speed up basic operations in the BCL, such as string comparisons. We’ve received quite a few requests to expose these APIs in .NET Standard as the functionality requires runtime support and thus cannot be provided meaningfully as a NuGet package.

ValueTask and ValueTask<T>. In .NET Core 2.1, the biggest feature was improvements in our fundamentals to support high-performance scenarios, which also included making async/await more efficient. ValueTask<T> already exists and allows to return results if the operation completed synchronously without having to allocate a new Task<T>. With .NET Core 2.1 we’ve improved this further which made it useful to have a corresponding non-generic ValueTask that allows reducing allocations even for cases where the operation has to be completed asynchronously, a feature that types like Socket and NetworkStream now utilize. Exposing these APIs in .NET Standard 2.1 enables library authors to benefit from these improvements both, as a consumer, as well as a producer.

DbProviderFactories. In .NET Standard 2.0 we added almost all of the primitives in ADO.NET to allow O/R mappers and database implementers to communicate. Unfortunately, DbProviderFactories didn’t make the cut for 2.0 so we’re adding it now. In a nutshell, DbProviderFactories allows libraries and applications to utilize a specific ADO.NET provider without knowing any of its specific types at compile time, by selecting among registered DbProviderFactory instances based on a name, which can be read from, for example, configuration settings.

General Goodness. Since .NET Core was open sourced, we’ve added many small features across the base class libraries such as System.HashCode for combining hash codes or new overloads on System.String. There are about 800 new members in .NET Core and virtually all of them got added in .NET Standard 2.1.

For more details, you might want to check out the full API diff between .NET Standard 2.1 and .NET Standard 2.0. You can also use apisof.net to quickly check whether a given API will be included with .NET Standard 2.1.

.NET platform support

In case you missed our Update on .NET Core 3.0 and .NET Framework 4.8, we’ve described our support for .NET Framework and .NET Core as follows:
.NET Framework is the implementation of .NET that’s installed on over one billion machines and thus needs to remain as compatible as possible. Because of this, it moves at a slower pace than .NET Core. Even security and bug fixes can cause breaks in applications because applications depend on the previous behavior. We will make sure that .NET Framework always supports the latest networking protocols, security standards, and Windows features.

.NET Core is the open source, cross-platform, and fast-moving version of .NET. Because of its side-by-side nature it can take changes that we can’t risk applying back to .NET Framework. This means that .NET Core will get new APIs and language features over time that .NET Framework cannot. At Build we showed a demo how the file APIs are faster on .NET Core. If we put those same changes into .NET Framework we could break existing applications, and we don’t want to do that.
Given many of the API additions in .NET Standard 2.1 require runtime changes in order to be meaningful, .NET Framework 4.8 will remain on .NET Standard 2.0 rather than implement .NET Standard 2.1. .NET Core 3.0 as well as upcoming versions of Xamarin, Mono, and Unity will be updated to implement .NET Standard 2.1.

Library authors who need to support .NET Framework customers should stay on .NET Standard 2.0. In fact, most libraries should be able to stay on .NET Standard 2.0, as the API additions are largely for advanced scenarios. However, this doesn’t mean that library authors cannot take advantage of these APIs even if they have to support .NET Framework. In those cases they can use multi-targeting to compile for both .NET Standard 2.0 as well as .NET Standard 2.1. This allows writing code that can expose more features or provide a more efficient implementation on runtimes that support .NET Standard 2.1 while not giving up on the bigger reach that .NET Standard 2.0 offers.

For more recommendations on targeting, check out the brand new documentation on cross-platform targeting.

Governance model

The .NET Standard 1.x and 2.0 releases focused on exposing existing concepts. The bulk of the work was on the .NET Core side, as this platform started with a much smaller API set. Moving forward, we’ll often have to standardize brand-new technologies, which means we need to consider the impact on all .NET implementations, not just .NET Core, and including those managed in other communities such as Mono or Unity. Our governance model has been updated to best include all considerations, including:

A .NET Standard review board. To ensure we don’t end up adding large chunks of API surface that cannot be implemented, a review board will sign-off on API additions to the .NET Standard. The board comprises representatives from .NET platform, Xamarin and Mono, Unity and the .NET Foundation and will be chaired by Miguel de Icaza. We will continue to strive to make decisions based on consensus and will leverage Miguel’s extensive expertise and experience building .NET implementations that are supported by multiple parties when needed.

A formal approval process. The .NET Standard 1.x and 2.0 version were largely mechanically derived by computing which APIs existing .NET implementations had in common, which means the API sets were effectively a computational outcome. Moving forward, we are implementing an editorial approach:

Anyone can submit proposals for API additions to the .NET Standard.

New members on standardized types are automatically considered. To prevent accidental fragmentation, we’ll automatically consider all members added by any .NET implementation on types that are already in the standard. The rationale here is that divergence at that the member level is not desirable and unless there is something wrong with the API it’s likely a good addition.

Acceptance requires:

A sponsorship from a review board member. That person will be assigned the issue and is expected to shepherd the issue until it’s either accepted or rejected. If no board member is willing to sponsor the proposal, it will be considered rejected.

A stable implementation in at least one .NET implementation. The implementation must be licensed under an open source license that is compatible with MIT. This will allow other .NET implementations to jump- start their own implementations or simply take the feature as-is.

.NET Standard updates are planned and will generally follow a set of themes. We avoid releases with a large number of tiny features that aren’t part of a common set of scenarios. Instead, we try to define a set of goals that describe what kind of feature areas a particular .NET Standard version provides. This simplifies answering the question which .NET Standard a given library should depend on. It also makes it easier for .NET implementations to decide whether it’s worth implementing a higher version of .NET Standard.

The version number is subject to discussion and is generally a function of how significant the new version is. While we aren’t planning on making breaking changes, we’ll rev the major version if the new version adds large chunks of APIs (like when we doubled the number of APIs in .NET Standard 2.0) or has sizable changes in the overall developer experience (like the added compatibility mode for consuming .NET Framework libraries we added in .NET Standard 2.0).

For more information, take a look at the .NET Standard governance model and the .NET Standard review board.

Summary

The definition of .NET Standard 2.1 is ongoing. You can watch our progress on GitHub and still file requests.

If you want to quickly check whether a specific API is in .NET Standard (or any other .NET platform), you can use apisof.net. You can also use the .NET Portability Analyzer to check whether an existing project or binary can be ported to .NET Standard 2.1.

Happy coding!
Click to expand...

Source: Announcing .NET Standard 2.1 | .NET Blog

Tweet

— Twitter API (@user) View on Twiiter

:)

Brink · Nov 5, 2018

Announcing .NET Standard 2.0

The .NET Standard 2.0 specification is now complete. It is supported in .NET Core 2.0, in the .NET Framework 4.6.1 and later versions, and in Visual Studio 15.3. You can start using .NET Standard 2.0 today.

For the impatient: TL;DR

.NET Standard is for sharing code. .NET Standard is a set of APIs that all .NET implementations must provide to conform to the standard. This unifies the .NET implementations and prevents future fragmentation. It replaces Portable Class Libraries (PCLs) as the tool for building .NET libraries that work everywhere.

Much bigger API Surface: We have more than doubled the set of available APIs from 13k in .NET Standard 1.6 to 32k in .NET Standard 2.0. Most of them are existing .NET Framework APIs. These additions make it much easier to port existing code to .NET Standard, and, by extension, to any .NET implementation of .NET Standard, such as .NET Core 2.0 and the upcoming version of UWP.

.NET Framework compatibility mode: The vast majority of NuGet packages are currently still targeting .NET Framework. Many projects are currently blocked from moving to .NET Standard because not all their dependencies are targeting .NET Standard yet. That’s why we added a compatibility mode that allows .NET Standard projects to reference .NET Framework libraries. While this may not work in all cases (for instance, if the .NET Framework binaries use WPF) we found that with .NET Standard 2.0. So in practice it unblocks many projects.

Broad platform support. .NET Standard 2.0 is supported on the following platforms:

.NET Framework 4.6.1

.NET Core 2.0

Mono 5.4

Xamarin.iOS 10.14

Xamarin.Mac 3.8

Xamarin.Android 7.5

Upcoming version of UWP (expected to ship later this year)

Click to expand...

Read more: Announcing .NET Standard 2.0 | .NET Blog

Brink · Nov 5, 2018

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

Waseemulla S · Nov 5, 2018

Microsoft .NET Framework, Unhandled exception

Hi,

Welcome to Microsoft Community.

I suggest you to un-check and recheck .Net framework 3.5 and .Net framework 4.6 advance series from Windows features.

Try the following steps:

Press Windows + R keys to open Run command.

Type Appwiz.cpl and select "turn Windows feature on or off" from the left

Uncheck .Net framework 3.5 and .Net framework 4.6 advance series.

Restart the computer

Repeat step 1 and 2 and check .Net framework 3.5 and .Net framework 4.6 advance series.

Restart the computer.

Regards,

Windows 10: Microsoft Announces .NET Standard 2.1

Microsoft Announces .NET Standard 2.1

Microsoft Announces .NET Standard 2.1

Microsoft Announces .NET Standard 2.1

Microsoft Announces .NET Standard 2.1 - Similar Threads - Microsoft Announces NET

Announcing .NET 6 Preview 2

Announcing .NET 6 Preview 1

Announcing .NET 5.0 RC 2

Announcing .NET 5.0 RC 1

Announcing .NET 5.0 Preview 1

Announcing .NET Core 3.1 Preview 2

Announcing .NET Core 3.1 Preview 1

Announcing .NET Core 3 Preview 2

Announcing .NET Standard 2.0