Issue building with Windows Desktop 6.0.2

[rbhanda]

We are aware of an issue where some customers are unable to run Windows Forms apps built against 6.0.2. This appears as a result of Windows Desktop servicing ref packs in 6.0.2.

This was reported on dotnet/winforms#6663 (Windows Forms) and in #7172 (comment) (WPF). We are working on a fix for this and will update this thread once we have a resolution.

Workaround

Add to the Project file and rebuild:

<ItemGroup>
<FrameworkReference
Update="Microsoft.WindowsDesktop.App;Microsoft.WindowsDesktop.App.WPF;Microsoft.WindowsDesktop.App.WindowsForms"
TargetingPackVersion="6.0.0" />
</ItemGroup>

Adding this will explicitly override the WindowsDesktop targeting pack used by the .NET 6.0.102 SDK, with the 6.0.0 WindowsDesktop targeting pack. This way you can use the .NET 6.0.102 SDK without using the broken .NET 6.0.2 WindowsDesktop targeting pack.

[philfontaine]

FYI, the workaround needs to be added to every referenced project that uses WPF/WinForms, not just the one being built.

Check #7176 (comment) for a more robust/scalable solution.

[pmeems]

I found this workaround from dotnet/winforms#6663.
I was having that issue in a Github Action for my 'x86 build and run unit test' only.
My x64 version had no issues.
After adding the suggested lines to my project, my unit tests (which uses some methods from my WinForm project) are working again.

[menees]

This workaround isn't working for my MegaBuild solution's .exe project. When I comment out the <UseWpf> property and comment out the few lines that require WPF in MainForm.cs, then it works. But when UseWpf is true, then I get these errors in the diagnostics MSBuild output:

2>            Encountered conflict between 'Reference:C:\Users\Bill\.nuget\packages\microsoft.windowsdesktop.app.ref\6.0.0\ref/net6.0/System.Windows.Forms.dll' and 'Reference:C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\6.0.2\ref/net6.0/System.Windows.Forms.dll'. Choosing 'Reference:C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\6.0.2\ref/net6.0/System.Windows.Forms.dll' because AssemblyVersion '6.0.2.0' is greater than '6.0.0.0'.
2>            Encountered conflict between 'Reference:C:\Users\Bill\.nuget\packages\microsoft.windowsdesktop.app.ref\6.0.0\ref/net6.0/System.Windows.Forms.dll' and 'Reference:C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\6.0.2\ref/net6.0/System.Windows.Forms.dll'. Choosing 'Reference:C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\6.0.2\ref/net6.0/System.Windows.Forms.dll' because AssemblyVersion '6.0.2.0' is greater than '6.0.0.0'.
2>            Encountered conflict between 'Reference:C:\Users\Bill\.nuget\packages\microsoft.windowsdesktop.app.ref\6.0.0\ref/net6.0/System.Windows.Forms.dll' and 'Reference:C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\6.0.2\ref/net6.0/System.Windows.Forms.dll'. Choosing 'Reference:C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\6.0.2\ref/net6.0/System.Windows.Forms.dll' because AssemblyVersion '6.0.2.0' is greater than '6.0.0.0'.
2>            Encountered conflict between 'Platform:System.Windows.Forms.dll' and 'Platform:System.Windows.Forms.dll'. Could not determine winner due to equal file and assembly versions.
2>            Encountered conflict between 'Platform:System.Windows.Forms.dll' and 'Platform:System.Windows.Forms.dll'. Could not determine winner due to equal file and assembly versions.

I've spent hours trying to resolve these conflicts, but I've been unsuccessful. I can't reproduce the problem in a small new WinForms app targeting 6.0, setting UseWpf=true, and pulling in similar references. Hopefully, someone here can take a look and point out the problem. The MSBuild diagnostic output is 241,646 lines long, so I don't want to post that here. But getting the MegaBuild repo (from https://github.com/menees/MegaBuild.git), building in VS 2022 with the 6.0.2 SDK produces a MegaBuild.dll for .NET 6.0 that still references System.Windows.Forms.dll v6.0.2. :-(

[RussKie]

@menees have you tried dotnet/winforms#6663 (comment)?

[menees]

Thanks, @RussKie! That worked! In addition to global.json, I added the following step to my GitHub build.yml workflow to make sure it will keep building successfully even when GitHub updates their windows-2022 image to a newer SDK:

- uses: actions/setup-dotnet@v1
  with:
    dotnet-version: '6.0.101' # SDK Version to use; x will use the latest version of the 6.0 channel. Force 101 for global.json compatibility.

[ebussa]

I believe this error is related to the issue so I'll share it here. I have a WPF app that should compile to a single file but fails with the error "error netsdk1112: the runtime pack for microsoft.windowsdesktop.app.runtime.win-x86 was not downloaded." I have restoration of missing packages enabled during the build.

@RussKie I now think the error above is caused by these errors:

XamlC error XFC0000 : Cannot resolve type "Application"
XamlC error XFC0000 : Cannot resolve type "Window".

I thought these errors were secondary but now I'm thinking they are primary. Here are the repro steps, but I'm not sure this issue belongs here? I've tried the FrameworkReference and globals.json workarounds but it doesn't seem to address this issue.

Repro Steps

1. Create a new WPF App.
2. Add a package reference to 'Xamarin.Forms'
3. XAML compiler can not resolve "Application" and "Window" types.

You may ask, why would I want to do this? I don't. In my solution that used to work prior to the Visual Studio update, I have a project that references a third party package (<PackageReference Include="Microcharts.Forms" Version="1.0.0-preview1" />). This package references Xamarin.Forms. Referencing the third party package also causes the XAML compiler to not resolve the "Application" and "Window" types.

Any help in solving this or where to create an issue is appreciated!

[RussKie]

If this is WPF related, please raise an issue in dotnet/wpf repo. You can also build with /bl flag to generate a binlog, and use MSBuild Structured Log Viewer tool to investigate what assemblies are referenced, and see where it's failing.

…

________________________________ From: Edward Bussa ***@***.***> Sent: Saturday, 19 February 2022 2:20 AM To: dotnet/core ***@***.***> Cc: Igor Velikorossov ***@***.***>; Mention ***@***.***> Subject: Re: [dotnet/core] Issue building with Windows Desktop 6.0.2 (Issue #7176) I believe this error is related to the issue so I'll share it here. I have a WPF app that should compile to a single file but fails with the error "error netsdk1112: the runtime pack for microsoft.windowsdesktop.app.runtime.win-x86 was not downloaded." I have restoration of missing packages enabled during the build. @RussKie<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FRussKie&data=04%7C01%7Cigor.velikorossov%40microsoft.com%7Cd235b993e89a4d1feaa508d9f2f2243c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637807944085038932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qDHjVGHdzqNnS5tJA4IheRdOxNyxpkYfpHD3Blee4HQ%3D&reserved=0> I now think the error above is caused by these errors: XamlC error XFC0000 : Cannot resolve type "Application" XamlC error XFC0000 : Cannot resolve type "Window". I thought these errors were secondary but now I'm thinking they are primary. Here are the repro steps, but I'm not sure this issue belongs here? I've tried the FrameworkReference and globals.json workarounds but it doesn't seem to address this issue. Repro Steps 1. Create a new WPF App. 2. Add a package reference to 'Xamarin.Forms' 3. XAML compiler can not resolve "Application" and "Window" types. You may ask, why would I want to do this? I don't. In my solution that used to work prior to the Visual Studio update, I have a project that references a third party package (<PackageReference Include="Microcharts.Forms" Version="1.0.0-preview1" />). This package references Xamarin.Forms. Referencing the third party package also causes the XAML compiler to not resolve the "Application" and "Window" types. Any help in solving this or where to create an issue is appreciated! — Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fcore%2Fissues%2F7176%23issuecomment-1044691028&data=04%7C01%7Cigor.velikorossov%40microsoft.com%7Cd235b993e89a4d1feaa508d9f2f2243c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637807944085038932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=BTZluVu2c3Ide8coJmORpulBzmAyF%2BJozzoY%2BOk7%2Bxg%3D&reserved=0>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABBTEXRC7SMLXOF7HBPUI6TU3ZPSLANCNFSM5N7G5XVQ&data=04%7C01%7Cigor.velikorossov%40microsoft.com%7Cd235b993e89a4d1feaa508d9f2f2243c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637807944085038932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C6LuXKvx2XK2jkjOXbne69DRG7prhjE05Zx8oFgPGXU%3D&reserved=0>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ThumbGen]

FYI, the workaround needs to be added to every referenced project that uses WPF/WinForms, not just the one being built.

Use Directory.Build.props for that. Directory.Build.targets is a better fit (see below)

[tomaszmalik]

FYI, the workaround needs to be added to every referenced project that uses WPF/WinForms, not just the one being built.

Use Directory.Build.props for that.

You should use Directory.Build.targets, otherwise it would not override default reference.

Directory.Build.targets content:

<Project>
  <ItemGroup Condition="'$(TargetFramework)' == 'net6.0-windows'">
    <FrameworkReference
        Update="Microsoft.WindowsDesktop.App;Microsoft.WindowsDesktop.App.WPF;Microsoft.WindowsDesktop.App.WindowsForms"
        TargetingPackVersion="6.0.0" />
  </ItemGroup>
</Project>