I am wondering if we should add ExportCodeFixProviderAttribute and DiagnosticAnalyzerAttribute to Banned APIs in Features layer, with a recommendation message in the diagnostic to move the analyzer/fixer down to the shared layer, when possible. For cases where this is not possible due to analyzer/fixer using a public API not available in a shipped Roslyn version, one would be expected to add a source suppression, with a reference to a tracking issue to perform the move later when the public API does become available (similar to the issue closed by this PR).

What do you thing @Youssef1313?

Btw, I don't recall whether or not the BannedApiAnalyzer flags banned attribute constructors :-)

@mavasani There are too many codefixes there (in Features) anyway. Banning the attribute (if possible) and suppressing all of the warnings is going to be noisy. I may look into moving more codefixes later. Then fix BannedApiAnalyzer if needed and use it.

Debug.Assert isn't annotated for netstandard2.0. Used RoslynDebug instead of null-suppression with !.

how does this work in vs @mavasani ? do we pick up the CodeStyle fixer? Or do we pick up the one from Features?

We prefer the fixer and analyzer from NuGet package over the one from VSIX

Btw is there a specific reason for marking this as low priority?

@mavasani From related discussion in #43596, it seems this was a copy from another feature

I think if overriding Priority is something important the API may be considered to be exposed publicly

cc @alrz