我认为，如果您想让子类能够设置或重写父构造函数将立即使用的属性，则忽略警告可能是合法的：

internal class Parent
{
    public Parent()
    {
        Console.WriteLine("Parent ctor");
        Console.WriteLine(Something);
    }

    protected virtual string Something { get; } = "Parent";
}

internal class Child : Parent
{
    public Child()
    {
        Console.WriteLine("Child ctor");
        Console.WriteLine(Something);
    }

    protected override string Something { get; } = "Child";
}

这里的风险是子类从其构造函数设置属性，在这种情况下，值的更改将在调用基类构造函数之后发生。

我的用例是，我希望子类提供一个特定的值或一个实用程序类（如转换器），而不需要在基础上调用初始化方法。

在实例化子类时，上面的输出是：

Parent ctor
Child
Child ctor
Child

对于你为什么不想这样做，上面有很好的答案。这里有一个反例，也许你想这样做（由Sandi Metz翻译成C#，来自Ruby中的实用面向对象设计，第126页）。

注意，GetDependency（）没有触及任何实例变量。如果静态方法可以是虚拟的，那么它将是静态的。

（公平地说，可能有更聪明的方法通过依赖注入容器或对象初始化器来实现这一点…）

public class MyClass
{
    private IDependency _myDependency;

    public MyClass(IDependency someValue = null)
    {
        _myDependency = someValue ?? GetDependency();
    }

    // If this were static, it could not be overridden
    // as static methods cannot be virtual in C#.
    protected virtual IDependency GetDependency() 
    {
        return new SomeDependency();
    }
}

public class MySubClass : MyClass
{
    protected override IDependency GetDependency()
    {
        return new SomeOtherDependency();
    }
}

public interface IDependency  { }
public class SomeDependency : IDependency { }
public class SomeOtherDependency : IDependency { }

警告的原因已经描述过了，但您将如何修复警告？您必须密封类或虚拟成员。

  class B
  {
    protected virtual void Foo() { }
  }

  class A : B
  {
    public A()
    {
      Foo(); // warning here
    }
  }

您可以密封A类：

  sealed class A : B
  {
    public A()
    {
      Foo(); // no warning
    }
  }

或者您可以密封方法Foo：

  class A : B
  {
    public A()
    {
      Foo(); // no warning
    }

    protected sealed override void Foo()
    {
      base.Foo();
    }
  }

我发现的另一件有趣的事情是，通过执行下面这样的操作可以“满足”ReSharper错误，这对我来说是愚蠢的。然而，正如许多前面提到的，在构造函数中调用虚拟财产/方法仍然不是一个好主意。

public class ConfigManager
{
   public virtual int MyPropOne { get; private set; }
   public virtual string MyPropTwo { get; private set; }

   public ConfigManager()
   {
    Setup();
   }

   private void Setup()
   {
    MyPropOne = 1;
    MyPropTwo = "test";
   }
}

因为在构造函数完成执行之前，对象不会完全实例化。虚拟函数引用的任何成员都不能初始化。在C++中，当您处于构造函数中时，这仅指所处构造函数的静态类型，而不是所创建对象的实际动态类型。这意味着虚拟函数调用甚至可能不会到达您期望的位置。

C#的规则与Java和C++的规则非常不同。

当您在C#中的某个对象的构造函数中时，该对象以完全初始化（只是不是“构造”）的形式存在，作为其完全派生类型。

namespace Demo
{
    class A 
    {
      public A()
      {
        System.Console.WriteLine("This is a {0},", this.GetType());
      }
    }

    class B : A
    {      
    }

    // . . .

    B b = new B(); // Output: "This is a Demo.B"
}

这意味着，如果从a的构造函数调用虚拟函数，它将解析为B中的任何重写（如果提供了重写）。

即使你有意这样设置A和B，充分理解系统的行为，你也可能会在以后受到冲击。假设您在B的构造函数中调用了虚拟函数，“知道”它们将由B或A酌情处理。然后时间过去了，其他人决定他们需要定义C，并重写其中的一些虚拟函数。突然间，B的构造函数最终调用了C中的代码，这可能会导致非常令人惊讶的行为。

无论如何，避免构造函数中的虚函数可能是一个好主意，因为C#、C++和Java之间的规则是如此不同。你的程序员可能不知道该怎么做！