C#或.NET中最糟糕的陷阱是什么？

垃圾回收和Dispose()。虽然您不必采取任何措施释放内存，但仍需通过Dispose()释放资源。当您使用WinForms或以任何方式跟踪对象时，这是一个极易被忽略的问题。

Stream.Read的契约是我看到许多人被绊倒的东西：

// 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);

    /// <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;
    }

foreach 循环变量的作用域！

var l = new List<Func<string>>();
var strings = new[] { "Lorem" , "ipsum", "dolor", "sit", "amet" };
foreach (var s in strings)
{
    l.Add(() => s);
}

foreach (var a in l)
    Console.WriteLine(a());

这段代码输出了五次"amet"，而下面的示例可以正常工作

var l = new List<Func<string>>();
var strings = new[] { "Lorem" , "ipsum", "dolor", "sit", "amet" };
foreach (var s in strings)
{
    var t = s;
    l.Add(() => t);
}

foreach (var a in l)
    Console.WriteLine(a());

一个让人沮丧的Linq缓存陷阱

查看我的问题，它导致了这个发现，以及发现问题的博主。

简而言之，DataContext会缓存你曾经加载过的所有Linq-to-Sql对象。如果其他用户对你之前加载的记录进行任何更改，即使你明确地重新加载该记录，你也无法获取到最新数据，这是因为DataContext上默认启用了ObjectTrackingEnabled属性。如果将该属性设置为false，则每次都会重新加载记录...但是...你不能使用SubmitChanges()持久化对该记录所做的任何更改。

注意!

MS SQL Server无法处理1753年之前的日期。这与.NET DateTime.MinDate常量不同，后者是1/1/1。因此，如果您尝试保存最早日期、格式错误的日期（最近在数据导入中发生了这种情况）或威廉征服者的出生日期，那么您将会遇到麻烦。没有内置的解决方案；如果您可能需要使用1753年之前的日期，则需要编写自己的解决方案。

今天我修复了一个长期存在的错误。这个错误出现在一个通用类中，该类在多线程场景中使用，并且使用静态int字段来提供无锁同步，使用Interlocked。该错误的原因是每个类型的通用类的每个实例都有自己的静态字段。因此，每个线程都获得自己的静态字段，并且没有像预期那样使用锁。

class SomeGeneric<T>
{
    public static int i = 0;
}

class Test
{
    public static void main(string[] args)
    {
        SomeGeneric<int>.i = 5;
        SomeGeneric<string>.i = 10;
        Console.WriteLine(SomeGeneric<int>.i);
        Console.WriteLine(SomeGeneric<string>.i);
        Console.WriteLine(SomeGeneric<int>.i);
    }
}

这会打印出

事件

我从未理解为什么事件是一种语言特性。它们很难使用：在调用之前需要检查 null 值，需要取消注册（自己），无法找出谁注册了该事件（例如：我是否注册过？）。为什么事件不只是库中的一个类呢？基本上它就是一个专门的 List<delegate> 吗？

刚刚发现一个奇怪的问题导致我花了很长时间进行调试：

你可以将可空整数的值加1而不会抛出异常，并且该值仍为null。

int? i = null;
i++; // I would have expected an exception but runs fine and stays as null

可枚举对象可以被多次评估

当你迭代一个惰性枚举的可枚举对象两次并获得不同的结果时，它会使你犯错。(或者你会获得相同的结果，但会不必要地执行两次)

例如，在编写某个测试时，我需要一些临时文件来测试逻辑：

var files = Enumerable.Range(0, 5)
    .Select(i => Path.GetTempFileName());

foreach (var file in files)
    File.WriteAllText(file, "HELLO WORLD!");

/* ... many lines of codes later ... */

foreach (var file in files)
    File.Delete(file);

当我使用File.Delete(file)时，出现了FileNotFound的异常，让我很吃惊！

发生的情况是files枚举被迭代了两次（第一次迭代的结果只是没有被记住），并在每个新的迭代中重新调用Path.GetTempFilename()，所以你会得到不同的临时文件名。

解决方法当然是通过使用ToArray()或ToList()来急切地枚举这个值：

var files = Enumerable.Range(0, 5)
    .Select(i => Path.GetTempFileName())
    .ToArray();

当你进行一些多线程的操作时，情况会变得更加可怕，比如：

foreach (var file in files)
    content = content + File.ReadAllText(file);

然后你发现在所有的写入后content.Length仍为0！你开始严格检查，确保没有竞争条件...浪费了一个小时后...你发现只是那个微小的Enumerable问题被忽略了....

这是一个非常棘手的问题，我浪费了2天时间来排查。它没有抛出任何异常，只是用一些奇怪的错误消息使Web服务器崩溃了。我无法在DEV中重现该问题。此外，对项目构建设置的实验不知何故让它在PROD中消失了，然后又回来了。最终我解决了问题。

如果你看到以下代码有问题，请告诉我：

private void DumpError(Exception exception, Stack<String> context)
{
    if (context.Any())
    {
        Trace.WriteLine(context.Pop());
        Trace.Indent();
        this.DumpError(exception, context);
        Trace.Unindent();
    }
    else
    {
        Trace.WriteLine(exception.Message);
    }
}

如果你重视自己的理智：

!!! 永远不要在 Trace 方法中放置任何逻辑 !!!

代码应该是这样的：

private void DumpError(Exception exception, Stack<String> context)
{
    if (context.Any())
    {
        var popped = context.Pop();
        Trace.WriteLine(popped);
        Trace.Indent();
        this.DumpError(exception, context);
        Trace.Unindent();
    }
    else
    {
        Trace.WriteLine(exception.Message);
    }
}