Windowscommunitytoolkit: Add Platform specific analyzer to DeveloperTools

[hermitdave]

https://github.com/ljw1004/platform-specific-analyzer?files=1 was started as a personal project for showing platform specific differences say between 10240 and 10586.

Dotnet framework has similar done by @terrajobst https://github.com/dotnet/platform-compat/tree/master/src/Terrajobst.PlatformCompat.Analyzers.Tests

I think we should either create a new lib that supports this or add this to dev tools

Thoughts ?

[Odonno]

@hermitdave At least, we should use it to detect errors in our codebase.

[hermitdave]

the future path is being looked at, hopefully we will find out whether its part of dotnet or something independent

[IbraheemOsama]

If it is something simple or small why not we can add it to a separate project inside the toolkit but if its a bit of work and requires maintenance with every Windows Update IMHO it shouldn't be part of the toolkit.

[hermitdave]

Makes some sense

[nmetulev]

Seems like a great addition, I'm all for it. From the project linked, it doesn't look like this would work as part of an existing lib though, it will probably need to be separate.

@hermitdave, are you already working on this?

[hermitdave]

@nmetulev discussing whether dotnet / sdk team has any plans. If we add this, should this be a distinct lib or an associated repo ?

[nmetulev]

I had a quick thread with @unniravindranathan and it doesn't look like there are any plans and he is supportive of the idea.

IMO, it fits well in this repo as a separate lib

[martinsuchan]

I've spent last week digging into this problem so here's a short summary:

• Original Platform Specific Analyzer (PSA) was created as a personal project by Lucian Wischik, who's working in Facebook now. It was often mentioned as a must-have tool on MSDN blog posts and in Build/Channel9 sessions, and I agree that having this functionality in UWP project is really helpful.
• It supports currently only notificaiton of new API from Windows 10 10586 vs 10240 and notification of device-specifc API for Mobile/Desktop/etc.
• It's written in Visual Basic .NET and uses hardcoded list of new classes, properties and methods in Windows 10 10586. This solution of hardcoded types really does not scale well, cannot add easily support for Anniversary Update, Creators Update and Fall Creators Update SDK.

In my opinion PSA, as an extremely useful analyzer, deserves new life as a part of UWP Community Toolkit library. It should be (re)written in C# for easier maintentenance and most importantly it requires different architecture. Hardcoded list of new types in SDKs feels just wrong.
Ideally someone from Microsoft AppModel team should give us guidance how to detect in VS analyzer properly platform-specific APIs, and based on that knowledge new PSA could be created.

Alternative approach could be having this functionality directly in Visual Studio 2017 but that would require work from the Microsoft UWP or VS team and I'm not sure that's feasible right now.

[hermitdave]

Could we dynamically load assemblies and query the containing classes using Reflection?

[nmetulev]

This still seems like a great addition to the toolkit, has there been any progress?

[hermitdave]

The issue here is that there is no way to query for classes and it's members from within the framework.

This means that we will have to provide a hardcoded list with each version. This isn't scalable. We need some input from SDK team here.

[bartlannoeye]

Can't you use the contract's XML files (under program files) to work out diffs? I'm not on a Win10 device right now, so don't know how detailed the contract files are.

[hermitdave]

I'll take a look if i can manage tonight. On holiday so it's a bit hectic right now

[nmetulev]

@bartlannoeye, that's a great idea. I did a quick search in the Program Files (x86)\WindowsKits\10 folder where each SDK is stored, and found the XMLs in the References[SDK build num]\Windows.Foundation.UniversalApiContract[contract number]\en folders.

[bartlannoeye]

Those are the files I meant.

[martinsuchan]

Those are promising files, even though only the UniversalApiContract XML file for Windows 10.0.16299.0 is 10MB large XML file.
The question is - are those doc files complete and reliable with perfect 1:1 mapping to actual types in Windows 10.0.16299.0?

It might be still worth a shot creating proof of concept analyzer that checks attributes of UWP types directly, like in this case:

WebView implements five incremental interfaces already, each of them added in newer version of Windows 10. If it's possible to check these attributes inside the Analyzer, it might be enough to determine if given type, property or method is available for target MinVersion or TargetVersion or not at all.

[nmetulev]

I agree, it's worth a shot. Looks like each version is just a multiple of 65536.

[martinsuchan]

All this ticket needs is some kind of working proof-of-concept, how the checks for sdk-specific apis in the analyzer. Once this proof-of-concept is validated as a viable way, it could be pretty straightforward implementing the rest of the analyzer...

[nmetulev]

Agree. @hermitdave, do you think you will be able to work on this for 2.2?

[hermitdave]

Let me get started @nmetulev

[hermitdave]

Okay so i have managed to iterate through winmd files and generate basic dataset for all runtime assemblies for all the public SDKs. Next set will be to generate version diffs which shouldn't be that difficult.

Here is a sample set that has an update in each of the 5 versions of SDK
Its a zip containing json.

Windows.Devices.SmartCards.SmartCardEmulatorContract.zip

@martinsuchan is this enough info for the diff requirement ?

[tibitoth]

The attribute way is more likeable for me rather than generating diffs and store in the analyzer's package.

[hermitdave]

@totht91 i played no part in original analyser and I'm still trying to work out what is possible from code point of view. Right now trying to identity if min and target version of app in question are accessible or not.

If they aren't, we aren't going anywhere. If you have an idea please do not hesitate. PoC would help

[hermitdave]

Another option might be to just consider supported SDK version.. not previous, not future.
The toolkit supports 14393 through to 16299. Any toolkit analyser could assume that are a target subset and perform analysis / provide hints to ensure that ApiInformation methods are used when differences are observed.

[windowstoolkitbot]

This issue seems inactive. Do you need help to complete this issue?

[windowstoolkitbot]

This issue seems inactive. Do you need help to complete this issue?

[nmetulev]

Moving this to 3.0 for now

[touseefbsb]

looks something I requested to template studio team a while ago. but they arent interested in implementing this atleast not in near future. but yeah it can be part of the toolkit as well. and will reduce a lot of friction for adaptive code to run on all devices and all SDKs .

[hermitdave]

folks so I am going back to the original idea however I am thinking of creating different sets
I am creating a type list to find out the new types added.

Other lists would be
Type Methods
Type Properties
Type Events

This way we could generate diffs and identify which ones would / should be decorated with ApiInformation declaration.

My concern however is still the following:
We will start wth Api Contract 4.0.0.0 since 14393 will now move out of support and 15063 will become with min supported version for toolkit.

With Toolkit 3.0 we dont know if we will have final SDK for whatever version of Windows 10 comes out next.

[hermitdave]

so to start with do we just support differences from 4.0 to 5.0 ?

[nmetulev]

I think so. As soon as 6 is officially released we should add it. Is that process going to be automated (generating the diff)?

[hermitdave]

@nmetulev nope I don't think so.. Maybe someone better than myself (just about everyone) could take a look at automating it

Right now I'm just using a. Net 4.5 command line app

[martinsuchan]

I still think that this feature should be natively part of Visual Studio or the UWP SDK. It's an essential feature for developers.

[hermitdave]

@martinsuchan whilst there is an agreement on that idea I do not think there's sufficient appetite.

I think this would make a nice extension too

[nmetulev]

@hermitdave, command line is a great start IMO :)

[hermitdave]

@nmetulev this is the type differences file between 4 and 5.. I think we can make this work. Next let me do the method, property and event differences.

UniversalApiContract-Differences.json.txt

[hermitdave]

This is based on WinMD exported types and not the xml documentation.

[touseefbsb]

@hermitdave you can start with creators update and above only bcz as u said anniversary update will go out of support for the toolkit and also moving forward, it will make more sense to support future SDKs as majority of windows 10 machines are already on creators update and above and will keep updating to newer versions.

[hermitdave]

@touseefbsb agreed.. we start with Creators update and with each release generate diffs between min and target SDK

[touseefbsb]

@hermitdave and during the development of the project, if the developer changes the target version or min version, the diffs should sync with that accordingly right? and if they choose any target below creators update, a warning can be displayed that this extension wont work properly unless min version is creators or above.

[hermitdave]

@touseefbsb sadly not.. This is values for toolkit not the project. If we go the extension route we can check if we can check user projector file

[touseefbsb]

cant we make a visual studio extension for this or a nuget package? a way to be more flexible where it can also watch the project file as well? in that case it will be more powerful and more fluent developer experience :)

[hermitdave]

@touseefbsb the existing platform analyser is a nuget package. We start with that and then see what else can be done. VS extension might be the best way forward

[touseefbsb]

@hermitdave in the latest preview of vs 2017 15.7 I saw that they have analyzers for this scenario in the xaml files ( with conditional xaml ) , so we do know that xaml files are safe, but we still do need analyzer for c# files. I am not sure whether they will be adding that to c# as well in upcoming previews, and yeah a vs extension seems a better way to achieve this in the long run.

[hermitdave]

https://github.com/Microsoft/UWPCommunityToolkit/issues/1497#comment-331003730

There is no plan as far as we know for one from VS team

[touseefbsb]

@hermitdave this issue is being tracked I guess on this uservoice https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/19105051-add-support-for-uwp-api-version-check-warning
go ahead and vote, maybe this can come to VS sooner than we think

[windowstoolkitbot]

This issue seems inactive. Do you need help to complete this issue?

[nmetulev]

@hermitdave, are you still working on this?

[hermitdave]

Yes I am.. converting original VB code to CS unless you want to keep it as is

[nmetulev]

Awesome. Yeah, we should have it CS for consistency

[hermitdave]

I truly looked at the code only today.. its 60% done.. going to finish it tonight and then take another stab at different Gen. Will consume the existing hard coded format. Will push it to repo soon

[hermitdave]

This is still work in progress.. I have added C# analyzer though haven't tested a thing yet on analyzer front.

[hermitdave]

The Platform specific analyzer and code fixer with support for both nuget and VSIX is now in PR. It supports both C# and Visual Basic.

[touseefbsb]

the bot itself adding the pr in progress tag is a bit creepy :D but after seeing the AI in Microsoft build and googl io, 18. this just looks normal :P

[Odonno]

@touseefbsb Well, I can assure you this bot is far from being smart compared to what you saw at Build/Google IO. :)

[hermitdave]

@touseefbsb @Odonno this is more of a script rather than a Bot

[touseefbsb]

@Odonno totally agreed, specially when google assistant was calling resturant to book the reservation, that was the most creepy thing I've ever seen in technology, I am also one of "AI will take us over" people :D

[hermitdave]

Not just you 😂 most of us wear a tin foil hat