Improvements to single-file analysis

[agocke]

The existing single-file analyzer covers the top issues customers will likely hit with single-file, but it has some shortcomings.

Goals

• Single-file analyzer is moved next to the trimming analyzer in the mono/linker repo
• Single-file analyzer is enabled in the dotnet/runtime repo to identify problems in the framework
• Users can annotate their own APIs as being not compatible with single-file

Work

• Add an attribute similar to RequiresUnreferencedCode (code, ref assemblies)
• Annotate low-level APIs with the attribute - One more run over all "dangerous" APIs
  • Make sure that the attributes show up in ref assemblies.
  • Validate that the ref assembly validator in dotnet/runtime enforces inclusion of this attribute (we had issues with this for RequiresUnreferencedCode)
• At least plan on adding a docs page on the topic with some thoughts/guides on how to “fix” – ideally link to this from the attributes (see https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file#api-incompatibility)
• Synchronize with mono/Xamarin to annotate low level APIs which are problematic because of mono/Xamarin single-bundle publishing (mono itself can do a single-file bundle similar to CoreCLR's single-file, but Xamarin has other single-file like bundles for devices - Android, iOS).
• Improve existing Roslyn analyzer
  • Move the analyzer next to the trimming analyzer in the mono/linker repo
  • Support for the new attribute
    • Implicit suppression on annotated methods
• Integrate the analyzers with SDK - probably conditioned on PublishSingleFile property - warnings on-by-default??? (they already are for user code, what about whole-program analysis done by linker)
• Enable Roslyn analyzer on dotnet/runtime repo (similar to TrimAnalysis) - probably add baselines as well (not sure how to do baselines for Roslyn analyzer - .cs file with SuppressMessage attributes which will be removed by compilation?)
• Go over reported warnings from within the framework in dotnet/runtime and “do something about them” (suppress, propagate to public API via attributes)
  • Ideally also look through other features which might be affected by single-file and annotate
• ?? Run the analysis on higher-level frameworks – ASP.NET, WinForms, WPF and file issues as appropriate

[ghost]

Tagging subscribers to this area: @agocke, @vitek-karas
See info in area-owners.md if you want to be subscribed.

---

Issue meta data

Issue content:	The existing single-file analyzer covers the top issues customers will likely hit with single-file, but it has some shortcomings. Goals Single-file problems are detected using linker whole-program analysis Single-file analyzer is moved next to the trimming analyzer in the mono/linker repo Single-file analyzer is enabled in the dotnet/runtime repo to identify problems in the framework Users can annotate their own APIs as being not compatible with single-file
Issue author:	agocke
Assignees:	-
Milestone:	-

[vitek-karas]

As part of the "Users can annotated their own APIs" we will introduce an attribute similar to RequiresUnreferencedCode and it will need almost identical treatment by the linker.

dotnet/linker#1607 will probably force us to move analysis around RequiresUnreferencedCode into a different place in the linker - so we might as well make it an extensibility point (of sorts) and then implement both there.

[danmoseley]

Should something like this be parented under a single file user story?

[agocke]

Probably a question for @samsp-msft

[danmoseley]

I think we're all just figuring out what is useful to us, hence the question. I'm going to be bold and make it a user story under the single file epic. I think in general 'significant work items' make sense to have in the tree. It's certainly helpful to me to see all the major work. Feel free to change.

[danmoseley]

Making story so it appears in the tree -- but now I see you have removed it @marek-safar ?

[agocke]

Update: cutting whole-program analysis of single-file for 6.0. Telemetry shows that most users are not using linking in conjunction with PublishSingleFile, so adding single-file analysis in the linker could produce several downsides, including slowing down publish significantly.

As a longer-term plan, adding the analysis to either a separate tool or inside crossgen is likely a better path here.