Exception on startup with version 8.3.0

[LeDahu22]

Describe the bug

Hi,

After upgrading from 8.2.2 to 8.3.0, as soon I run my WPF application, I've got the following exception :

System.TypeInitializationException : 'The type initializer for 'Module' threw an exception.'
FileNotFoundException : Could not load file or assembly 'WinRT.Runtime, Version=2.1.0.0, Culture=neutral, PublicKeyToken=99ea127f02d97709'. Specified file not found.

It crashes on the very first line of OnStartup method :

IHost host = CreateHostBuilder().Build();

There seems to be something wrong related to WinRT.Runtime.

Thanks

Regression

8.2.2

Steps to reproduce

Not sure if I can provide a repro sample easily...

Expected behavior

App should start with no exception

IDE and version

VS 2022

IDE version

17.11.2

Nuget packages

• CommunityToolkit.Common
• CommunityToolkit.Diagnostics
• CommunityToolkit.HighPerformance
• CommunityToolkit.Mvvm (aka MVVM Toolkit)

Nuget package version(s)

8.3.0

Help us help you

No, just wanted to report this

[Sergio0694]

This is unfortunate, but I think it's expected so far until the new .NET SDK comes out. The problem is that the MVVM Toolkit is using the new Windows SDK projections, but your app is trying to use the old ones (because you have an old version of the .NET SDK that doesn't know about this new version yet). As a workaround, can you try adding this to your .csproj file:

<WindowsSdkPackageVersion>10.0.22621.41</WindowsSdkPackageVersion>

Replace 22621 with whatever Windows SDK you're using as target (it should match your TargetFramework). For instance:

<TargetFramework>net8.0-windows10.0.18362.0</TargetFramework>
<WindowsSdkPackageVersion>10.0.18362.41</WindowsSdkPackageVersion>

Let me know if this solves the issue for you! 🙂

[jysong74]

I also encountered this problem.

[LeDahu22]

@Sergio0694 Thank you for your quick answer, I changed my csproj to what you advised and the issue went away

<TargetFramework>net8.0-windows10.0.18362.0</TargetFramework> <WindowsSdkPackageVersion>10.0.18362.41</WindowsSdkPackageVersion>

Thanks a lot ! 😃

[hungchips]

• In my csproj there is no line <WindowsSdkPackageVersion>10.0.18362.41</WindowsSdkPackageVersion>
• If I try to paste it in, when building it says:
  Severity Code Description Project File Line Suppression State Details
  Error (active) NU1102 Unable to find package Microsoft.Windows.SDK.NET.Ref with version (= 10.0.26100)
• Found 263 version(s) in nuget.org [ Nearest version: 10.0.26100.1 ]
• Found 0 version(s) in Microsoft Visual Studio Offline Packages
• Found 0 version(s) in C:\Program Files\dotnet\library-packs NameProject (net8.0-windows10.0.26100.0) F:\Apps\XXX\XXXX\NameProject.csproj 1

[Sergio0694]

Like I said, you need to use a package version that matches your target framework SDK version.

So for instance, if you have:

<TargetFramework>net8.0-windows10.0.26100.0</TargetFramework>

Then you need:

<WindowsSdkPackageVersion>10.0.26100.41</WindowsSdkPackageVersion>

Etc., basically just replace the last .0 with .41 from the target framework.

[LucaCris]

@Sergio0694, my project is a universal dll, so no target framework:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="CommunityToolkit.Mvvm" Version="8.2.2" />
  </ItemGroup>

What to add here, on upgrade? Or I need to set it in the caller project?

[bagusnl]

After adding WindowsSdkPackageVersion identifier, I get different error

Error CS0433 : The type 'TextDecorations' exists in both 'Microsoft.WinUI, Version=3.0.0.0, Culture=neutral, PublicKeyToken=de31ebe4ad15742b' and 'Microsoft.Windows.SDK.NET, Version=10.0.22621.38, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

here is our target settings

        <Platforms>x64</Platforms>
        <TargetFramework>net8.0-windows10.0.22621.0</TargetFramework>
        <WindowsSdkPackageVersion>10.0.22621.41</WindowsSdkPackageVersion>
        <TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
        <RuntimeIdentifier>win-x64</RuntimeIdentifier>
        <EnableWindowsTargeting>true</EnableWindowsTargeting>

Project is using WinUI3

[Sergio0694]

That is expected if you're using an older version of WinAppSDK. You need to update to 1.6 preview 2, or later.

[Sergio0694]

"Or I need to set it in the caller project?"

@LucaCris you need to add that in the consuming project (presumably, your app) that's targeting Windows 🙂

[LucaCris]

That is expected if you're using an older version of WinAppSDK. You need to update to 1.6 preview 2, or later.

1.6 preview 2?! Ok... nothing for now. :(

[hungchips]

sorry for rushing to give you a bad review. But how can I download and install Windows 11 SDK version 10.0.26100.41?

Because I tried to edit csproj 10.0.26100.0 -> 10.0.26100.41.
This resulted in no SDK on my Project to perform Build.
I tried to type the command dotnet restore but it couldn't install the SDK itself.

Currently on Visual Studio Installer Windows 11 SDK version 10.0.26100.0 is the latest, I can't choose other versions at all. (Maybe it only exists in beta versions? I haven't checked it myself).

[Sergio0694]

Once again, you are modifying the wrong thing. You should not change your target framework. Just follow exactly the steps I provided in #923 (comment). Only add WindowsSdkPackageVersion with the right version based on your target framework. You do not need to change the target framework. You do not need to install any Windows SDK.

For instance, if you have:

<TargetFramework>net8.0-windows10.0.22621.0</TargetFramework>

Then leave that as is and just also add this:

<WindowsSdkPackageVersion>10.0.22621.41</WindowsSdkPackageVersion>

That's it.

[4broadcast]

I don't think this issue should be closed. Others, like I did, are going to miss this because it is not an open issue, and will have to search closed issues. And in my humble opinion, it is an open issue that this "stable" release relies on a preview of the SDK.

[Sergio0694]

I pinned this issue yesterday for visibility. It's closed because it's not an issue with the MVVM Toolkit itself.

"this "stable" release relies on a preview of the SDK"

It does not. There are no references anywhere in the .NET Community Toolkit to preview builds of the .NET SDK. The VM image used in the pipeline that builds the repo doesn't have access to the preview of the .NET SDK either. This is the same exact issue that WinAppSDK 1.6 will also have when they release in stable soon: it will not work correctly for people using a .NET SDK that has not been updated. The only difference is that WinAppSDK includes a custom target that generates a build error to detect that scenario, whereas the MVVM Toolkit does not. But the point is that without either overriding the Windows SDK package version manually, or updating the .NET SDK to a version that knows about the new SDK projections, things will not work.

[eduardoagr]

I put this

`

<PropertyGroup>
	<TargetFrameworks>net8.0-android;net8.0-ios;net8.0-maccatalyst</TargetFrameworks>
	<TargetFrameworks Condition="$([MSBuild]::IsOSPlatform('windows'))">$(TargetFrameworks);net8.0-windows10.0.26100.0</TargetFrameworks>
	<WindowsSdkPackageVersion>windows10.0.26100.0</WindowsSdkPackageVersion>
	<!-- Uncomment to also build the tizen app. You will need to install tizen by following this: https://github.com/Samsung/Tizen.NET -->
	<!-- <TargetFrameworks>$(TargetFrameworks);net8.0-tizen</TargetFrameworks> -->

	<!-- Note for MacCatalyst:
	The default runtime is maccatalyst-x64, except in Release config, in which case the default is maccatalyst-x64;maccatalyst-arm64.
	When specifying both architectures, use the plural <RuntimeIdentifiers> instead of the singular <RuntimeIdentifier>.
	The Mac App Store will NOT accept apps with ONLY maccatalyst-arm64 indicated;
	either BOTH runtimes must be indicated or ONLY macatalyst-x64. -->
	<!-- For example: <RuntimeIdentifiers>maccatalyst-x64;maccatalyst-arm64</RuntimeIdentifiers> -->

	<OutputType>Exe</OutputType>
	<RootNamespace>METROWIND</RootNamespace>
	<UseMaui>true</UseMaui>
	<SingleProject>true</SingleProject>
	<ImplicitUsings>enable</ImplicitUsings>
	<Nullable>enable</Nullable>

	<!-- Display name -->
	<ApplicationTitle>METROWIND</ApplicationTitle>

	<!-- App Identifier -->
	<ApplicationId>com.companyname.metrowind</ApplicationId>

	<!-- Versions -->
	<ApplicationDisplayVersion>1.0</ApplicationDisplayVersion>
	<ApplicationVersion>1</ApplicationVersion>

`

and errors

[4broadcast]

@Sergio0694 fair enough, I misunderstood one of your earlier comments & missed the pin.

Still can't get it to work w/ workaround, but I'm gonna wait 'til all this shakes out. I have enough trouble getting my own code to work.

[eduardoagr]

This should be opened again

[Sergio0694]

@eduardoagr you did not set the correct values. Please follow my instructions in #923 (comment) and #923 (comment).

[eduardoagr]

@Sergio0694 I did

`
net8.0-android;net8.0-ios;net8.0-maccatalyst
$(TargetFrameworks);net8.0-windows10.0.19041.0

<!-- Note for MacCatalyst:
The default runtime is maccatalyst-x64, except in Release config, in which case the default is maccatalyst-x64;maccatalyst-arm64.
When specifying both architectures, use the plural <RuntimeIdentifiers> instead of the singular <RuntimeIdentifier>.
The Mac App Store will NOT accept apps with ONLY maccatalyst-arm64 indicated;
either BOTH runtimes must be indicated or ONLY macatalyst-x64. -->
<!-- For example: <RuntimeIdentifiers>maccatalyst-x64;maccatalyst-arm64</RuntimeIdentifiers> -->

<OutputType>Exe</OutputType>
<RootNamespace>METROWIND</RootNamespace>
<UseMaui>true</UseMaui>
<SingleProject>true</SingleProject>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>

<WindowsSdkPackageVersion>10.0.19041.0</WindowsSdkPackageVersion>

<!-- Display name -->
<ApplicationTitle>METROWIND</ApplicationTitle>`

[Sergio0694]

"I did"

You did not. Like I clearly said in both my comments, especially in #923 (comment):

"basically just replace the last .0 with .41 from the target framework."

In your screenshot, you're using 10.0.19041.0 for WindowsSdkPackageVersion. You need 10.0.19041.41.

[eduardoagr]

@Sergio0694 Than you and sorry for the trouble, are you considering adding this, for future releases

[Sergio0694]

No worries. No, this is not something that we'll add to the MVVM Toolkit. Like I explained in #923 (comment), this is a problem in outdated versions of the .NET SDK. As soon as the new update for the .NET SDK is released next month, this will just work with no changes needed. Manually setting the package version is a temporary workaround, but you should remove it when the new .NET SDK is out (as you don't want to hardcode a package version that will be eventually outdated) 🙂

[jarvis10211]

Just change
"<TargetFramework>net8.0-windows10.xxx</TargetFramework>"
to
"<TargetFramework>net8.0-windows</TargetFramework>"

Works Well.

[Sergio0694]

There's no need to use that tone. We did not realize this would be an actual issue before we released the package, that's why the disclaimer doesn't mention it. I've unlisted the package on NuGet for the time being, and will list it again after the servicing .NET SDK update. That should help minimize issues in the meantime. I'll also mention this in the release notes just in case.

[eduardoagr]

@Balkoth dude how can you be a developer with that attitude? This is not anyone fault and @Sergio0694 is only trying to help. I had to bother him a couple of times times, and you know what this is probably the best package we have for Windows development.

Do you think you are acomplinshing anything by using that tone?

[sdb7]

me work well, thankyou @Sergio0694

yes, i understand people are upset, I postponed a project for a week, me frustrated but that's because me overlooked something.

pardon the english.

[LucaCris]

SDK 1.6 just released, if someone can test it now...

[rlatm]

The release notes mention needing the .NET SDK version > 8.0.400 (or the "temporary workaround" of the WindowsSdkPackageVersion).

I verified that I have .NET SDK > 8.0.400 - 8.0.401 specifically (and only that version). However, I still receive the original error. Is this fixed in .NET SDK > 8.0.400 ?

> dotnet --list-sdks
8.0.401 [C:\Program Files\dotnet\sdk]
> dotnet --version
8.0.401
> ls "C:\Program Files\dotnet\Sdk"
[only 8.0.401]

I restarted Windows. I deleted all /bin/ and /obj/ folders. I verified that the servicing release version number is the third part of the version number ( https://learn.microsoft.com/en-us/dotnet/core/releases-and-support#minor-releases ). I searched this repo and found no mentions of 8.0.401.

Thank you!

[Sergio0694]

Ah, typo, I meant to say 8.0.403, fixed it! Also I'll be releasing a hotfix soon with a built-in diagnostics to help out 🙂

[Sergio0694]

Hey everyone! Thank you all for the feedback. I've just published a new 8.3.1 hotfix update that includes the changes in #942. This is a new custom targets that will validate the Windows SDK package version and emit a helpful error message to spot issues right at build time. It will also tell you exactly which package version to set in case the one you have isn't compatible.

Hope this helps! 🙂

[mikeKuester]

Hi,

after updating to the latest Visual Studio Version 17.11.5, the installed SDKs are updated: https://github.com/microsoft/CsWinRT/releases/tag/2.1.5.241003.1

For .NET 8 for example I have to use the .47 now:

<WindowsSdkPackageVersion>10.0.19041.47</WindowsSdkPackageVersion>

Hope that helps if some runs into the same problem after the update.