{"id":2135,"date":"2021-12-17T19:23:49","date_gmt":"2021-12-18T00:23:49","guid":{"rendered":"https:\/\/badecho.com\/?p=2135"},"modified":"2022-11-15T20:18:41","modified_gmt":"2022-11-16T01:18:41","slug":"net-6-xaml-mayhem","status":"publish","type":"post","link":"https:\/\/badecho.com\/index.php\/2021\/12\/17\/net-6-xaml-mayhem\/","title":{"rendered":".NET 6 XAML Markup Compiler Mayhem"},"content":{"rendered":"\n
\".NET<\/figure><\/div>\n\n\n\n

A little over a month ago, I found myself greeting the new day with my usual fairly-cheery demeanor by taking a quick look at all the latest news and goings-on in the tech world.<\/p>\n\n\n\n

Lo and behold! I was greeted with grand news indeed: the release of a new version of .NET, along with Visual Studio 2022<\/a>. Well, to be honest, I really was just starting<\/em> to get nice and comfy with .NET 5, but one must keep up with the times!<\/p>\n\n\n\n

I immediately set forth to acquire this newly sanctified development stack with the intention to eventually port my Bad Echo technologies<\/a> and related applications to the new version, which were, of course, previously running on .NET 5 and being developed using Visual Studio 2019. <\/p>\n\n\n\n

It was my plan to continue working on my Bad Echo tech within my Visual Studio 2019 environment, comfortably and at my leisure, while examining the new platform and IDE. Only when all the right chips were in place would I be making the move to the new .NET version…<\/p>\n\n\n\n

Alas, this was not to be.<\/p>\n\n\n\n

XAML Compiler Errors in VS 2019 After Upgrade<\/h2>\n\n\n\n

With Visual Studio 2022 being a separate product from Visual Studio 2019, as well as .NET 6 being a separate platform from .NET 5, one might expect a small amount of insulation between the two environments. In other words, you would hope that installing the latest and the greatest wouldn’t impact your current development environment.<\/p>\n\n\n\n

Sadly, my code, which compiled just fine in VS 2019 before the upgrade, started to throw errors in VS 2019 after installing VS 2022 and .NET 6.<\/p>\n\n\n\n

This was very strange, as my code was still targeting .NET 5…<\/h5>\n\n\n\n

The particular error I was getting was centered around some keyed resources I had defined in the Extensibility framework for Vision<\/em>, the game overlay application I created to provide on-demand visual data for Omnified<\/a> games.<\/p>\n\n\n\n

Vision<\/em> comprises several plugins, each corresponding to various Omnified systems. The Extensibility framework for Vision, found in BadEcho.Vision.Extensibility.dll<\/strong>, is a unifying library which all these plugins reference so they can all speak the same lingo and all walk the same walk.<\/p>\n\n\n\n

And one of the ways these plugins walk the same walk is by having shared visual elements, such as coloring, etc. These common theme elements are defined in a resource dictionary in this particular Extensibility library. <\/p>\n\n\n\n

Now, whenever I define a WPF resource in a common DLL that I expect other assemblies to reference, I like a bit more assurance than just an easily misspelled string name for the key.<\/p>\n\n\n\n

Type safety!<\/h5>\n\n\n\n

That’s what I like. And I achieve this in a similar way (though not exactly the same way, but I digress as that leads to a whole other discussion) we reference the various system colors exposed by WPF’s built-in SystemColors<\/code> class.<\/p>\n\n\n\n

To make use of these system colors, we reference them via the x:Static<\/code> markup extension — e.g., {x:Static SystemColors.HighlightBrush}<\/code>. <\/p>\n\n\n\n

If I spell the name of this “resource” wrong, we’ll get a compiler error. Not so with a simple string-based key name; we won’t know about any issues with those until runtime! <\/p>\n\n\n\n

That kind of assurance one gets when interfacing with static resource keys such as those exposed by SystemColors<\/code> is what I like to have with my own shared resources whose consumers are external and potentially many. Unfortunately, the .NET 6 install wasn’t having any of that!<\/p>\n\n\n\n

The Problem Code<\/h2>\n\n\n\n

I won’t go into detail how my static resource key names work, all we need to understand is that they work like any other kind of value one might assign to the key of a resource, with the added benefit that compilation fails if any kind of fat-fingering (i.e., mistyping-of-the-key) occurs.<\/p>\n\n\n\n

Prior to installing Visual Studio 2022 and .NET 6, the following code was compiling just fine:<\/p>\n\n\n

\n<SolidColorBrush x:Key="{x:Static t:Brushes.TextForegroundKey}" \n                 Color="{StaticResource {x:Static t:Colors.TextColorKey}}"\n                 f:Freeze="True" \n                 \/>\n<SolidColorBrush x:Key="{x:Static t:Brushes.CriticalTextForegroundKey}" \n                 Color="{StaticResource {x:Static t:Colors.CriticalTextColorKey}}"\n                 f:Freeze="True" \n                 \/>\n\n<SolidColorBrush x:Key="{x:Static t:Brushes.OutlinedTextStrokeKey}"\n                 Color="{StaticResource {x:Static t:Colors.OutlineColorKey}}"\n                 f:Freeze="True"\n                 \/>\n\n<SolidColorBrush x:Key="{x:Static t:Brushes.FadedOutlinedTextStrokeKey}"\n                 Color="{StaticResource {x:Static t:Colors.FadingOutlineColorKey}}"\n                 f:Freeze="True"\n                 \/>\n<\/pre>\n\n\n
After the update, the same code failed (again, in<\/em> Visual Studio 2019) with the following errors:<\/p>\n\n\n\n
1>C:\\src\\BadEcho\\src\\Vision.Extensibility\\AnchorPointLocation.cs(14,1,45,2): \nwarning CA1707: Remove the underscores from assembly name \nBadEcho.Vision.Extensibility_po1jwjdd_wpftmp\n\n1>C:\\src\\BadEcho\\src\\Vision.Extensibility\\Themes\\Resources\\Coloring.xaml(25,22): \nerror MC3050: Cannot find the type 'Colors'. Note that type names are case sensitive.\n\n1>C:\\src\\BadEcho\\src\\Vision.Extensibility\\Themes\\Resources\\VisionTitleTextStyle.xaml(19,33): \nerror MC3050: Cannot find the type 'Brushes'. Note that type names are case sensitive.\n1>    1 Warning(s)\n1>    2 Error(s)<\/code><\/pre>\n\n\n\n
First of all, what is going on with that first warning with the malformed project name? It looks like the compiler literally swallowed my project and involuntarily regurgitated it back up in a corrupted form.<\/p>\n\n\n\n
Secondly, the actual errors at hand, which indicate that the compiler is unable to find the types Colors<\/code> and Brushes<\/code> referenced in the file, are also problematic as these types are defined in the very same assembly that this ResourceDictionary<\/code> exists in.<\/p>\n\n\n\n
Very strange…<\/p>\n\n\n\n
.NET 5, But Not Completely .NET 5<\/h2>\n\n\n\n
I first wanted to see how an install of .NET 6 and Visual Studio 2022, both different products from Visual Studio 2019, could cause this. I turned on detailed diagnostic logging with MSBuild in Visual Studio 2019, and saw something very interesting right away:<\/p>\n\n\n\n
1>Target MarkupCompilePass2:\n1>  Task \"Message\" skipped, due to false condition; ('$(MSBuildTargetsVerbose)'=='true') was \nevaluated as (''=='true').\n1>  Using \"MarkupCompilePass2\" task from assembly \n\"C:\\Program Files\\dotnet\\sdk\\6.0.100\\Sdks\\Microsoft.NET.Sdk.WindowsDesktop\\tools\\net472\\\nPresentationBuildTasks.dll\".\n1>  Task \"MarkupCompilePass2\"\n1>\n1>    Microsoft (R) Build Task 'MarkupCompilePass2' Version '6.0.21.52301'.\n1>    Copyright (C) Microsoft Corporation 2005. All rights reserved.\n1>\n1>    Current project directory is 'C:\\src\\BadEcho\\src\\Vision.Extensibility\\'.\n1>    Preparing for the markup compilation...<\/code><\/pre>\n\n\n\n
Well, this is a bit alarming…<\/h5>\n\n\n\n
Vision<\/em>‘s Extensibility project was targeting .NET 5, yet for some reason it was using .NET 6’s XAML markup compiler. Not sure if this is intentional on Microsoft’s part; it’s difficult to see it as anything other than a bug.<\/p>\n\n\n\n
Well, even if we’ve determined that our .NET 5 project is using an incorrect version of the markup compiler, this doesn’t solve our particular problem at hand, which will surely remain a problem upon transitioning the codebase so it targets .NET 6.<\/p>\n\n\n\n
Indeed, after doing so, this error persisted.<\/p>\n\n\n\n
Temporary Target Assembly Gibberish<\/h2>\n\n\n\n
Not much further up the build log from where I just posted, we see the task GenerateTemporaryTargetAssembly<\/code> being executed. It was my assumption that this particular task was responsible for creating those *_wpftmp.csproj<\/strong> malformations of my Extensibility’s project file name.<\/p>\n\n\n\n
It was also my assumption that perhaps these temporary assemblies, project names, or what-have-you were also perhaps in part responsible for our inability to resolve types defined in the same assembly within our ResourceDictionary<\/code> XAML markup.<\/p>\n\n\n\n
So why were these temporary assemblies being generated? The same reason anything strange happens in the land of MSBuild: because of an unexpected MSBuild property of course!<\/p>\n\n\n\n
Deep within the bowels of MSBuild, exists a property known as <IncludePackageReferencesDuringMarkupCompilation\/><\/code>, which is assigned a Boolean value. I suppose the option does exactly what its name indicates, and that supposition will have to do, since documentation is a bit scant in this particular area.<\/p>\n\n\n\n
Apparently, this setting defaulted to false<\/code> in .NET 5.0, however that is no longer the case in .NET 6.0. Indeed, it is on by default, and it would appear that this option, when enabled, is what is responsible for generating all those temporary assemblies and causing my error.<\/p>\n\n\n\n
The Temporary Assembly Mayhem Fix<\/h2>\n\n\n\n
Things were definitely better off as they were before. Not sure what this newly-enabled option is supposed to do, but I definitely don’t like it.<\/p>\n\n\n\n
To correct the issue, and once again bring about lovely error-free compiles, I stuck the following into the existing root <PropertyGroup\/><\/code> in my repository’s Directory.build.props<\/strong> file:<\/p>\n\n\n
\n<PropertyGroup>\n  .\n  .\n  <IncludePackageReferencesDuringMarkupCompilation>\n\t  false\n  <\/IncludePackageReferencesDuringMarkupCompilation>\n  .\n  .\n<\/PropertyGroup>\n<\/pre>\n\n\n
And all was well.<\/p>\n\n\n\n
Hope this saves someone else out there a headache or two!<\/p>\n","protected":false},"excerpt":{"rendered":"
A little over a month ago, I found myself greeting the new day with my usual fairly-cheery demeanor by taking […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[10],"tags":[41,42,64,70],"yoast_head":"\r\n.NET 6 XAML Markup Compiler Mayhem - omni's hackpad<\/title>\r\n<meta name=\"description\" content=\"I was excited to upgrade to the new .NET 6, but much less excited to see it generating strange temporary assemblies borking my WPF projects.\" \/>\r\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\r\n<link rel=\"canonical\" href=\"https:\/\/badecho.com\/index.php\/2021\/12\/17\/net-6-xaml-mayhem\/\" \/>\r\n<meta property=\"og:locale\" content=\"en_US\" \/>\r\n<meta property=\"og:type\" content=\"article\" \/>\r\n<meta property=\"og:title\" content=\".NET 6 XAML Markup Compiler Mayhem - omni's hackpad\" \/>\r\n<meta property=\"og:description\" content=\"I was excited to upgrade to the new .NET 6, but much less excited to see it generating strange temporary assemblies borking my WPF projects.\" \/>\r\n<meta property=\"og:url\" content=\"https:\/\/badecho.com\/index.php\/2021\/12\/17\/net-6-xaml-mayhem\/\" \/>\r\n<meta property=\"og:site_name\" content=\"omni's hackpad\" \/>\r\n<meta property=\"article:published_time\" content=\"2021-12-18T00:23:49+00:00\" \/>\r\n<meta property=\"article:modified_time\" content=\"2022-11-16T01:18:41+00:00\" \/>\r\n<meta property=\"og:image\" content=\"https:\/\/badecho.com\/wp-content\/uploads\/2021\/12\/BlowingUpMyXAML.png\" \/>\r\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\r\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebSite\",\"@id\":\"https:\/\/badecho.com\/#website\",\"url\":\"https:\/\/badecho.com\/\",\"name\":\"omni's hackpad\",\"description\":\"Game Code Disassembly. Omnified Modification. Madness.\",\"publisher\":{\"@id\":\"https:\/\/badecho.com\/#\/schema\/person\/3de67496328be7ae6e1f52faf582e9d2\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":\"https:\/\/badecho.com\/?s={search_term_string}\",\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"en-US\"},{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/badecho.com\/index.php\/2021\/12\/17\/net-6-xaml-mayhem\/#primaryimage\",\"inLanguage\":\"en-US\",\"url\":\"https:\/\/badecho.com\/wp-content\/uploads\/2021\/12\/BlowingUpMyXAML.png\",\"width\":856,\"height\":456,\"caption\":\".NET 6 is doing some strange things to the names of my projects...\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/badecho.com\/index.php\/2021\/12\/17\/net-6-xaml-mayhem\/#webpage\",\"url\":\"https:\/\/badecho.com\/index.php\/2021\/12\/17\/net-6-xaml-mayhem\/\",\"name\":\".NET 6 XAML Markup Compiler Mayhem - omni's hackpad\",\"isPartOf\":{\"@id\":\"https:\/\/badecho.com\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/badecho.com\/index.php\/2021\/12\/17\/net-6-xaml-mayhem\/#primaryimage\"},\"datePublished\":\"2021-12-18T00:23:49+00:00\",\"dateModified\":\"2022-11-16T01:18:41+00:00\",\"description\":\"I was excited to upgrade to the new .NET 6, but much less excited to see it generating strange temporary assemblies borking my WPF projects.\",\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/badecho.com\/index.php\/2021\/12\/17\/net-6-xaml-mayhem\/\"]}]},{\"@type\":\"Article\",\"@id\":\"https:\/\/badecho.com\/index.php\/2021\/12\/17\/net-6-xaml-mayhem\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/badecho.com\/index.php\/2021\/12\/17\/net-6-xaml-mayhem\/#webpage\"},\"author\":{\"@id\":\"https:\/\/badecho.com\/#\/schema\/person\/3de67496328be7ae6e1f52faf582e9d2\"},\"headline\":\".NET 6 XAML Markup Compiler Mayhem\",\"datePublished\":\"2021-12-18T00:23:49+00:00\",\"dateModified\":\"2022-11-16T01:18:41+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/badecho.com\/index.php\/2021\/12\/17\/net-6-xaml-mayhem\/#webpage\"},\"publisher\":{\"@id\":\"https:\/\/badecho.com\/#\/schema\/person\/3de67496328be7ae6e1f52faf582e9d2\"},\"image\":{\"@id\":\"https:\/\/badecho.com\/index.php\/2021\/12\/17\/net-6-xaml-mayhem\/#primaryimage\"},\"keywords\":\".NET,C#,WPF,XAML\",\"articleSection\":\"General Dev\",\"inLanguage\":\"en-US\"},{\"@type\":[\"Person\",\"Organization\"],\"@id\":\"https:\/\/badecho.com\/#\/schema\/person\/3de67496328be7ae6e1f52faf582e9d2\",\"name\":\"Matt Weber\",\"image\":{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/badecho.com\/#personlogo\",\"inLanguage\":\"en-US\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/7e345ac2708b3a41c7bd70a4a0440d41?s=96&d=mm&r=g\",\"caption\":\"Matt Weber\"},\"logo\":{\"@id\":\"https:\/\/badecho.com\/#personlogo\"}}]}<\/script>\r\n<!-- \/ Yoast SEO plugin. -->","_links":{"self":[{"href":"https:\/\/badecho.com\/index.php\/wp-json\/wp\/v2\/posts\/2135"}],"collection":[{"href":"https:\/\/badecho.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/badecho.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/badecho.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/badecho.com\/index.php\/wp-json\/wp\/v2\/comments?post=2135"}],"version-history":[{"count":22,"href":"https:\/\/badecho.com\/index.php\/wp-json\/wp\/v2\/posts\/2135\/revisions"}],"predecessor-version":[{"id":2531,"href":"https:\/\/badecho.com\/index.php\/wp-json\/wp\/v2\/posts\/2135\/revisions\/2531"}],"wp:attachment":[{"href":"https:\/\/badecho.com\/index.php\/wp-json\/wp\/v2\/media?parent=2135"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/badecho.com\/index.php\/wp-json\/wp\/v2\/categories?post=2135"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/badecho.com\/index.php\/wp-json\/wp\/v2\/tags?post=2135"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}