Windows 10: XAML Islands v1 - Updates and Roadmap for Windows 10

Brink · Jun 13, 2019

At Microsoft Build, we announced that the Windows 10 May 2019 Update (version 1903) would include XAML Islands v1.

Below you can find more details on the roadmap and two workstreams in progress to complete the developer experience: the .NET wrappers and Visual Studio 2019 support.

What are XAML Islands?

XAML Islands enable .NET and native Win32 applications to host UWP XAML controls. You can enhance the experience and functionality of your existing desktop applications with the latest UI innovations previously only available for UWP apps. For example, you can use the UWP XAML controls such as ColorPicker, InkCanvas, CalendarView, and NavigationView in your existing C++ Win32, Windows Forms, and WPF applications.

With XAML Islands you can modernize your app at your own pace without having to rewrite your app–just use the UWP XAML controls.

How can I use XAML Islands?

The first component is the UWP XAML hosting API. This is a set of Windows 10 APIs (Windows Runtime classes and COM interfaces) that are shipped within the Windows 10 version 1903. If you have a native C++ Win32 app that is using the Common Controls library (Comctl32.dll) or MFC and you need to modernize your UI, use these APIs.

The second component consists of the .NET wrapped controls and the host controls. Those are a set of UWP XAML hosting API wrappers in the Windows Community Toolkit for both Windows Forms and WPF developers.

What are the requirements for using XAML Islands in my application?

Windows 10 version 1903 and above: Regardless you have a native Win32 app or a .NET app, this first version of XAML Islands only works on apps running in the Windows 10 version 1903 and above.

Windows 10 SDK version 1903 (10.0.18362): This SDK provides the headers, libraries, metadata, and tools for building Windows 10 apps with XAML Islands.

Packaged desktop app: Desktop apps can be packaged into a MSIX to access certain Windows 10 APIs like live tiles and notifications. To package your desktop app you should use the Windows Application Packaging Project. Packaging your app doesn’t mean that your desktop app will run in the UWP reduced-privileged sandbox. Instead, your packaged Win32 app will run in a full-trust process. Packaged apps with XAML Islands will have a streamlined developer experience with Visual Studio 2019.

Note: Unpackaged apps will have a limited support in this release, but some scenarios will be possible.

Visual Studio 2019: Only Visual Studio 2019 will have the toolchain necessary for building desktop apps with XAML Islands.

.NET Core 3.0: This environment is fully supported for .NET apps. Some scenarios will also work in apps that target the .NET Framework 4.7.2, but there are some limitations for these apps, for example consuming managed 3rd party controls.

What versions of .NET Core and .NET Framework can I target with XAML Islands?

The .NET wrapped controls are supported in .NET Framework and .NET Core 3. The .NET host control (WindowsXamlHost) is available for Windows Forms and WPF. This control allows you to host UWP XAML content. If the UWP XAML content is a control that ships with the Windows 10 platform such as ColorPicker or NavigationView, you can target the .NET Framework 4.7.2 or NET Core 3.

If the UWP XAML content is a UWP user control that is implemented in a 3rd party WinRT component, the version of .NET you can target depends on how the user control was developed. A user control is considered a 3rd party WinRT component if it is defined in one of these ways: in a separate UWP project, in a Nuget Package, or via a link to file.

If the 3rd party WinRT component is native (written in C++/WinRT), the user control can be consumed by both .NET Framework 4.7.2 and the NET Core 3.

If the 3rd party WinRT component is managed (for example, written in C#), the user control can be consumed only by .NET Core 3. The full .NET Framework is not fully supported in this scenario, and it requires some cross compilation to work at all.

This is the matrix of platform support for XAML Islands v1:

If your app targets .NET Core 3, regardless of whether the 3rd party WinRT component you are hosting is native or managed, you will get a streamlined developer experience. If your app targets the full .NET Framework, you will get a streamlined developer experience only if your 3rd party WinRT component is native.

How can I use XAML Islands in my native C++ Win32 app?

If you’re a C++ developer, you need to use the UWP XAML hosting APIs. These are some basic steps:

First initializes the UWP XAML framework in the current thread (you can use the static InitializeForCurrentThread method of the WindowsXamlManager class).

Create a DesktopWindowXamlSource object that requires the HWND of your app. The DesktopWindowXamlSource will create a ChildWindow where you can place the XAML content.

You need to take care of the keyboard focus when users navigate into and out of the XAML Islands. This DesktopWindowXamlSource object exposes event for routing keyboard focus navigation.

You can find more details at: https://docs.microsoft.com/en-us/win...ml-hosting-api

How can I use XAML Islands in my .NET App?

The Windows Community Toolkit version 6.0.0 (in preview right now) provides several NuGet packages for Windows Forms and WPF that you can add to your project.

The WindowXamlHost control is a host control in which you can host all kinds of UWP XAML content.

The wrapped controls wrap most of the events and properties of a small set of specific UWP controls into WPF and Windows Forms controls. These wrapped controls are designed to be used as regular Windows Forms and WPF controls so you don’t need to understand UWP concepts. Currently we provide these wrapped controls:

InkCanvas wraps the UWP InkCanvas and InkToolbar and provides a surface and toolbars for Ink-based user interaction.

MediaPlayerElement enables your .NET apps to use modern audio and video codecs and provide better performance for streaming and rendering media content.

MapControl enables you to use the latest innovations from the mapping platform in your apps, such as more photorealistic maps.

SwapChainPanel (preview) enables you to add DirectX 12 content in your app.

What modern web view controls are available to desktop applications?

Windows Forms and WPF apps use the WebBrowser control, which uses the Internet Explorer rendering engine and therefore lacks support for HTML5 and other features. The Windows Community Toolkit contains a Windows Forms and WPF wrapper for the UWP WebView control that uses Edge as the rendering engine, so these apps can host web content that requires HTML5.

The Windows Community Toolkit also contains the WebViewCompatible control. This control uses either the WebBrowser or the WebView rendering engine, depending on the version of Windows the app is running on:

Apps running on Windows 10, version 1803 and later will use the current WebView rendering engine.

Apps running on earlier versions of Windows, like Windows 8.1, will use the older WebBrowser rendering engine.

Are the XAML Islands using a different thread?

No. XAML Islands run on the same UI thread of your desktop app. You can access all the UWP XAML objects from your code behind without doing any marshalling. This is different from Windows Forms and WPF hosted technologies.

Any samples?

XAML Islands Lab is a comprehensive lab that provides step-by-step instructions for using the wrapped controls and host controls in the Windows Community Toolkit to add UWP controls to an existing WPF line-of-business application. This lab includes the complete code for the WPF application as well as detailed instructions for each step in the process.

This C++ Win32 Sample demonstrates a complete implementation of hosting a UWP user control in an unpackaged C++ Win32 application (that is, an application that is not built into an MSIX package).

For a WPF .NET Core 3 app that consumes a UWP project within a User Control you can use this one:

https://github.com/marb2000/XamlIsla...th_UserControl

The Windows community Toolkit contains demos to validate the wrapped control and the host control.

https://github.com/windows-toolkit/M....Toolkit.Win32

What is your roadmap for XAML Islands v1?

1. Windows 10 May 2019 update contains the first release of XAML Islands (v1).
2. The Windows Community Toolkit, v6.0, will contain the WindowsXamlHost and wrapped controls for the .NET Framework.

This is planned for this Summer of 2019.

There will be a preview of v6.1 that will contain the .NET Core 3 version of the WindowsXamlHost and the wrapped controls. This update will be released to align with the .NET Core 3 release – the second half of 2019.

3. Visual Studio 2019 will get an update in the second half of 2019, aligned with the release of .NET Core 3 that will support XAML Islands v1. Remember that only packaged apps will get a streamlined developer experience.

What is your roadmap for XAML Islands v2?

XAML Islands v2 is intended to ship as a part of WinUI 3.0. Therefore, v2 will support the same Windows 10 versions as WinUI 3.0. We are planning to release v3 major release of WinUI during the first half of 2020. WinUI is an open source project, and you can follow the latest roadmap and news at: https://github.com/microsoft/microso...ocs/roadmap.md

What are the best ways for me to give you feedback about XAML Islands?

The main channel is our GitHub place: https://github.com/microsoft/microsoft-ui-xaml

You can also email us to XAML Islands L: Feedback@microsoft.com

You can tweet us at @windowsui

If you have issues with the .NET wrappers you can also reach us at https://github.com/windows-toolkit/M....Toolkit.Win32

Click to expand...

Source: https://blogs.windows.com/buildingap...s-and-roadmap/

:)

Brink · Jun 13, 2019

XAML Islands - A deep dive Part 1 for Windows App Developers

XAML Islands is a technology that enables Windows developers to use new pieces of UI from the Universal Windows Platform (UWP) on their existing Win32 Applications, including Windows Forms and WPF technologies. This allows them to gradually modernize their apps at their own pace, making use of their current code as much as they want.

Background: How did we get here?

In 2012, with Windows 8, we introduced a new framework to modernize the Win32 APIs called Windows Runtime, with many new UI Controls. These UI Controls were part of the visual framework called XAML, which is part of the Windows Runtime. Back then, if you wanted to use any of these new XAML Controls, you would need to create a new App.

In the middle of 2015, with the introduction of Windows 10, UWP was born. The Universal Windows Platform (UWP) allows you to create apps that work across Windows devices (Xbox, Mobile, HoloLens, Desktop, etc).

In 2015 we announced Project Centennial, later Desktop Bridge, a set of tools that allowed developers to bring their existing apps (Win32) to the Microsoft Store (i.e. the new packaging system), so they could convert, for example, their MSI to an APPX. That was the first step on allowing even more apps to be delivered to customers in a safe and reliable way. Later on, we added even more capabilities to this bridge, allowing developers to enhance their apps leveraging some of the new Windows 10 APIs into their existing apps, like live tiles and notification on the new action center. But still, no new UI controls.

And now, at Build 2018, Kevin Gallo announced that Microsoft would be introducing a way for developers to use the new Windows 10 controls into their current WPF, Windows Forms and native Win32 apps, without fully migrating their apps to the Universal Windows Platform. That was branded as UWP XAML Islands, and it is huge! Now you can have your “Islands” of UWP controls wherever you want inside your WPF apps without rewriting thousands of lines of code.

Who is it for?

XAML Islands are intended for existing Win32 Apps that wants to improve their user experience by leveraging new UWP controls and behaviors but, due to effort or cost being prohibitive, are unable to do a full rewrite of the App. You could already leverage Windows 10 APIs, but up until XAML Islands, only non-UI related APIs.

If you are developing a new Windows App, a UWP App is probably the right approach.
Click to expand...

Read more: XAML Islands - A deep dive - Part 1 - Windows Developer Blog

Tweet

— Twitter API (@User) View on Twiiter

Brink · Jun 13, 2019

XAML Islands - A deep dive Part 2 for Windows App Developers

Welcome to the 2nd post of our Xaml Islands deep dive adventure! On the first blog post, we talked a little bit about the history of this amazing feature, how the Xaml Islands infrastructure works and how to use it, and also a little bit of how you can leverage binding in your Island controls.

On this second blog post, we’ll take a quick look on how to use the wrappers NuGet packages and how to host your custom controls inside Win32 Apps.

Wrappers

Creating custom wrappers around UWP controls can be a cumbersome task, and you probably don’t want to do that. For simple things such as Buttons, it should be fine, but the moment you want to wrap complex controls, it can take a long time. To make things a little bit less complicated, some of our most requested controls are already wrapped for you! The current iteration brings you the InkCanvas, the InkToolbar, the MapControl and the MediaPlayerElement. So now, if your WPF app is running on a Windows 10 machine, you can have the amazing and easy-to-use UWP InkCanvas with an InkToolbar inside your WPF App (or WinForms)! You could even use the InkRecognizer to detect shapes, letters and numbers based on the strokes of that InkCanvas.

How much code does it take to integrate with the InkCanvas? Not much, at all!

[table][tr][td]1 2 3 4 5 6 7 8 9 10 11 12[/td] [td]<Window ... xmlns:uwpControls="clr-namespace:Microsoft.Toolkit.Wpf.UI.Controls;assembly=Microsoft.Toolkit.Wpf.UI.Controls"> <Grid> <Grid.RowDefinitions> <RowDefinition Height="Auto"/> <RowDefinition Height="*"/> </Grid.RowDefinitions> <uwpControls:InkToolbar TargetInkCanvas="{x:Reference Name=inkCanvas}"/> <uwpControls:InkCanvas Grid.Row="1" x:Name="inkCanvas" /> </Grid>[/td] [/tr] [/table]

Most of it is just the Grid definition so, in fact, we added very few lines of code (only 2). And that would give your users an amazing experience that is enabled by XAML Islands and the new UWP Controls.

Custom Control – Managed Code

Everything I explained so far is for platform controls, but what if you want to wrap your own custom UWP UserControl and load it using WindowsXamlHost? Would it work? Yes! XAML controls, when instantiated in the context of an Island, handle resources in a very smart way, meaning that the ms-appx protocol just works, even if you are not running you Win32 process inside a packaged APPX. The root of the ms-appx protocol will map its path to your executable path.

As of right now, you can’t just create a UWP Library and reference it on your WPF or WinForms project, so the whole process of using a custom control is manual. When you develop a UWP App (C#, for example) you are compiling using a UWP flavor of the .NET Core Framework, not the .NET Full Framework. In order for your custom control to work on a WPF or WinForms App that is based on the .NET Full Framework, you must recompile the artifacts of the UWP Library using the .NET Full Framework toolset, by coping them to your WPF/WinForms project. There is a very good documentation about this right here that describes all the necessary steps. Remember that your WPF/WinForms project does not target, by default, any specific Windows 10 version, so you need to manually add references to some WinMD and DLLs files. Again, this is all covered in Enhance your desktop application for Windows 10, which describes how to use Windows 10 APIs on your Desktop Bridge Win32 App. By referencing the WinMDs and DLLs, you will also be able to build this compilation artifacts from the UWP Library on the WPF/WinForms project (.NET Full Framework).

NOTE: There is a whole different process for native code (C++/WinRT), which I’m not going to get into the details in this blog post.

You also can’t build these artifacts as-is. You need to inform the build system to disable type information reflection and x:Bind diagnostics. That’s because the generated code won’t be compatible with the .NET Framework. You can make it work by adding these properties to your UWP Library project:

[table][tr][td]1 2 3 4[/td] [td]<PropertyGroup> <EnableTypeInfoReflection>false</EnableTypeInfoReflection> <EnableXBindDiagnostics>false</EnableXBindDiagnostics> </PropertyGroup>[/td] [/tr] [/table]

Now, you could just manually copy the required files to the WPF/WinForms project, but then you would have multiple copies of it. You can automate that process with a post-build step, just like the documentation does it. If you do it that way though, it will not work if you try to pack your app inside an APPX, because the files will not get copied. To improve that, I created a custom MSBuild snippet that does that for you. The advantage of the Microsoft Build snippet is that is adds the CSharp files as well as the compilation outputs from the library all in the right place. All you must do is copy this script and it will just work.

NOTE: Keep in mind that this will be handled by the Visual Studio in the future, so you’ll have to remove either solution whenever that happens.

This is the snippet:

[table][tr][td]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22[/td] [td]<PropertyGroup> <IslandPath Condition="$(IslandPath) == ''">..\$(IslandLibrary)</IslandPath> <IslandDirectoryName>$([System.IO.Path]::GetFileName($(IslandPath.TrimEnd('\'))))</IslandDirectoryName> </PropertyGroup> <ItemGroup> <IslandLibraryCompile Include="$(IslandPath)\**\*.xaml.cs;$(IslandPath)\obj\$(Configuration)\**\*.g.cs;$(IslandPath)\obj\$ (Configuration)\**\*.g.i.cs"/> </ItemGroup> <ItemGroup> <Compile Include="@(IslandLibraryCompile)"> <LinkBase>$(IslandDirectoryName)\%(RecursiveDir)</LinkBase> </Compile> </ItemGroup> <ItemGroup> <IslandLibraryContent Include="$(IslandPath)\**\*.*" Exclude="$(IslandPath)\**\*.user;$(IslandPath)\**\*.csproj;$(IslandPath)\**\*.cs;$(IslandPath)\**\*. xaml;$(IslandPath)\**\obj\**;$(IslandPath)\**\bin\**"/> <IslandLibraryContent Include="$(IslandPath)\obj\$(Configuration)\**\*.xbf"/> </ItemGroup> <ItemGroup> <None Include="@(IslandLibraryContent)"> <Link>$(IslandDirectoryName)\%(RecursiveDir)\%(Filename)%(Extension)</Link> <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> </None> </ItemGroup>[/td] [/tr] [/table]

This Microsoft Build snippet is copying files, based on the IslandLibrary Property path, to the project where it resides. The IslandLibraryCompile includes:

All the .xaml.cs files. That will enable you to reuse the code behind of your custom controls.

All the generated .g.i.cs and .g.cs files. These files are generated files. All that you do under the “x:” prefix, is actually generated code, and this is where this generated code is going after all. So this files are the partial classes that actually hold the fields of all the x:Names inside their corresponding XAML files, and they also hold the code for connecting this fields with their actual instances. They also reference the .XAML file that will be loaded whenever the InitializeComponentmethod is called, usually at the beginning of the control’s constructor. You can look at this as a black box, but it is interesting to understand what is inside these files, but not necessarily how it works. The IslandLibraryContent includes:

All the content files of your project. That basically will copy all the files required for your project to run, like PNGs, JPGs, etc. It already copies them to the right folders so ms-appx:///will “just work”™. There are better ways of doing this, but this will cover the basic needs of the most common scenarios.

All the generated .xbf files. XBF stands for XAML Binary Format and it is a compiled version of your .xaml files, they load much faster than the XAML files (no XML parsing, for example). Even though the .g.i.cs files might look like they are trying to load the .xaml files, the XAML infrastructure itself always tries to load the .XBF files first, for performance. Only if it can’t find them they will try to load the .xaml files. This MSBuild script is not copying the .xaml files since they bring no advantage compared to the .XBFs.

To make sure that your developer experience is optimal, you also have to add a solution level project dependency, from the WPF/WinForms project to the UWPLibrary project. This means that whenever you change any of the UWP Library’s files, you can just build the WPF/WinForms project and the newest artifacts are already in place, in the correct order of project compilation. All these steps are going away in a future version of Visual Studio, when the tooling gets updated. There steps are described here at the documentation.

With these files included into the project’s build infrastructure and with the build dependency added, your WindowsXamlHost should work just fine if you set it’s InitialTypeName to your custom control’s fully qualified name. You can checkout the sample project here.

With this MSBuild snippet, even your apps packaged with the “Windows Application Packaging Project” template should work. If you want to know more, checkout this blog post.

October 2018 Limitations

Again, this release is in preview, so nothing you see here is production ready code. Just to name a few:

Wrapped Controls properly responding to changes in DPI and scale.

Accessibility tools that work seamlessly across the application and hosted controls.

Inline inking, @Places, and @People for input controls.

For a complete list, check the docs.

What’s next?

The version just released is not the final stable version, meaning that it is a preview. We’re still actively working on improving Xaml Islands. We would love for you to test out the product and provide feedback on the User Voice or at L: XamlIslandsFeedback@microsoft.com, but we currently are not recommending this for production use.
Click to expand...

Source: XAML Islands - A deep dive - Part 2 - Windows Developer BlogWindows Developer Blog

Cluster Head · Jun 13, 2019

Updated: Windows 10 Roadmap

Updated: Windows 10 Roadmap *Wink

Take an inside look

The Windows 10 roadmap provides a snapshot of what we’ve recently made generally available, released into public preview, are still developing and testing, or are no longer developing.
Click to expand...

Source: https://www.microsoft.com/en-us/Wind...indows-roadmap

Windows 10: XAML Islands v1 - Updates and Roadmap for Windows 10

XAML Islands v1 - Updates and Roadmap for Windows 10

XAML Islands v1 - Updates and Roadmap for Windows 10

XAML Islands v1 - Updates and Roadmap for Windows 10

XAML Islands v1 - Updates and Roadmap for Windows 10 - Similar Threads - XAML Islands Updates

XAML Islands - A deep dive Part 2 for Windows App Developers

XAML Islands - A deep dive Part 1 for Windows App Developers

what is Microsoft advertising SDK for XAML update?

Windows Bridge for iOS: UIKit, meet XAML. XAML, meet UIKit

Roadmap to Win10

Windows 10 Anniversary Update to Launch in July, MS Roadmap Reveals

Windows 10 Business features roadmap

Windows Server and System Center roadmap update

Updated: Windows 10 Roadmap

Users found this page by searching for:

wpf future roadmap

defining styles in xaml islands