<\/i>Important<\/strong><\/p>UWP support for modern .NET is now generally available, and no preview tooling is required anymore. Visual Studio 2022 includes built-in project templates to create new UWP applications, class libraries, and Windows Runtime components using .NET 9. Visual Studio 2026 includes updated versions of all new templates targeting .NET 10. The Windows SDK with support for UWP XAML projects with modern .NET is also included in both editions of Visual Studio. The original blog post can be viewed below, however the steps and instructions to try things out before the official release are not applicable anymore, as everything will now just work out of the box.<\/div><\/p>\n We\u2019re introducing the initial preview UWP (Universal Windows\nPlatform) support for .NET 9<\/strong>, providing a path for existing UWP\ndevelopers to modernize their apps with the latest .NET and Native\nAOT.<\/p>\n Are you a UWP app developer considering migrating to Windows App SDK\nand WinUI 3? Or wanting to leverage the latest releases of .NET and\nNative AOT? Or perhaps you\u2019ve been struggling with referencing new\nversions of your favorite libraries, because they only include support\nfor .NET 6 and above? Well, look no further! This preview UWP\nsupport for .NET 9<\/strong> provides a path for UWP apps to modernize\nusing the latest version of .NET.<\/p>\n <\/i>Note<\/strong><\/p>UWP support for .NET 9 is\navailable in preview, and as such you should expect to potentially find\nissues, as well as missing functionality (such as no XAML Designer at\nthe moment). You should also expect some binary size regressions\ncompared to .NET Native (more on this below). This first public preview\nis only the first step in this journey for UWP apps to adopt the latest\nversion of .NET, and we\u2019re looking forward to your feedback (see #summary<\/a> for support contacts) as we work on\nimproving the tooling and the developer experience to make it as good as\npossible.<\/div><\/p>\n This preview is a set of updated tools and components that are part\nof .NET, Visual Studio, the Windows SDK, and more, to allow using the\nlatest version of .NET and C# for building UWP apps. This preview\ndoes not introduce any new features for UWP<\/strong>. Instead,\nit provides a migration path for developers to modernize their apps with\n.NET 9 while they consider moving toward WinUI 3. It is rather a way for\nUWP app developers to modernize their apps and leverage all the recent\nadvancements in .NET and C#, while still retaining the existing features\nthat UWP provides today.<\/p>\n <\/i>Note<\/strong><\/p>If you are starting to develop new\nWindows apps, we recommend you consider using the Windows\nApp SDK<\/a> and WinUI 3<\/a>\nrather than UWP. Although still officially supported, UWP is not under\nactive development. You can refer to Start\ndeveloping Windows apps<\/a> for more information. If you\u2019d like to keep\nleveraging AppContainer (see #glossary<\/a>) for\nextra security, just like UWP, refer to MSIX\nAppContainer apps<\/a> to see how you can configure your WinUI 3 app to\nbe a partial trust Windows app.<\/div><\/p>\n The main goals of the UWP support for .NET 9 are as follows:<\/p>\n Whether you\u2019re migrating from UWP to WinUI 3, or you\u2019re just trying\nto be more productive on your app\u2019s existing UI framework, this preview\nlets you modernize to the latest .NET and C# and take advantage of\nrecent tooling improvements to ease your migration journey.<\/p>\n <\/i>Tip<\/strong><\/p>If you\u2019re not familiar with\nall the exact terminology around UWP and all related technologies, or if\nyou\u2019d simply like to learn more, you can refer to the #glossary<\/a> section at the end of this blog post.\nThis glossary provides all the context you might need to fully\nunderstand where the UWP support for .NET 9 ties into the Windows\nplatform.<\/div><\/p>\n In order to try out the UWP support for .NET 9, a few preview tools\nare needed. Here\u2019s everything you\u2019ll need to install.<\/p>\n First, make sure to get Visual Studio 2022 17.12 Preview 2, which\nwent live just yesterday! All new tooling is included in the \u201cUniversal\nWindows Platform tools\u201d section under the \u201cWindows application\ndevelopment\u201d workload. To install all the necessary components, follow\nthese easy steps:<\/p>\n You\u2019ll also need an updated version of the XAML compiler that\nsupports .NET 9 projects. This will be included in an upcoming servicing\nrelease of the Windows 11 SDK (10.0.26100.0). However, if you want to\ntry things out today, we have a small bundle with just the updated XAML\ncompiler, which you can manually patch on your machine. To do that, download\nthe preview Windows SDK bundle<\/a> and follow the instructions in the\nREADME file.<\/p>\n Next, you\u2019ll need to install the latest nightly build of the .NET\nSDK, which you can download from the .NET SDK GitHub repo<\/a>. These changes\nwill also be available in .NET 9 RC2, once it releases later this year. For the time being, you\u2019ll\nfind the download link for .NET 9 nightly builds in the latest\nbuilds table<\/a> page. Don\u2019t forget to follow the instructions in the\nREADME to also add the necessary preview NuGet feed for .NET 9 packages.\nIn order to avoid installing nightly .NET SDK builds machine-wide, you\ncan pick the .zip option of the .NET SDK instead of the installer. Then,\nextract it in a folder of your choosing (we recommend excluding the\nfolder from Windows Defender for extra build performance or setting up a\nDevDrive<\/a>),\nand add it to PATH. This is a convenient way to try out nightly builds\nwithout having to worry about uninstalling them later on.<\/p>\n For further convenience, below is the contents of a complete nuget.config<\/a>\nfile you can copy-paste next to your .sln file that includes the .NET 9\nfeed. This will ensure that UWP .NET projects using the latest nightly\nbuild of the .NET 9 SDK from the .NET SDK repo will be able to correctly\nrestore all their dependent NuGet packages:<\/p>\n As part of the UWP support for .NET 9, we now also have new project\ntemplates for UWP apps and libraries. To get started, install this\nVSIX<\/a> to get all the new templates (in preview), which we\u2019ll be using\nin the guide below as well to show how to create a new UWP project with .NET 9 support.<\/p>\n And that\u2019s it! All other changes across other components are included\nor referenced by default. Now that all preview tools are installed, we\ncan actually start creating our first UWP .NET 9 project, or start\nmigrating our existing UWP applications to the latest .NET and C#.<\/p>\n <\/i>Note<\/strong><\/p>This preview should be seen as an\nincremental migration step, with the ultimate goal of moving toward\nWinUI 3 for the most up-to-date and actively supported\nframework.<\/div><\/p>\n After installing the VSIX we linked above, the new templates should\nshow up automatically when opening Visual Studio, or you can also easily\nfilter all templates by searching for \u201cUWP\u201d. These templates are meant\nto be a convenient way to create updated UWP apps, libraries, runtime\ncomponents, and more, targeting .NET 9, both to help migrating existing\napps, as well as for developers wanting to experiment with new project\nideas.<\/p>\n To see all these new templates, launch Visual Studio and click\n\u201cCreate a new project\u201d:<\/p>\n We included 5 new project templates:<\/p>\n Let\u2019s click on \u201cBlank UWP App (Preview for .NET 9)\u201d to try it out\n(make sure to select Windows 11 22H2, build 26100, as the target\nframework, in the new project wizard), and let\u2019s inspect the resulting\nproject. You will notice that it combines all the familiar aspects of\nUWP XAML apps (the app manifest file, <\/i>Tip<\/strong><\/p>When creating a new\nproject with one of the preview templates, you might get an error dialog\nsaying \u201cOperation is not valid due to the current state of the object.\u201d.\nThis is due to the UWP Project Wizard in Visual Studio not supporting\n.NET 9 projects yet. This issue will be fixed in the next release of\nVisual Studio. As a temporary workaround, you can close Visual Studio,\nopen it again, manually open the .sln file that was created, and then\nright click > Add > Existing Project, and browse the new .csproj\nfile that was created. That error dialog does not prevent the actual\nproject from being created and saved on disk. If you\u2019re instead using\none of the new templates to create a project in an existing solution,\nthe new project should just show up correctly after dismissing the error\ndialog.<\/div><\/p>\n For this initial preview (using Visual Studio 17.12 Preview 2),\nyou\u2019ll need to make a slight temporary modification to the .csproj in\norder for things to work. The UWP support for .NET 9 is currently\nrelying on the single-project MSIX tooling in Windows App SDK, which is\ncausing the WebView2 NuGet package to also be referenced by default. We\nhave made changes for it to support UWP .NET 9 apps as well, but those\nare not released publicly just yet. So for now, you need to manually\nexclude all assets from that NuGet package to avoid it causing build\nerrors. Without those, you\u2019ll probably see something like this in the\nerrors window when trying to build your project:<\/p>\n To fix this, we can add the following to the .csproj file:<\/p>\n This is only temporary, and it will no longer be needed once the new\nupdate for this package is released.<\/p>\n With all of these changes, we should end up with the following:<\/p>\n So clean! We just need a total of 16 lines of code (ignoring the\ntemporary WebView2 workaround), and nothing else! Alright, now that our\nnew project is ready, it\u2019s time to run our very first UWP .NET 9 app! We\ncan just click the green \u201cStart Debugging\u201d button in Visual Studio as always:<\/p>\n And there it is: UWP XAML running on .NET 9! \ud83d\ude80<\/p>\n We made changes to several components in Visual Studio to ensure a\ngreat developer experience. You\u2019ll notice:<\/p>\n This first preview does not include the XAML designer, but keep\nreading for more info on this!<\/p>\n Now that we\u2019ve successfully run our first UWP .NET 9 app, we should\ntake a moment to look into some technical details to better understand\nhow UWP .NET 9 projects are structured. You might notice a few\nproperties that are set automatically in the .csproj file by the project\ntemplate. This is what they\u2019re doing:<\/p>\n These three properties are making all the magic happen so that we can\nnow build UWP XAML apps on latest .NET! \u2728<\/p>\n Notice we\u2019re also setting It is worth calling out when migrating from .NET Native to Native\nAOT, you should expect a fair amount of friction and complexity in\nmaking sure that all of your code (including all of your dependencies)\nwill work correctly with Native AOT. At first, depending on your app,\nyou might see things stop working as expected until updated for AOT.<\/p>\n On the bright side, working to enable Native AOT in your app will\nmake it much more resilient, and additionally, this work can be 100%\nreused if you then decided to also move from UWP to Windows App SDK in\nthe future. As they both leverage .NET, they are identical to respect to\nthe constraints and code changes needed for Native AOT support!<\/p>\n With traditional UWP apps using .NET Native, you could find\ndifferences in behavior between Debug and Release and encounter all\nsorts of runtime crashes that would be difficult to debug or prevent.\nEven with a .NET Native app that was working, it was impossible to know\nfor sure that there weren\u2019t some hidden bugs here and there due to\nincorrect trimming. .NET Native provided a double-edged sword, as it\nrelied on lots of heuristics to try to make all .NET code \u201cjust work\u201d,\nmeaning it included pretty extensive fallback logic to try to make even\nthe most aggressive reflection paths work, and it would try to\nautomatically root .NET code for trimming if it thought it could be\nreflected on (e.g.\u00a0it had special handling of well-known libraries such\nas Newtonsoft.JSON<\/a>). But\nthere was no way to statically prove that that would be the case,\nleading to these types of crashes you may have encountered while\ndeveloping your own apps as well.<\/p>\n Native AOT, on the other hand, takes a drastically different approach\nand relies on static validation through code annotations and a set of\nanalyzers. You can learn more about this in this\nblog post on AOT compatibility<\/a>. Practically speaking, this means\nthat Native AOT has \u201cmuch less tolerance\u201d than .NET Native and requires\nall code to be properly annotated for AOT support ahead of time, but in\nreturn for this work it provides a guarantee that if an app can be built\nand published with Native AOT without producing any trim\/AOT\nwarnings<\/strong>, then it will run exactly the same<\/strong> as\nin a normal Debug build. This also means that any problems will show up\nmuch earlier in the development phase, and you\u2019ll be able to easily\ndebug them during your normal dev inner loop, without needing a Release\nbuild to test.<\/p>\n <\/i>Information<\/strong><\/p>NativeAOT also has\nslightly different performance and binary size characteristics compared\nto .NET Native. We expect performance for NativeAOT on .NET 9 to be\nroughly equivalent to .NET Native (our benchmarks showed startup\nperformance between ~5% when compared to .NET Native, whereas backend\ncode not relying on WinRT interop should actually be consistently\nfaster). As for binary size, you might notice a ~4MB regression,\nespecially with smaller apps. This is due to .NET Native using a\nframework package for its runtime and class libraries (meaning all that\ncode was installed as a separate component and shared with other UWP\napps using the same version of .NET Native). NativeAOT, on the other\nhand, compiles all code into its output executable. This results in an\nincrease in binary size (which should be amortized as the size of the\napplication grows, however), but in return it also gives NativeAOT\nbetter performance, as it allows the compiler to perform\ninter-procedural optimizations with code from the .NET BCL, such as eg.\ninlining and optimizing code from the core libraries depending on the\nspecific use in your application. Improving both performance and binary\nsize metrics for NativeAOT and CsWinRT (the component handling all WinRT\ninterop on modern .NET) is something that is under active development,\nso expect regular improvements in this area in future\nreleases!<\/div><\/p>\n One more bit of information with respect to the Microsoft Store\ncertification, if you\u2019re interested in trying to publish an update (or a\nnew app!) using the UWP support for .NET 9: we recommend ignoring Windows\nApp Certification Kit failures<\/a> when running the tool locally,\nespecially regarding \u201cunsupported Win32 APIs\u201d. These checks are in place\nbecause UWP apps were historically subjected to a particularly strict\nvalidation of all imported Windows APIs, which would trigger automatic\nfailure during certification if unsuccessful. This is no longer the\ncase, and Partner Center doesn\u2019t execute this Win32 API set validation\non UWP apps anymore, relying instead on the security model provided by\nAppContainer itself. That is, rather than trying to detect all \u201cunsafe\u201d\nWin32 APIs and fail certification, all APIs are allowed, and\nAppContainer will simply make them fail at runtime if they tried to\nperform any operation that wasn\u2019t allowed. This is especially relevant\nfor Native AOT, as it includes several Win32 imports for APIs that are\nnot in the allowlist for UWP apps, but that are completely fine to use\nfrom UWP (and in fact, work just fine). Because of this, you can still\nrely on WACK to perform basic validation before uploading a package to\nthe Microsoft Store (it\u2019s especially useful to double check that no\nmandatory asset is missing from the manifest, for instance), but you\nshould not worry about false-positive errors it reports about disallowed\nWin32 APIs.<\/p>\n Enabling the latest .NET for UWP applications not only provides an\nupgrade path to existing UWP developers, but it also improves existing\nscenarios that were previously limited by the legacy .NET infrastructure\nand limitations that managed UWP apps have had from the start. Let\u2019s\ntake a quick look at some other benefits that the UWP support for .NET 9\nbrings to the table.<\/p>\n For those of you working on complex apps combining multiple\nUI-frameworks, where some controls are leveraging UWP\nXAML Islands<\/a> (i.e.\u00a0hosting UWP XAML controls inside a Win32 app),\nthe UWP support for .NET 9 brings improved support for this scenario,\nthanks to the switch to the latest .NET and Native AOT! It is now\npossible to have a single project, using .NET 9, representing a packaged\nfull trust (or partial\ntrust<\/a>) Win32 app, as well as the hosted UWP component to be placed\nin the visual tree! You can even combine everything into a single,\nnative binary, without having to worry about the UWP components\nrequiring a separate build toolchain that\u2019s difficult to integrate with\nthe rest of your application.<\/p>\n Here is an example showcasing how the native UWP You can find a full sample using C++\/WinRT in the WindowsAppSDK-Samples\nrepo<\/a>, which shows all the code that\u2019s needed in detail. A C#\nimplementation would be very close to this, with just minor differences\ndue to different ways of doing interop with native APIs between C++ and\nC#. We\u2019ll also soon be updating the samples to include a Windows App SDK\napp hosting XAML Islands via a UWP .NET 9 app too, so you can just use\nthat as a reference if you\u2019d like to experiment with this in your own\napp.<\/p>\n <\/i>Tip<\/strong><\/p>As mentioned in the docs, the\nUWP Adding support for the latest version of .NET and switching from .NET\nNative to Native AOT also brings massive improvements to one particular\nscenario: using F#<\/a> on UWP! While\nyou can\u2019t use F# for your app layer with XAML, just like WinUI 3, you\ncan now reference dependencies or other projects that are built with\nF#!<\/p>\n .NET Native, to this day, has some hard blocks that detect F#\nassemblies and immediately fail compilation, and even trying to manually\npatch some Visual Studio files to bypass those blocks, a lot of\nscenarios would still simply fail to compile or work at all, because the\n.NET Native toolchain simply was never designed to handle many of the\ncommon patterns of F# code. There is a long standing and\nvery popular issue<\/a> in the F# repo asking for F# support for .NET\nNative, which has since been closed without being completed. With the\nUWP support for .NET 9, all of this no longer applies, as you\u2019ll be\nusing the same Native AOT runtime that already fully supports using F#\nwith any other project type as well!<\/p>\n If you are a F# enthusiast and would like to try this out, don\u2019t\nforget to share your findings and tell us about your experience! \ud83e\uddea<\/p>\n The UWP support for .NET 9 also enables one more thing that might be\nuseful for library authors in some advanced scenarios. Like we\nmentioned, the new \u201cUseUwp\u201d property tells the .NET SDK to add a\nreference to the Windows.UI.Xaml.* projections for .NET, which is\nnecessary for UWP XAML apps. However, while using<\/em> these types\nis only allowed in UWP XAML apps, referencing<\/em> these projections\nis something that any .NET project can do. What this means is that it is\nnow possible to have a single .NET library (or WinRT projection\nassembly) including some UWP XAML types in the public API surface, and\nconsume it from both UWP apps (or libraries) and Win32 ones.<\/p>\n Imagine you have a WinRT component that is consumed from multiple\nplaces, some of which might be UWP, some Win32. Let\u2019s say you decide to\nadd one specific API that takes or returns a UWP XAML type as well, to\nsupport a specific scenario. Previously, that would\u2019ve been impossible:\nUWP XAML types simply did not exist on latest .NET, so there was no way\nto reference them at all. However, it is now instead possible to add a\nreference to them (by setting the \u201cUseUwp\u201d property), and still be\nconsumed by both UWP and Win32 (which of course will not be able to\nactually use those specific APIs with UWP XAML types), without the need\nto either ship two different assemblies that only differ by a handful of\nAPIs, or resort to other workarounds to \u201chide\u201d the types from the API\nsurface of the library (e.g.\u00a0such as only taking an This is only meant for very advanced scenarios (and comes with some\nadditional caveats, especially in case the library also references or is\nconsumed by Windows App SDK, since CsWinRT can only project either UWP\nXAML or WinUI 3 types in a given process), but it is yet another benefit\nthat comes as a side bonus from this preview support. For instance, we\ncan take advantage of this feature in some internal libraries used by\nseveral inbox apps and Windows modules, that ship as WinRT components\n(meaning they could leverage this for their .NET projections), because\nsome APIs reference UWP XAML types that could not previously be\nprojected correctly when the latest .NET version was being used.<\/p>\n As we mentioned before, this first preview does not include a XAML\ndesigner in Visual Studio. However, we are already working on this, and\nthanks to Ahmed Walid<\/a>, a\nMicrosoft MVP and Windows developer, who has been helping us put\ntogether this first preview (a huge shout-out to him, thank you!), we\nalready have a working prototype complete with the \u201cProperties\u201d windows\nas well! You can see it in action here:<\/p>\n We\u2019ll be working on integrating this prototype into an upcoming\nrelease of Visual Studio, so stay tuned! Here\u2019s also some of the other\nthings we\u2019re looking into right now, and that you can expect to see\navailable in the near future:<\/p>\n We\u2019re so excited to help UWP developers modernize their apps and\nleverage the latest .NET and C# advancements, as they move toward WinUI\n3 and Native AOT.<\/p>\n <\/i>Note<\/strong><\/p>Like we mentioned in the\nintroduction, the UWP support for .NET 9 is available in preview, so\nexpect some rough edges as we work on improving the developer\nexperience! We hope that in the long run, this will become the preferred\nway for UWP apps to use .NET and C#, and that as many developers as\npossible will be able to upgrade their existing UWP apps from .NET\nNative to the latest .NET and Native AOT.<\/div><\/p>\n If you hit any issues, there\u2019s multiple channels you can use to\nreport them:<\/p>\n Lastly, we want to thank everyone who contributed to this preview and\nhelped make this project happen. This was a collaborative effort between\nseveral teams across all of Microsoft, including the .NET and .NET SDK\nteams, the MSBuild team, the .NET Native and .NET diagnostics team, the\nVisual Studio team (including the owners of project templates, XAML\ndiagnostics, and the UWP workload), the Windows App SDK and WinUI team,\nthe Win2D team, the Windows Community Toolkit team, the XamlBehaviors\nteam, the Edge team, and the Store team. We also want to thank two\nMicrosoft MVPs for their contributions: Ahmed Walid<\/a>, for his help\nprototyping a big part of the changes necessary across Visual Studio and\nthe XAML compiler, as well as testing out early preview bits and\nproviding extremely useful feedback for us, and Dongle<\/a>, for prototyping\na fork of\nCsWinRT<\/a> with Windows.UI.Xaml support, and associated WinRT\nprojections<\/a>, which we used as reference for implementing the final\nchanges we shipped as part of CsWinRT and the official Windows SDK\nprojections. Thank you! \ud83c\udfc6<\/p>\n Happy coding!<\/strong> \ud83d\udda5\ufe0f<\/p>\n There is very often confusion around all the various Windows\ntechnologies around UWP, in part because there are so many relevant\nconcepts that are tightly interconnected, and the lines are often blurry\nbetween then. Let\u2019s take this opportunity to try to provide some\nclarity. Here is a small summary of the main components that UWP and\nWindows App SDK apps interact with. Some of these components are\northogonal to each other, but still closely related:<\/p>\n![\"Preview](\"https:\/\/devblogs.microsoft.com\/ifdef-windows\/wp-content\/uploads\/sites\/61\/2024\/09\/hero-image.png\")
<\/a><\/p>\nWhat is the UWP support for\n.NET 9<\/h2>\n
\n
How to get started<\/h2>\n
\n
\n
<\/a><\/p>\n<?xml<\/span> version=<\/span>\"1.0\"<\/span> encoding=<\/span>\"utf-8\"<\/span>?><\/span><\/span>\r\n<configuration<\/span>><\/span>\r\n <packageSources<\/span>><\/span>\r\n <clear<\/span> \/><\/span>\r\n <add<\/span> key=<\/span>\"nuget\"<\/span> value=<\/span>\"https:\/\/api.nuget.org\/v3\/index.json\"<\/span> \/><\/span>\r\n <add<\/span> key=<\/span>\"dotnet9\"<\/span> value=<\/span>\"https:\/\/pkgs.dev.azure.com\/dnceng\/public\/_packaging\/dotnet9\/nuget\/v3\/index.json\"<\/span> \/><\/span>\r\n <\/packageSources<\/span>><\/span>\r\n<\/configuration<\/span>><\/span><\/code><\/pre>\n<\/div>\nCreating a UWP .NET 9\nproject<\/h2>\n
<\/a><\/p>\n\n
Frame<\/code><\/a>,\na MainPage<\/code> that is navigated to, and minimal sample XAML\ncontent. This project template also features single-project MSIX\nsupport, just like WinUI 3 applications (and just like classic UWP\ndoes). This ensures a smooth migration path from classic UWP to WinUI 3\nas well.<\/li>\nApp.xaml<\/code> with shared\nresources and basic initialization of the root Frame<\/code> and\nnavigation to a page, and MainPage<\/code>, the default XAML page\nthat is displayed when the application is launched), with things that\nshould be familiar to you if you\u2019ve worked with modern .NET before. In\nparticular, we now (finally! \ud83c\udf8a) have an SDK-style .csproj file (no more\nsuper verbose legacy-style .csproj with all individual XAML and C# files\nlisted!), and a Properties<\/code> folder with some launch and\npublish settings.<\/p>\nError WMC1006: \"Cannot resolve Assembly or<\/span> Windows Metadata file<\/span> 'Type universe cannot resolve assembly: System.Windows.Forms, Version<\/span>=4<\/span>.0<\/span>.0.0<\/span>, Culture=neutral, PublicKeyToken=b77a5c561934e089.'\"<\/span><\/code><\/pre>\n<\/div>\n<PackageReference<\/span> Include=<\/span>\"Microsoft.Web.WebView2\"<\/span> Version=<\/span>\"1.0.2783-prerelease\"<\/span> IncludeAssets=<\/span>\"none\"<\/span> \/><\/span><\/code><\/pre>\n<\/div>\n<\/a><\/p>\n<\/a><\/p>\n\n
The project in detail<\/h2>\n
\n
INotifyPropertyChanged<\/code><\/a>\ninterface will be projected as Windows.UI.Xaml.Data.INotifyPropertyChanged<\/code><\/a>,\nas opposed to Microsoft.UI.Xaml.Data.INotifyPropertyChanged<\/code><\/a>.\nIf you\u2019re curious to check out these changes, see the .NET PR (dotnet\/sdk\/#41936<\/a>)\nand the CsWinRT PR (microsoft\/CsWinRT\/#1421<\/a>)\non GitHub.<\/li>\nPublishAot<\/code> (see\ndocs<\/a>) and DisableRuntimeMarshalling<\/code> (see\ndocs<\/a>) in the .csproj (and in all UWP .NET 9 project templates). This\nis because Native AOT is the only supported way for publishing\nUWP apps targeting .NET 9 in the Microsoft Store<\/strong>. This is meant\nto be a direct upgrade path for all UWP apps using .NET\nNative<\/a> today, and it also ensures that the usual fast startup of UWP\napps will be preserved. Additionally, the Microsoft Store does\nnot<\/strong> allow publishing UWP apps using managed code, so of\ncourse, Native AOT provides us with a modern solution for that native\ncode requirement.<\/p>\nBut wait, there\u2019s more!<\/h2>\n
MapControl<\/code><\/a>\ncan be hosted inside a full trust packaged Win32 app (e.g.\u00a0it could be a\nWindows Forms app, a WPF app, a WinUI 3 app, etc.), and used just like\nany other controls. You can do the same with any other UWP XAML controls\nas well!<\/p>\n<\/a><\/p>\nMapControl<\/code> relies on Bing Maps for Enterprise, which is\ndeprecated and will be retired. Thankfully though, the data sources for\nthe control are fully customizable. For this demo, we used the OpenStreetMap<\/a> data sources\ninstead, which you can also leverage if you plan on using this control.<\/div><\/p>\nThere\u2019s even more!<\/h3>\n
There\u2019s even<\/em> more!<\/h3>\n
object<\/code>\nor IInspectable*<\/code> parameter instead of the actual type).<\/p>\nWhat\u2019s next?<\/h2>\n
<\/a><\/p>\n\n
Summary<\/h2>\n
\n
#dev-csharp<\/code>). There\u2019s lots of\nother developers from the community that can help, and plenty of\nMicrosoft folks also hang out in the server!<\/li>\nGlossary<\/h2>\n
\n
CoreApplication<\/code><\/a>\ninstance, and may or may not use XAML for their UI. UWP is considered a\nlegacy application model for modern Windows apps, and developers are\nencouraged to migrate to WinUI 3 for long-term support. UWP applications\ncan run on any\nWindows device family<\/a> that supports the UWP contract. Nowadays, this\nmeans that UWP apps will be able to run on Windows Desktop, Xbox, IoT,\nand HoloLens. UWP applications have access to some exclusive APIs, such\nas CoreWindow<\/code><\/a>,\nand support features such as prelaunch<\/a>,\nsuspension<\/a>,\nrunning under modern\nstandby<\/a> (for out-of-process\nbackground tasks<\/a>), and more.<\/li>\n