Aligns the naming conventions defined in editorconfig (dotnet_naming_style, dotnet_naming_symbols, dotnet_naming_rule) which are reported under the IDE1006 rule with the existing StyleCop rules from the SA13XX range.
This ensures the two rulesets agree when rejecting and accepting naming conventions within the IDE, with a few edges cases where only one ruleset can enforce the convention. IDE1006 allows use to specify a naming convention for type parameters, const locals and protected readonly fields which SA13XX cannot enforce. Some StyleCop SA13XX rules such as SA1309 'Field names should not begin with underscore' are not possible to enforce with the naming rules of IDE1006.
Therefore we enable the IDE1006 as a build time warning to enforce conventions and extend them. We disable SA13XX rules that can now be covered by IDE1006 to avoid double-reporting but leave the remaining SA13XX rules that cover additional cases enabled.
We also re-enable the SA1311 rule convention but enforce it via IDE1006, requiring some violations to be fixed or duplication of existing suppressions. Most violations fixes are trivial renames with the following exception. In ActorInitializer.cs, we prefer to make the fields private instead. ValueActorInit provides a publicly accessible property for access and OwnerInit provides a publicly accessible method. Health.cs is adjusted to access the property base instead when overriding. The reflection calls must be adjusted to target the base class specifically, as searching for a private field from the derived class will fail to locate it on the base class.
Unused suppressions were removed.
Also added a rule to silence StyleCop complaining about StaticReadonlyFieldsMustBeginWithUpperCaseLetter to match what we already have configured for the IDE.
Unfortunately due to bugs in the analyzers or something else, the IDE0005 doesn't work as expected. The "officially suggested" workaround is to enable XML documentation generation to trigger IDE0005 during compiling. Then we need to add three more rules to silence the warnings that come from the XML documentation generation. We also need to enable code style enforcing on build for all of this to work.
Known issue is that all of this produces a bunch (tens to hundreds) of obscure analyzer warnings on older versions of Visual Studio, but those seem to not be causing issues.
