We recommend using Visual Studio 2017

Non-constant fields should not be visible







Breaking Change


A public or protected static field is not constant nor is it read-only.

Static fields that are neither constants nor read-only are not thread-safe. Access to such a field must be carefully controlled and requires advanced programming techniques for synchronizing access to the class object. Because these are difficult skills to learn and master, and testing such an object poses its own challenges, static fields are best used to store data that does not change. This rule applies to libraries; applications should not expose any fields.

To fix a violation of this rule, make the static field constant or read-only. If this is not possible, redesign the type to use an alternative mechanism such as a thread-safe property that manages thread-safe access to the underlying field. Realize that issues such as lock contention and deadlocks might affect the performance and behavior of the library.

It is safe to exclude a warning from this rule if you are developing an application and therefore have full control over access to the type that contains the static field. Library designers should not exclude a warning from this rule; using non-constant static fields can make using the library difficult for developers to use correctly.

The following example shows a type that violates this rule.

using System;

namespace UsageLibrary
   public class SomeStaticFields
      // Violates rule: AvoidNonConstantStatic;
      // the field is public and not a literal.
      static public DateTime publicField = DateTime.Now;

      // Satisfies rule: AvoidNonConstantStatic.
      public static readonly DateTime literalField = DateTime.Now;

      // Satisfies rule: NonConstantFieldsShouldNotBeVisible;
      // the field is private.
      static DateTime privateField = DateTime.Now;