document what to do in case of multiple target frameworks

[dawedawe]

This is very likely not the end of this story but should help people overcome one of the first obstacles the might face.

[baronfel]

We should make the analysis task multi-targeting aware to help prevent this.

Essentially, if the task is called with TargetFrameworks nonempty, then the task should be called again with each separate TFM and the outputs collected together in some way. I'll send a PR with an example and we can work through the specifics

[baronfel]

Also we should consider shipping a nuget package that includes the recommended MSBuild target (AnalyzeProject, etc) so that users don't have to hand-roll this. That wouldn't work for solution-level targets, sadly.

[nojaf]

Also we should consider shipping a nuget package that includes the recommended MSBuild target (AnalyzeProject, etc) so that users don't have to hand-roll this. That wouldn't work for solution-level targets, sadly.

Yes, please! Is that a difficult thing to do? Something similar to KeepAChangelog?

[baronfel]

It would actually be simpler than KeepAChangelog since the package we're talking about here wouldn't have any DLLs - the short version is you would make a package (let's call it FSharp.Analyzers.Build) with the following layout:

<root>
- build
- - FSharp.Analyzers.Build.targets
- buildMultitargeting
- - FSharp.Analyzers.Build.targets

and in the build targets you'd just put the logic for a single-TFM run of the analyzers (since the build logic in NuGet packages is guaranteed by the .NET SDK to only run for a single TFM). then, in the buildMultitargeting targets you'd have the 'new' target that knows how to handle invoking analysis for each TFM specified (since the buildMultitargeting logic in NuGet packages is guaranteed by the .NET SDK to only run in the 'outer', multi-TFM context).

[dawedawe]

Not needed anymore because we have #139