[release/7.0.1xx] SealInternalTypes (CA1852): Don't warn for top-level type (#6278)

[jhartmann123]

Backport #6278 into the .NET7 release branch
Issue: #6141 - CA1852 warns on generated Program for top-level statements

Customer Impact

The CA1852 analyzer is hidden by default, but it is bulk configurable. Which means it is will be on if user choose to warn on all analyzers or on Performance category analyzers. Several customers asked about the porting in the issue #6141. For the customer who opened this PR they have all analyzers enabled with TreatWarningsAsErrors set to true in their project. So, they explicitly have to suppress this analyzer in order to compile. There is no workaround except suppressing the warning or upgrading to .NET 8 previews which is not desirable. Accounting that top level statements are getting more and more popular the fix better to be serviced in 7.0.

Regression

No, but if we account that the analyzer newly added in 7.0 with the bug it could cause an unexpected warning when the analyzers bulk configured to Warn

Testing

• Unit test added with the fix
• Manual testing done with the repro

Risk

Very low, the fix is quite simple and self-descriptive. It would not introduce a new warning nor would affect any other code/analyzer.

CC @jeffhandley @stephentoub

[mavasani]

@buyaa-n

[buyaa-n]

@jhartmann123 personally I am supportive to port, but for porting fixes into SDK servicing releases we need to get approval from management. I will update the description with the info needed for servicing request, we need more info from you to fill the Customer impact part of the request. Why do you think the fix need to be ported and why the porting is necessary for you, are you blocked by this bug and how? Especially when the analyzer is hidden by default the customer scenario would be helpful

[jhartmann123]

I'm sorry, while not stated explicitly anywhere, some people, including me, were under the impression that this was planned to be fixed with SDK 7.0.1xx. As it still wasn't fixed with 7.0.200, I thought that this was just a missed cherry pick...

Thanks for updating the MR description, I've added our issue with this in the Customer impact part.

[jeffhandley]

Backporting this to 7.0.x sounds good to me. It addresses a common scenario of top-level statements where a bug exists and cannot be satisfactorily worked around.

@buyaa-n Can you shepherd this through Tactics please?

[buyaa-n]

Servicing approved, the code coverage failure is unrelated, merging. Assuming it would just flow from 7.0.1xx branch to next 7.0 release as usual.

CC @jmarolf @mavasani

[buyaa-n]

Hm, could not merge, probably because of the failure? Rerunning did not work, closing and reopening the PR