ljw1004
commented
8 years ago @nelsonghezzi @sohra - thanks for the bug report.
The issue is that things you describe - Thickness, Auto - aren't actually taken by the compiler or .NET runtime from the Windows SDK. Instead the types are "projected" by the runtime so it's as if they're really types from a collection of System.Runtime.* assemblies that get automatically added to all WinRT projects as a bunch of NuGet references. Therefore they are always present and there's no need to warn about them.
I've made the fix for this issue, and will push out a new version of the NuGet in a day or two.
Thanks again for taking the time to report!
[porting from https://github.com/ljw1004/blog/issues/1 @nelsonghezzi]
Hi,
Using the latest pre release version (2.0.0), I've found that it warns about classes in the Windows.UI.Xaml namespace, like Thickness, as being Platform-specific code.
But these classes are declared in the Windows.Foundation.UniversalApiContract.
It's that ok?
Regards.
@sohra responded:
I noticed using 2.0.2, that Windows.UI.Xaml.GridLength.Auto was marked as platform-specific. The suggested fix was to wrap in a call to IsTypePresent, which was pointless since when I investigated, GridLength is in the UniversalApiContract. This would always return true.
However, the type in the UniversalApiContract (both versions 1 and 2) contains just two of the members listed on MSDN, all the other members are defined in System.Runtime.WindowsRuntime.UI.Xaml, Version=4.0.0.0.
So the fix suggested by the analyzer is incorrect, it should have been something like:
...assuming that works with static properties (I haven't tested).