You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
C#/WinRT code generated by providing a CsWinRTIncludes and CsWinRTWindowsMetadata makes it impossible to set an assembly level SupportedOSPlatformAttribute.
To Reproduce
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")]
Set <SupportedOSPlatformVersion>10.0.17763</SupportedOSPlatformVersion>. This will generate another [assembly: System.Runtime.Versioning.SupportedOSPlatformAttribute("Windows10.0.17763.0")], which conflicts with the first.
Use any projected type, even from MUX.
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
The text was updated successfully, but these errors were encountered:
@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.
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.
Describe the bug
C#/WinRT code generated by providing a CsWinRTIncludes and CsWinRTWindowsMetadata makes it impossible to set an assembly level SupportedOSPlatformAttribute.
To Reproduce
[assembly: global::System.Runtime.Versioning.SupportedOSPlatform("Windows")]
<SupportedOSPlatformVersion>10.0.17763</SupportedOSPlatformVersion>
. This will generate another[assembly: System.Runtime.Versioning.SupportedOSPlatformAttribute("Windows10.0.17763.0")]
, which conflicts with the first.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
The text was updated successfully, but these errors were encountered: