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

C#/WinRT generates non specific assembly level SupportedOSPlatformAttribute #792

Closed
azchohfi opened this issue Apr 6, 2021 · 3 comments · Fixed by #829
Closed

C#/WinRT generates non specific assembly level SupportedOSPlatformAttribute #792

azchohfi opened this issue Apr 6, 2021 · 3 comments · Fixed by #829
Assignees
Labels
bug Something isn't working fixed Issue has been fixed in an upcoming or existing release
Milestone

Comments

@azchohfi
Copy link
Contributor

azchohfi commented Apr 6, 2021

Describe the bug
C#/WinRT code generated by providing a CsWinRTIncludes and CsWinRTWindowsMetadata makes it impossible to set an assembly level SupportedOSPlatformAttribute.

To Reproduce

  1. Create a project that uses C#/WinRT and project a winmd using CsWinRTIncludes and CsWinRTWindowsMetadata. Doing so will generate a file such as this one: "obj\x86\Debug\net5.0-windows10.0.19041.0\Generated Files\WinRT.cs". This file has this code at the very top:[assembly: global::System.Runtime.Versioning.SupportedOSPlatform("Windows")]
  2. Set <SupportedOSPlatformVersion>10.0.17763</SupportedOSPlatformVersion>. This will generate another [assembly: System.Runtime.Versioning.SupportedOSPlatformAttribute("Windows10.0.17763.0")], which conflicts with the first.
  3. Use any projected type, even from MUX.
  4. You will get CA1416 when calling any API from MUX, for example.

Expected behavior
No compilation warnings. The version that the developer sets in SupportedOSPlatformVersion should be respected and used in the code generation for the CsWinRT generation. Its fine to have mulitple instances of SupportedOSPlatformAttribute, but if there is a conflict at the same level, the lowest version is selected. Either this, or C#/WinRT should not generate an assembly level SupportedOSPlatform("Windows")], and replace it with a class level for each class that is generated by C#/WinRT, but I believe the first solution is simpler.

Version Info
C#/WinRT 1.2.0
.Net SDK 5.0.201

@azchohfi azchohfi added the bug Something isn't working label Apr 6, 2021
@angelazhangmsft
Copy link
Contributor

@azchohfi, I'm trying to repro - is step 2 setting SupportedOSPlatformVersion in the same library project as step 1, or are you setting that property in a separate C#/.NET 5 application that references the projection?

When I set <SupportedOSPlatformVersion>10.0.17763</SupportedOSPlatformVersion> in a C#/WinRT projection project, I see [assembly: global::System.Runtime.Versioning.SupportedOSPlatform("Windows")] in the generated WinRT.cs file. I would think it should be Windows10.0.17763.0 instead of Windows though.

@angelazhangmsft angelazhangmsft added this to the Release 1.2.3 milestone Apr 13, 2021
@azchohfi
Copy link
Contributor Author

ort step2, its on the same library.
I would make the same assumption as you. It should not add SupportedOSPlatform("Windows") if I specifically added the supported version that I said I want.

@Scottj1s
Copy link
Member

We can remove [assembly:global::System.Runtime.Versioning.SupportedOSPlatform("Windows")] from WinRT.cs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working fixed Issue has been fixed in an upcoming or existing release
Projects
None yet
3 participants