Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows App SDK new projects should automatically set a default TFM and Windows SDK package version, as necessary #4734

Open
Scottj1s opened this issue Sep 19, 2024 · 6 comments
Labels
area-DeveloperTools Issues related to authoring (source and IDL), debugging, HotReload, LiveVisualTree, VS integration

Comments

@Scottj1s
Copy link
Member

Describe the bug

C#/WinRT is used to generate .NET projection assemblies for both Windows App SDK and the Windows SDK. On occasion, these must be updated together to maintain compatibility (e.g., with the introduction of AOT support in Windows App SDK 1.6). But since they are released independently, setting WindowsSdkPackageVersion is sometimes necessary for a project to override the version of the Windows SDK projection implied by the TFM and the current .NET SDK. Microsoft.WindowsAppSDK.targets attempts to be helpful here, reporting an error indicating the project edits necessary to resolve potential runtime incompatibility errors. This behavior is a sharp edge, as the required user action is not simple or obvious. Ideally, the Windows App SDK would automatically default the Windows SDK projection to the revision necessary to ensure compat (e.g., 38). The same consideration should apply to generating a default TFM, with a minimum .NET version required. Both project creation and update scenarios should be supported.

Steps to reproduce the bug

  1. Create a new C# WinUI project, or update an existing one, referencing Windows App SDK 1.6
  2. Build
  3. An error results, informing the user of the need to override the Windows SDK package version, via WindowsSdkPackageVersion

Expected behavior

A new project should build and run without error

Screenshots

No response

NuGet package version

Windows App SDK 1.6.0: 1.6.240829007

Packaging type

No response

Windows version

No response

IDE

No response

Additional context

No response

@Scottj1s
Copy link
Member Author

Tracked internally with https://task.ms/54014544

@RieBi
Copy link

RieBi commented Sep 20, 2024

I must admit, "Please update to .NET SDK 6.0.134, 6.0.426, 8.0.109, 8.0.305 or 8.0.402" is quite a misleading error message. Such SDK versions simply do not exist.

@Balkoth
Copy link

Balkoth commented Sep 26, 2024

And now 8.0.402 is out but without support for Visual Studio 2022.

@codendone codendone added area-DeveloperTools Issues related to authoring (source and IDL), debugging, HotReload, LiveVisualTree, VS integration and removed needs-triage labels Sep 26, 2024
@manodasanW
Copy link
Member

And now 8.0.402 is out but without support for Visual Studio 2022.

It looks like .NET has decided to reuse version 8.0.402 for a hotfix release to address some other issues. There is still an update coming out on their typical .NET SDK servicing cadence which is still expected next month.

@Balkoth
Copy link

Balkoth commented Sep 27, 2024

This version number is at this time in all the error messages in Visual Studio. What the f...

@LucaCris
Copy link

LucaCris commented Oct 5, 2024

Just (re)tried... New Packaged WinUI3 wizard: unable to build App. Even inserting the "temporary" workaround attribute...

Please, come on...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-DeveloperTools Issues related to authoring (source and IDL), debugging, HotReload, LiveVisualTree, VS integration
Projects
None yet
Development

No branches or pull requests

6 participants