Using XAML Islands on Windows 10 19H1: fixing the "Catastrophic failure" exception
Published Mar 18 2019 11:06 AM 18.6K Views
Microsoft

As you probably know, the AppConsult team has a strong focus on Windows app modernization. XAML Islands is one of the main technologies we're working with and with my buddy Sebastien Bovo we have delivered a full workshop about it at Microsoft Ready, an internal Microsoft event which gathers more than 5000 engineers from all around the world.

XAML Islands is one of the technologies which allows to modernize your existing WPF and Windows Forms applications without rewriting them from scratch. You can embed, in fact, controls from the Universal Windows Platform and, as such, bring a bit of Fluent design, touch and ink support also to your Win32 applications.

The APIs which make XAML Islands possible are included in Windows 10, but to make easier to consume them the Windows team has built a set of controls which have been included in the Windows Community Toolkit. This way, embeedding a UWP control in your Win32 application is easy as dragging and dropping a control inside your window and set some properties.

XAML Island support has been added in preview in Windows 1809, but it's on Windows 10 19H1 (the next major Windows update) where it will reach its full potential. As a consequence, I've finally decided to make the switch and I moved my Surface Pro to the Windows Insider program. As such, at the moment of writing, I'm now running Windows 10 18358.1.

However, when I launched the application me and Sebastien have built for the XAML Island lab, it started to crash when I was opening one of the windows which hosts a UWP control. The error was the following one:

 

System.Exception: 'Catastrophic failure WindowsXamlManager and DesktopWindowXamlSource are supported for apps targeting Windows version 10.0.18226.0 and later. Please check either the application manifest or package manifest and ensure the MaxTestedVersion property is updated.'

exception.png

 

After some investigations and with the help of my friend Alexandre, I've found two ways to solve this problem.

 

MSIX packaging

The first way to solve this problem is to package the application as MSIX and use, as target SDK, the 19H1 one. This way, the application will be compiled with the newest version of the SDK, which includes support for all the latest XAML Island features, and the error will go away.

As first step, you have to go to the https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewSDK website, login with a Microsoft Account enrolled in the Windows Insider program and click on Get SDK Insider Preview. At the time of writing, the most recent SDK is 18351. Once the download is complete, double click on the ISO file, which will be mounted as a virtual drive. Open it in File Explorer and double click on the WinSDKSetup.exe file to start the installation.

Once the setup is finished, open your WPF or Windows Forms solution in Visual Studio. Then right click on it in Solution Explorer and choose Add -> New project. If you're using Visual Studio 2019, just type packaging in the search box to find the Windows Application Packaging Project. If you're using Visual Studio 2017, instead, you will find under the category C# -> Windows Universal.

 

packaging project.png

 

As first step, you will be asked which Windows 10 version you want to target. Make sure to choose, as Target version, the Insider SDK you have just installed:

 

insider.png

 

Once the project has been created, identify the Applications section in Solution Explorer and right click on it. Choose Add reference: Visual Studio will show the list of projects included in the solution. Choose the one which contains your WPF / Windows Forms application and press OK. Now your application has been packaged. If you set the new project as startup and you deploy it, you will actually launch the packaged version of your application inside the MSIX container.

 

solution explorer.png

 

If you now try to open a windows of your application which includes a XAML Island control, it will work just fine and you'll be able to see and interact with it.

 

Add an application manifest

The second option is to add an application manifest to your Win32 application. This will allow to leverage XAML Islands without having to package your application as MSIX. But there's an advantage also in the MSIX scenario: you'll be able, in fact, to package your application but still target 1809, without having to install the 19H1 SDK and retarget the app.

To add an application manifest, right click on your WPF or Windows Forms project and choose Add -> New item. Choose XML File from the list, name it app.manifest and then copy and paste the following content:

 

<?xml version="1.0" encoding="utf-8"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>

      <!-- Windows 10 -->
      <maxversiontested Id="10.0.18358.0"/>
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

    </application>
  </compatibility>

</assembly>

The maxversiontested element inside the application node must match the most recent available version of Windows 10 19H1. Ideally, once 19H1 will ship, it should include the final version number. For the moment, I've specified the most recent Insider build at the time of writing, which is 18358.

The second step is to edit the .csproj to add a reference to the manifest file we have just added. We can do this through the visual editor. Right click on the project and choose Properties, then in the Resources section type app.manifest in the Manifest field, as highlighted below:

 

appmanifest.png

 

That's it! Now you launch your WPF or Windows Forms application, even not packaged as MSIX, and you should see the UWP controls being rendered just fine, wihout any other catastrophic failure =)

 

Wrapping up

In this post we have seen how to fix the catastrophic failure exception that you may get if you have started to integrate XAML Island in your WPF and Windows Forms app on Windows 10 1809 and then you moved to 19H1. If you want to take a deeper look to XAML Islands, the official GitHub repository is a great starting point, since it contains many samples you can play with.

Happy coding!

20 Comments
Copper Contributor

@Matteo Pagani - Thanks for this post. I've been following the work from the app consult team very closely as I love using the new technologies you all come out with for UWP. I ran into this error after upgrading my Windows to 19H1 and I've since halted development on upgrading my desktop bridge app(s) to use XAML Islands since I've had numerous issues using the preview and it didn't seem worth it to continue developing for an OS release version that most of my users will not use for a while. However, I'm very glad to see work is still being put into these technologies. I have a couple questions which may affect the priority of the work in my apps and maybe you can answer them for me:
1. If I'm required to also upgrade my package to build 18351, does that mean there will never be support for XAML islands earlier than that build (like for OS version 1809)?
2. When is XAML island's anticipated release date and when can I expect to be publishing apps with XAML islands to the Windows Store?

Microsoft

Hello and thanks for the feedback! Let me try to address your questions:

 

  1. Partially correct. XAML Islands has been introduced in Windows 1809, so it works also there. However, in 1809 it has been released as a preview technology to allow developers start playing with it, but it isn't suggested to be used in production environments.
  2. XAML Islands will be out of preview in 19H1, so very soon. I think nothing is blocking you to publish an application on the Store which uses XAML Islands right now. The only caveat is that you need to test it very well and make sure that the UWP controls you're using don't introduce any kind of  instability in your apps.
Copper Contributor

Hi Matteo, 

 

I have few questions. I try xaml Island and got error:  "Catastrophic failure. WindowsXamlManager and DesktopWindowXamlSource are supported for apps targeting Windows version 10.0.18226.0 and later. Please check either the application manifest..." in xaml editor for "MapControl". The offending "MapControl" is part of a UserControl which is inside a .net Core WPF class library. the class library is referenced by a .net Core WPF application.

 

Q1 - I included the manifest into both (Class library and app) but I feel it is only required into the app because the "Manifest" combo box of my User control project is disabled. Why Microsoft let me enter a Manifest into a UserControl if it is not required. If it is required, which seems normal in order for the UserControl to validate that it has the minimum requirement, then why the Manifest Combo box of my UserControl project property is disabled? 

 

Q2 - You seems to say that we have to put the latest version (latest build) of windows version into the manifest. I don't understand why it is not the minimum supported version? Why it is the maximum version? You seems to say that we have to write the latest version of a version of Windows but how does it stay valid when Windows version change (new patches for examples)? We always have to update that version number?

 

Q3 - We are in february 2020 and I still have the error. Nothing seems to have evolved since your post because I have the exact same error. Microsoft pushes developers to use .Net Core but xaml Island seems the only way to gat advantages of recent developement  related to UWP like SVG, Win2D, MapControl and so on. You also mention that is is not suggested to use that in prodution. So what should I understand? Should we use xaml Island or not?

 

Thanks,

Eric

 

 

Microsoft

Hello Eric,

here is my feedback to your questions:

 

  1.  Yes, that's correct. The app manifest is an application concept, not a user control one. The user control will leverage the minimum and maximum version that you have specified for the main application.
  2. This blog post has been written before Windows 10 1903 was officially released. As such, the build number in the manifest was the most recent one related to Windows 1903 available at that time. Now that Windows 10 1903 is out, you can safely use the final build number, which is 18632. You don't have to increase it when new Windows 10 versions are released, you can stick to 18362 since it's the first public Windows 10 version to offer full support for XAML Islands.
  3. The error you are seeing isn't an error, but a requirement to specify the minimum OS version since version earlier than Windows 10 1903 don't offer XAML Islands support. Setting the minimum supported Windows 10 version (either via manifest or MSIX packaging) will always be a requirement. Things eventually might change with the release of WinUI 3.0, which will offer XAML Islands supports to older versions of Windows 10.

I hope it helps!

Copper Contributor

Thanks a lot Mateo, it really helps. But I still have few interrogations/problems that you seems to be the key to the solution.


I followed Thomas Claudius Huber post: https://www.thomasclaudiushuber.com/2019/04/23/net-core-3-use-uwp-controls-in-wpf-with-xaml-islands/ and video (PluralSight) of Olia Gavrysh - Building Modern .Net Desktop Apps with .NET Core and Windows 10: DEVintersection 2019.

Note: Olia says at minute 40:40 : Minimum version of Windows talking about "maxversiontested". Is this a minimum or maximum version (one is the opposite of the other)? Does Microsoft will fix that?

 

I used <maxversiontested Id ="10.0.18362.0"/> but the XamlDesigner message says in the error message "0.0.18226.0". It's really comfusing, it would be nice the remove the ambiguity.

 

After everything was added like described by Thomas and Olia (and you), I still got the error from XAML designer:

"Catastrophic failure\r\n\r\nWindowsXamlManager and DesktopWindowXamlSource are supported for apps targeting Windows version 10.0.18226.0 and later. Please check either the application manifest..."

 

OK, although the designer say that, it compiled fine and worked fine, at least in appearance. Just in appearance, because I'm also not able to access "MyMapControl" from code behind although I set x:Name = "MyMapControl".

 

Also, as a side note, the designer does not really help if it says errors that do not exists. I Know it's like that for at least 10 years (Xaml Designer, in some circumstance, show some false errors although everything compile fine) but this one, a new one, really does not help when we are trying new stuff. Can we expect Microsoft to fix the Xaml Designer in order to show real errors? I can sent you samples of many types of false errors.

 

Also, I can't access the MapControl from code behind. Do you have any idea why?

Copper Contributor

Thanks a lot.

 

Your answers are great and relly helpful. 

 

I posted a stackoverflow question because I still have 2 problems. Perhaps you can take a look if you have few minutes?

 

 https://stackoverflow.com/questions/60121122/xdg0062-catastrophic-failure-when-trying-to-use-uwp-con...

 

Thanks for your very quick feedback and nice answers.

Eric

Microsoft

Hello Eric,

I tried to reply on Stack Overflow but, unfortunately, I need some clarifications on your configuration and Stack Overflow doesn't allow that. Since I don't have enough reputation, it seems that I'm not allowed to ask for clarifications but only to provide direct answers. However, in this case I need additional info before helping you.

 

Which Windows 10 version you're running on your machine? Can you try if you get the same behavior with the sample app available at https://github.com/qmatteoq/MCTSummit2020-MiddleEast/tree/master/ModernWpfDemo?

This is a demo project I've built which uses a MapControl as well and, on my machine, I'm not able to reproduce your problem. I don't get any error in the designer.

 

Thanks!

Copper Contributor

Thanks Matteo for your feedback,

 

I try your code.

- I uncommented the MapControl

- Added 2 nuget package: Microsoft.Toolkit.Wpf.UI.   (Controls and Xamlhost)

-I got error MSB3270, I went to App properties and changed Platform Target from x86 to AnyCpu. 

- I got another error where I switched my solution to debug in x64 (with appropriate project)

- I now have:

Severity Code Description Project File Line Suppression State
Error MSB3270 There was a mismatch between the processor architecture of the project being built "AMD64" and the processor architecture of the reference "C:\Prj\Samples\UWP\MCTSummit2020-MiddleEast-master\ModernWpfDemo\ModernWpfDemo\bin\x86\Debug\netcoreapp3.1\win-x86\ModernWpfDemo.dll", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project. ModernWpfDemo.Package C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets 2106

 

Or 

 

Severity Code Description Project File Line Suppression State
Error NETSDK1032 The RuntimeIdentifier platform 'win-x86' and the PlatformTarget 'x64' must be compatible. ModernWpfDemo C:\Program Files\dotnet\sdk\3.1.101\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets 151

 

Everything is set to x64 in project properties.

 

I had to hack manually the ModernWpfDemo.csproj to swap

from:  <!--<RuntimeIdentifier>win-x86</RuntimeIdentifier>-->

To:  <RuntimeIdentifier>win-x64</RuntimeIdentifier>

 

Now I have when I run the app:

+ $exception {"Could not load file or assembly 'Windows.Foundation.UniversalApiContract, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified."} System.Windows.Markup.XamlParseException

Microsoft

Hello,

I apologize but I have realized that the repository I have shared wasn't in a good shape :)

Can you try again to clone the master branch from https://github.com/qmatteoq/MCTSummit2020-MiddleEast then follow these steps:

 

  1. Open the solution ModernWpfDemo.sln inside the ModernWpfDemo folder
  2. Make sure that the ModernWpfDemo project is the startup one (not the ModernWpfDemo.Package one)
  3. Choose x86 o x64 as CPU architecture.
  4. Press F5 and launch the debug.

Can you also share which is the Windows 10 build you're running on your machine?

 

I'm looking forward to your feedback.

Kind regards

Copper Contributor

Thanks Matteo,

 

Result of compilation:

 

Severity Code Description Project File Line Suppression State
Warning Because your app is being built as AnyCPU no Microsoft.VCRTForwarders.140 DLLs were copied to your ouput folder. Microsoft.VCRTForwarders.140 only supports x86 or x64 applications due to a C++ Runtime dependency. Please change your app project architecture to x86 or x64 in the Configuration Manager. ModernWpfDemo C:\Users\cn1629\.nuget\packages\microsoft.vcrtforwarders.140\1.0.2-rc\build\netcoreapp2.0\Microsoft.VCRTForwarders.140.targets 33

 

Severity Code Description Project File Line Suppression State
Warning 81010002 Unrecognized Element "maxversiontested" in namespace "urn:schemas-microsoft-com:compatibility.v1". ModernWpfDemo C:\Prj\Samples\UWP\MCTSummit2020-MiddleEast-master 2\MCTSummit2020-MiddleEast-master\ModernWpfDemo\ModernWpfDemo\obj\AnyCPU\Debug\netcoreapp3.1\Manifests\app.manifest 1

 

Severity Code Description Project File Line Suppression State
Warning 81010002 Unrecognized Element "maxversiontested" in namespace "urn:schemas-microsoft-com:compatibility.v1". ModernWpfDemo C:\Prj\Samples\UWP\MCTSummit2020-MiddleEast-master 2\MCTSummit2020-MiddleEast-master\ModernWpfDemo\ModernWpfDemo\app.manifest 1

 

Severity Code Description Project File Line Suppression State
Error MSB3270 There was a mismatch between the processor architecture of the project being built "AMD64" and the processor architecture of the reference "C:\Prj\Samples\UWP\MCTSummit2020-MiddleEast-master 2\MCTSummit2020-MiddleEast-master\ModernWpfDemo\ModernWpfDemo\bin\Debug\netcoreapp3.1\win-x86\ModernWpfDemo.dll", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project. ModernWpfDemo.Package C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets 2106

 

I wonder if Microsoft employees could have something that is not included in Visual Studio installation?

 

I have latest Visual Studio version and Windows 10 v1909. My desktop Windows version was initially installed in french (not my choice).

 

Eric

Microsoft

Ok this problem is happening because the WPF project is configured to support only the x86 runtime. You have two options:

  • Compile for x64
  • Do a pull from GitHub. I have updated the project to support both x86 and x64.

Let me know if this works for you!

Copper Contributor

Thanks Matteo,

 

It works fine. But I still have the Catastrophic failure in XAML editor.

FYI: There is many other XAML errors in the XAML Designer of Visual Studio since at least 2012. I reported them in Microsoft Connect but nothing happen.

 

EricOuellet_0-1581612370364.png

 

Microsoft

It seems it might be something specific to your configuration, because on my machines I don't see the catastrophic errors. Can you open an issue with the feedback tool integrated in Visual Studio and share me with the ID / link?

I will make sure that someone from the VS team takes a look at that.

 

Thanks!

Copper Contributor

Thanks so much!

 

I reported a problem from Help-Send Feedback-Report a problem: "Catastrophic failure..." using UWP-MapControl into .Net-Core app with UWP

 

It is under my name: "Eric Ouellet". I just received an email with this link: https://developercommunity.visualstudio.com/content/problem/917596/catastrophic-failure-using-uwp-ma...

 

Thanks so much for your help. 

 

Eric

Microsoft

If you go back to the Feedback section, you should be able to see a list of all the feedbacks you have opened. You can click on them and go to the corresponding webpage. That's the link I'm looking for!

 

Thanks!

Copper Contributor

I think you write me while I was modifying my answer. I inserted the link: https://developercommunity.visualstudio.com/content/problem/917596/catastrophic-failure-using-uwp-ma...

 

I received the link in an email few minutes after I created the bug report. 

If I go to "Help-Send feedback-Report a problem", I can see there is links but there is no way to copy them.

Is the previous link ok?

 

Copper Contributor

   

Copper Contributor

After many errors from myself, I finally got the exact same behavior with your code than my own code.

- I would say that everything appears to be the same.

- It sounds like an external dependency is the problem... How to know?

 

Copper Contributor

Got it work just fine for the WPF App but not in VSTO Add-in. The VSTO Add-in Project is Class Library and manual adding app.manifest is grey out. Is there a work around for VSTO Add-in using UWP Xaml Islands ?

Microsoft

Hello,

I don't think XAML Islands can work with VSTO Add-in. The host of XAML Islands must be a standalone application.

 

Best

Version history
Last update:
‎Mar 19 2019 01:37 AM
Updated by: