PlatformSpecific.Analayzer - to spot when you're using platform-specific UWP APIs
With the release of 10586, I’ve wanted to know whether an API I just used was newly introduced in 10586 or was already present back in 10240.
So what I did is write a “Roslyn Analyzer” for VB/C# and put it on NuGet. It detects whether an API I’ve used is platform-specific or version-specific. If so then it puts in a warning squiggle and gives you a quickfix (unless you've already put an ApiInformation.IsTypePresent check, or similar)
I’d love for folks to try this out and see if you find it helpful!
- To use, add a NuGet reference to PlatformSpecific.Analyzer from your VB/C# UWP project to this NuGet package (2k+ downloads so far)
- Documentation and source code here on GitHub.
- Short 3-minute training video
- More focused on the version-specific aspects, another short video
- Mike Taulty wrote a blogpost about it
- What's new in 10586 UWP? I typed up the "diff" in this file.
What I’d like to learn is this:
- Overall, does the analyzer add value, not just for your simplistic examples, but also for your advanced/large projects?
- The analyzer has its convention for “transitivity” where you can mark an entire method or field as platform-specific. If you use this, does it work out okay?
- This kind of analysis can never be perfect, so it falls back on loosey-goosey heuristics. Are they too loosey-goosey? Do you find places where you’d expected a warning but it produced none? Do you find places where it produced an erroneous warning?
If people really find it useful, then I’ll push for it to be included by default in the File>New>UWP project template. But that’s a big unprecedented step so I’m cautious.
Here are some of the new 10586 APIs you could test it on! …
Comments
- Anonymous
December 02, 2015
Using the build number as target version is really a terrible idea.