Dev Analyzer Rule to ensure there are no public types in the Lucene.Net.Support namespace

[NightOwl888]

Is there an existing issue for this?

• I have searched the existing issues

Task description

While we probably will have a Support folder in the repository for some time going forward, it is important to enforce the fact that we won't have a public Lucene.Net.Support namespace. This is easier to enforce using a Roslyn code analyzer than trying to keep track of during reviews because we can easily miss it.

The developer should get a build failure if they add a public type to the Lucene.Net.Support namespace or any namespace below that namespace. They should be instructed:

• If the type is not intended for users, make it internal
• If the type is intended for users:
  • If it is an adaption of something available in the JDK, consider submitting it to J2N
  • If it is more specialized, move it to an appropriate namespace below Lucene.Net, such as Lucene.Net.Util

The latter two options can be discussed either on the dev mailing list or on Slack to help make the right choice.

Side Note: I noticed that the Lucene.Net.Support.IO.WindowsFsyncSupport type is public and made it into the 4.8.0-beta00017 release. This would make a good test case for the analyzer.

[paulirwin]

The dev analyzer has been merged. Once we do the next release to NuGet for the dev analyzers, this can be ran against lucenenet and any issues discovered from that can be addressed.