May 19, 2017 10:00 am

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:

Updated May 19, 2017 10:20 am

Join the conversation

    • Thanks Mike. Just like .NET standard, the goal of XAML Standard is to maximize code sharing for developers between XAML based technologies. We are in the early stages and at this time, we are starting with reconciling dialects between UWP XAML and Xamarin.Forms. In doing that, we do want to ensure that the APIs that form a part of XAML Standard are familiar to XAML developers coming from a WPF/Silverlight background.
      We do believe, it is important for the XAML Standard effort to have a common vocabulary of the most widely used types that XAML developers can comfortably rely on and it means we are working towards ensuring that your WPF XAML code can be brought forward through XAML Standard.
      That said, we are also being careful to make the XAML Standard a useful, modern subset to serve the UI needs of today and tomorrow. Walking the balance here is where we need your inputs.
      For more information, see the principles outlined here – https://github.com/Microsoft/xaml-standard/blob/staging/docs/reviewboard.md#principles

    • In order to serve the widest base, MS-XAML 2006 vocab specs is our starting point for XAML Standard.

  1. I don’t read anything about WPF, which is probably the most-used XAML based framework. Are there any plans to include WPF in these plans or is it considered a legacy framework?

  2. You guys should definitely take advantage of a.net core X-Platform functionality: with 2.0 you can literally get an ASP mvc web app up & running on an Azure VM with about 40 lines of code most of which are docker container calls & getter/setter lines utilizing MS wonderful open source embracing, net framework core libraries, Publicly loving Linux, & amazing API integration & interop…made all the more impressive by using their new Dockery “thin container/wrapper” so I could code on bare metal visual studio on W10, or in Azure VM (Linux or Windows) & have my app perform perfectly when run on any system. Points for integrating such an inclusive, feature rich, interoperable service fabric in Azure; especially the Micro Service Line your growing….. I honestly feel like I’m cheating when I can bundle the few services necessary for a given project & Barely have to type! I love contributing to your GitHub & Insider Builds & alpha/beta testing all MSFT products so I can still do some low level programming & debugging before they’re RTM ready! I love where Microsoft has attached itself & the promises of technological transparency & truly understanding their Partners, Customers, Enthusiasts, & IT Pro/Development Community….. but sometimes I actually miss searching 5000 lines for a missing semi colon on compiler error! 🙂

  3. This is a great start but without conditional xaml compilation it’s not terribly useful except for copying and pasting code – not ideal. We should be able to actually share XAML files between targets of different platforms – Uwp, Xamarin, even WPF. Why the resistance to implementing conditional compilation for can?

    • No resistance. The XAML Standard effort right now is all about standardizing the vocabulary spec across XAML flavors. We completely understand that conditional/platform specific markup will need to be a part of a modern cross-platform standard. It is part of the spec and we are working on it. See proposals being drafted on this here – https://github.com/Microsoft/xaml-standard/issues/14