Runtime: 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 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

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
  
  
• [ ] 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
  
  
• [ ] Implement linker changes to recognize the new attribute
  
  
  
  • [ ] Implicit suppression on annotated methods
  
  
  • [ ] Support it via attribute.xml
  
  
  • [ ] Validate that warning suppression mechanisms work on it
  
  
• [ ] Consider intrinsic support for single-file APIs – currently the Roslyn analyzer works like this, we should either change both to only work on the attribute or both to have some support for intrinsic – based on the UX we can deliver with each.
• [ ] 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 the linker or Roslyn (or both) 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
  
  
• [ ] Add an SDK E2E test to baseline single-file warnings from console app (that is no warnings)
• [ ] ?? Run the analysis on higher-level frameworks – ASP.NET, WinForms, WPF and file issues as appropriate

[msftbot[bot]]

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.

https://github.com/mono/linker/issues/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.

[danmosemsft]

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

[agocke]

Probably a question for @samsp-msft

[danmosemsft]

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.

[danmosemsft]

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