当您启动一个进程(使用System.Diagnostics)写入控制台，但从未读取控制台时。输出流，在一定数量的输出后，你的应用程序将出现挂起。

可变集合中的值对象

struct Point { ... }
List<Point> mypoints = ...;

mypoints[i].x = 10;

没有效果。

mypoints[i]返回一个Point值对象的副本。c#允许您修改副本的字段。默默地什么也不做。

更新: 这似乎在c# 3.0中被修复了:

Cannot modify the return value of 'System.Collections.Generic.List<Foo>.this[int]' because it is not a variable

合同在流。阅读是我见过很多人被绊倒的东西:

// Read 8 bytes and turn them into a ulong
byte[] data = new byte[8];
stream.Read(data, 0, 8); // <-- WRONG!
ulong data = BitConverter.ToUInt64(data);

这是错误的原因是流。Read最多读取指定的字节数，但完全可以只读取1个字节，即使在流结束前还有7个字节可用。

它看起来与Stream如此相似，这并没有什么帮助。如果没有异常返回，则保证已写入所有字节。上面的代码几乎一直都能工作，这也没有什么帮助。当然，没有现成的、方便的方法来正确地读取N个字节也无济于事。

所以，为了堵住这个漏洞，提高人们的意识，这里有一个正确的方法:

    /// <summary>
    /// Attempts to fill the buffer with the specified number of bytes from the
    /// stream. If there are fewer bytes left in the stream than requested then
    /// all available bytes will be read into the buffer.
    /// </summary>
    /// <param name="stream">Stream to read from.</param>
    /// <param name="buffer">Buffer to write the bytes to.</param>
    /// <param name="offset">Offset at which to write the first byte read from
    ///                      the stream.</param>
    /// <param name="length">Number of bytes to read from the stream.</param>
    /// <returns>Number of bytes read from the stream into buffer. This may be
    ///          less than requested, but only if the stream ended before the
    ///          required number of bytes were read.</returns>
    public static int FillBuffer(this Stream stream,
                                 byte[] buffer, int offset, int length)
    {
        int totalRead = 0;
        while (length > 0)
        {
            var read = stream.Read(buffer, offset, length);
            if (read == 0)
                return totalRead;
            offset += read;
            length -= read;
            totalRead += read;
        }
        return totalRead;
    }

    /// <summary>
    /// Attempts to read the specified number of bytes from the stream. If
    /// there are fewer bytes left before the end of the stream, a shorter
    /// (possibly empty) array is returned.
    /// </summary>
    /// <param name="stream">Stream to read from.</param>
    /// <param name="length">Number of bytes to read from the stream.</param>
    public static byte[] Read(this Stream stream, int length)
    {
        byte[] buf = new byte[length];
        int read = stream.FillBuffer(buf, 0, length);
        if (read < length)
            Array.Resize(ref buf, read);
        return buf;
    }

DateTime.ToString(“dd / MM / yyyy”);这实际上不会总是给你dd/MM/yyyy，而是会考虑到区域设置，并根据你所在的位置替换你的日期分隔符。你可能得到dd-MM-yyyy或类似的东西。

正确的方法是使用DateTime.ToString("dd'/'MM'/'yyyy");

DateTime.ToString(“r”)应该转换为使用GMT的RFC1123。GMT距离UTC只有几分之一秒，但是“r”格式说明符不会转换为UTC，即使问题中的DateTime指定为Local。

这将导致以下gotcha(取决于您的本地时间与UTC的距离):

DateTime.Parse("Tue, 06 Sep 2011 16:35:12 GMT").ToString("r")
>              "Tue, 06 Sep 2011 17:35:12 GMT"

哎呀!

海森堡表窗

如果你在做按需加载的事情，这会让你很难受，就像这样:

private MyClass _myObj;
public MyClass MyObj {
  get {
    if (_myObj == null)
      _myObj = CreateMyObj(); // some other code to create my object
    return _myObj;
  }
}

现在让我们假设你有一些代码在其他地方使用这个:

// blah
// blah
MyObj.DoStuff(); // Line 3
// blah

现在您需要调试CreateMyObj()方法。因此，您在上面的第3行上放置了一个断点，目的是进入代码。为了更好地度量，您还在上面的行中放置了一个断点，表示_myObj = CreateMyObj();，甚至在CreateMyObj()本身中也放置了一个断点。

代码在第3行碰到断点。你进入代码。您希望输入条件代码，因为_myObj显然是空的，对吗?嗯…所以…为什么它跳过条件直接返回_myObj?!将鼠标悬停在_myObj上…事实上，它确实有价值!怎么会这样?!

The answer is that your IDE caused it to get a value, because you have a "watch" window open - especially the "Autos" watch window, which displays the values of all variables/properties relevant to the current or previous line of execution. When you hit your breakpoint on Line 3, the watch window decided that you would be interested to know the value of MyObj - so behind the scenes, ignoring any of your breakpoints, it went and calculated the value of MyObj for you - including the call to CreateMyObj() that sets the value of _myObj!

这就是为什么我称其为海森堡观察窗口-你不能观察值而不影响它…：）

明白了!

编辑-我觉得@ChristianHayter的评论应该包含在主要答案中，因为它看起来是解决这个问题的有效方法。所以任何时候你有一个惰性加载的属性…

用[DebuggerBrowsable(DebuggerBrowsableState.Never)]或[DebuggerDisplay("<loaded on demand>")]装饰你的属性。——克里斯蒂安·海特

所有UserControls中的DesignMode属性实际上不会告诉你是否处于设计模式。