Roslyn-analyzers: Platform compat analyzer: should be disabled when compiling for .NET Framework

[terrajobst]

We can't mark .NET Framework projects as Windows-specific (because the attribute doesn’t ship with .NET Framework). Which means if you set <AnalysisLevel> to 5, all Windows-specific APIs are now flagged. This is usually not a big thing, because most APIs are in-box and in-box APIs aren’t marked. But if someone consumes a NuGet package with internal attributes, they could get false positives.

The customer can work this around by either disabling the rule or by applying the attribute to their assembly, but this would also require them to define it themselves.

We should disable the analyzer if the TFM is < net5.0.

[jeffhandley]

We would still allow the analyzer to be forced to enabled for TFM < net5.0 though, respecting any attributes they apply to their own APIs.

[jeffhandley]

Per @mavasani:

Note that the analyzer can read the underlying MSBuild TFM through analyzer options. So, if we wanted different default behavior based on it, it would be possible. For example, we can add a new boolean editorconfig option for this analyzer, say enabled_on_net_framework, which can be defaulted to false, and user would need an additional step 4. to set this option to true in their editorconfig to enable this analyzer on .NET Framework.

[buyaa-n]

Questions around TFM edge cases:

• What if there is no TFM specified? Could I assume we should disable the analzyer to avoid false positives?
• What if multiple TFMs provided (separated by ;). Could i assume analyzer should be enabled if at least one of them is net5.0 or above?

CC @terrajobst @jeffhandley

[mavasani]

What if multiple TFMs provided (separated by ;). Could i assume analyzer should be enabled if at least one of them is net5.0 or above?

Each compilation should only have a single TFM, even if project file has multiple TFMs. I am not suggesting we should run the analyzer if subset of TFMs are supported and subset are not supported, Immo/Jeff should make a call on that.

[mavasani]

Actually, I am not sure if analyzer will have access to TargetFrameworks property, as each compilation is done using individual TargetFramework from the list of frameworks in that property. You may have to try it out...

[buyaa-n]

Actually, I am not sure if analyzer will have access to TargetFrameworks property, as each compilation is done using individual TargetFramework from the list of frameworks in that property.

That makes sense, most likely that is true

You may have to try it out...

Guess only option is manual testing, will give it try

[terrajobst]

• What if there is no TFM specified? Could I assume we should disable the analzyer to avoid false positives?

What @mavasani said. Not having a TFM would be a major issue. I don't think we want to crash in this case, but I personally don't care whether the analyzer is enabled or disabled in that case.

• What if multiple TFMs provided (separated by ;). Could i assume analyzer should be enabled if at least one of them is net5.0 or above?

What @mavasani said. Should never happen.