以下可能是我缺乏的常识，但是，嗯。前段时间，我们遇到了一个包含虚拟财产的bug案例。将上下文抽象一点，考虑以下代码，并将断点应用到指定区域:

class Program
{
    static void Main(string[] args)
    {
        Derived d = new Derived();
        d.Property = "AWESOME";
    }
}

class Base
{
    string _baseProp;
    public virtual string Property 
    { 
        get 
        {
            return "BASE_" + _baseProp;
        }
        set
        {
            _baseProp = value;
            //do work with the base property which might 
            //not be exposed to derived types
            //here
            Console.Out.WriteLine("_baseProp is BASE_" + value.ToString());
        }
    }
}

class Derived : Base
{
    string _prop;
    public override string Property 
    {
        get { return _prop; }
        set 
        { 
            _prop = value; 
            base.Property = value;
        } //<- put a breakpoint here then mouse over BaseProperty, 
          //   and then mouse over the base.Property call inside it.
    }

    public string BaseProperty { get { return base.Property; } private set { } }
}

而在Derived对象上下文中，您可以在添加基类时获得相同的行为。属性作为手表，或打字基地。财产成快表。

我花了些时间才意识到发生了什么。最后，我受到了Quickwatch的启发。当进入Quickwatch并探索派生对象d(或从对象的上下文，this)并选择字段基时，Quickwatch顶部的edit字段显示以下类型转换:

((TestProject1.Base)(d))

这意味着如果base被替换，调用会是

public string BaseProperty { get { return ((TestProject1.Base)(d)).Property; } private set { } }

对于watch、Quickwatch和调试鼠标移到工具提示，在考虑多态性时显示“AWESOME”而不是“BASE_AWESOME”是有意义的。我仍然不确定为什么它会转换成一个类型转换，一个假设是，调用可能无法从这些模块的上下文，只有callvirt。

无论如何，这显然不会改变派生功能方面的任何东西。BaseProperty仍然会返回“BASE_AWESOME”，因此这不是我们工作中的bug的根源，只是一个令人困惑的组件。然而，我发现有趣的是，它会误导开发人员，他们在调试过程中不会意识到这一事实，特别是如果Base没有在你的项目中公开，而是作为第三方DLL引用，导致开发人员只是说:

“喂，等等……什么?”omg那个DLL是 , . .做一些有趣的事情”

c#支持数组和列表之间的转换，只要数组不是多维的，并且类型之间有继承关系，并且类型是引用类型

object[] oArray = new string[] { "one", "two", "three" };
string[] sArray = (string[])oArray;

// Also works for IList (and IEnumerable, ICollection)
IList<string> sList = (IList<string>)oArray;
IList<object> oList = new string[] { "one", "two", "three" };

注意，这是无效的:

object[] oArray2 = new int[] { 1, 2, 3 }; // Error: Cannot implicitly convert type 'int[]' to 'object[]'
int[] iArray = (int[])oArray2;            // Error: Cannot convert type 'object[]' to 'int[]'

如果您有一个泛型类，它的方法可以根据类型参数而变得模糊，该怎么办?我最近在写一本双向词典时遇到了这种情况。我想要编写对称的Get()方法，它将返回传递的任何参数的相反值。就像这样:

class TwoWayRelationship<T1, T2>
{
    public T2 Get(T1 key) { /* ... */ }
    public T1 Get(T2 key) { /* ... */ }
}

如果你创建一个实例，其中T1和T2是不同类型的，那么一切都很好:

var r1 = new TwoWayRelationship<int, string>();
r1.Get(1);
r1.Get("a");

但如果T1和T2是相同的(可能如果一个是另一个的子类)，这是一个编译器错误:

var r2 = new TwoWayRelationship<int, int>();
r2.Get(1);  // "The call is ambiguous..."

有趣的是，第二种情况下的所有其他方法仍然可用;只有调用现在模棱两可的方法才会导致编译器错误。有趣的案例，只是有点不太可能和晦涩。

即使枚举函数重载，它们也应该使0为整数。

我知道c#核心团队将0映射到enum的基本原理，但是，它仍然没有像它应该的那样正交。来自Npgsql的例子。

测试的例子:

namespace Craft
{
    enum Symbol { Alpha = 1, Beta = 2, Gamma = 3, Delta = 4 };


   class Mate
    {
        static void Main(string[] args)
        {

            JustTest(Symbol.Alpha); // enum
            JustTest(0); // why enum
            JustTest((int)0); // why still enum

            int i = 0;

            JustTest(Convert.ToInt32(0)); // have to use Convert.ToInt32 to convince the compiler to make the call site use the object version

            JustTest(i); // it's ok from down here and below
            JustTest(1);
            JustTest("string");
            JustTest(Guid.NewGuid());
            JustTest(new DataTable());

            Console.ReadLine();
        }

        static void JustTest(Symbol a)
        {
            Console.WriteLine("Enum");
        }

        static void JustTest(object o)
        {
            Console.WriteLine("Object");
        }
    }
}

我来派对晚了一点，但我有三四五

If you poll InvokeRequired on a control that hasn't been loaded/shown, it will say false - and blow up in your face if you try to change it from another thread (the solution is to reference this.Handle in the creator of the control). Another one which tripped me up is that given an assembly with: enum MyEnum { Red, Blue, } if you calculate MyEnum.Red.ToString() in another assembly, and in between times someone has recompiled your enum to: enum MyEnum { Black, Red, Blue, } at runtime, you will get "Black". I had a shared assembly with some handy constants in. My predecessor had left a load of ugly-looking get-only properties, I thought I'd get rid of the clutter and just use public const. I was more than a little surprised when VS compiled them to their values, and not references. If you implement a new method of an interface from another assembly, but you rebuild referencing the old version of that assembly, you get a TypeLoadException (no implementation of 'NewMethod'), even though you have implemented it (see here). Dictionary<,>: "The order in which the items are returned is undefined". This is horrible, because it can bite you sometimes, but work others, and if you've just blindly assumed that Dictionary is going to play nice ("why shouldn't it? I thought, List does"), you really have to have your nose in it before you finally start to question your assumption.

我认为这个问题的答案是因为。net使用字符串实习，这可能会导致相同的字符串指向相同的对象(因为字符串是可变的，这不是一个问题)

(我说的不是string类上重写的相等运算符)