您的构造函数（稍后，在软件的扩展中）可以从重写虚拟方法的子类的构造函数调用。现在不是子类的函数实现，而是基类的实现将被调用。所以在这里调用虚拟函数是没有意义的。

然而，如果您的设计满足Liskov替换原则，则不会造成任何伤害。也许这就是为什么它被容忍的原因——一个警告，而不是错误。

我发现的另一件有趣的事情是，通过执行下面这样的操作可以“满足”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#中，基类构造函数在派生类构造函数之前运行，因此派生类可能在可能重写的虚拟成员中使用的任何实例字段都尚未初始化。

请注意，这只是一个警告，让你注意并确保一切正常。这个场景有实际的用例，您只需要记录虚拟成员的行为，它不能使用下面的派生类中声明的任何实例字段，构造函数调用它。

该警告提醒您虚拟成员很可能在派生类上被重写。在这种情况下，父类对虚拟成员所做的任何操作都将通过重写子类来撤消或更改。看一下这个小例子

下面的父类试图将值设置为其构造函数上的虚拟成员。这将触发Re sharper警告，请参见代码：

public class Parent
{
    public virtual object Obj{get;set;}
    public Parent()
    {
        // Re-sharper warning: this is open to change from 
        // inheriting class overriding virtual member
        this.Obj = new Object();
    }
}

此处的子类重写父属性。如果此属性未标记为virtual，编译器将警告该属性隐藏父类上的属性，如果有意，建议您添加“new”关键字。

public class Child: Parent
{
    public Child():base()
    {
        this.Obj = "Something";
    }
    public override object Obj{get;set;}
}

最后是对使用的影响，下面示例的输出放弃了父类构造函数设置的初始值。这就是Re sharper试图警告您的，在父类构造函数上设置的值将被子类构造函数覆盖，子类构造函数在父类构造器之后立即调用。

public class Program
{
    public static void Main()
    {
        var child = new Child();
        // anything that is done on parent virtual member is destroyed
        Console.WriteLine(child.Obj);
        // Output: "Something"
    }
} 

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之间的规则是如此不同。你的程序员可能不知道该怎么做！

当用C#编写的对象被构造时，会发生的情况是初始化器按照从最派生类到基类的顺序运行，然后构造函数按照从基类到最派生类的顺序运行（有关为什么这样做的详细信息，请参阅Eric Lippert的博客）。

此外，在.NET对象中，对象在构造时不会改变类型，而是从最派生的类型开始，方法表是最派生的。这意味着虚拟方法调用总是在最派生的类型上运行。

当你结合这两个事实时，你会遇到这样的问题：如果你在构造函数中调用了一个虚拟方法，并且它不是继承层次结构中最派生的类型，那么它将在一个尚未运行构造函数的类上被调用，因此可能不处于调用该方法的合适状态。

当然，如果您将类标记为密封的，以确保它是继承层次结构中最派生的类型，那么这个问题就会得到缓解——在这种情况下，调用虚拟方法是完全安全的。