我最近正在使用一个DateTime对象，并写了这样的东西:
DateTime dt = DateTime.Now;
dt.AddDays(1);
return dt; // still today's date! WTF?
AddDays()的智能感知文档说它在日期后添加了一天，但它并没有这样做——它实际上返回了一个添加了一天的日期，所以你必须这样写:
DateTime dt = DateTime.Now;
dt = dt.AddDays(1);
return dt; // tomorrow's date
这个问题以前已经困扰过我很多次了，所以我认为将最糟糕的c#陷阱分类会很有用。
当前回答
在虚方法中使用默认参数
abstract class Base
{
public virtual void foo(string s = "base") { Console.WriteLine("base " + s); }
}
class Derived : Base
{
public override void foo(string s = "derived") { Console.WriteLine("derived " + s); }
}
...
Base b = new Derived();
b.foo();
输出: 派生的基础
其他回答
对于C/ c++程序员来说，过渡到c#是很自然的事情。然而，我个人遇到的最大的问题(以及其他人在做同样的转换时遇到的问题)是没有完全理解c#中类和结构之间的区别。
在c++中，类和结构是相同的;它们只在默认可见性上有所不同，其中类默认为私有可见性，结构默认为公共可见性。在c++中，这个类定义
class A
{
public:
int i;
};
在功能上等价于此结构定义。
struct A
{
int i;
};
然而，在c#中，类是引用类型，而结构是值类型。这在(1)决定何时使用一个而不是另一个，(2)测试对象的相等性，(3)性能(例如，装箱/拆箱)等方面产生了很大的差异。
网络上有各种各样的信息与两者之间的差异有关(例如，这里)。我强烈建议任何想要过渡到c#的人至少要了解这些差异及其含义。
讨厌的Linq缓存抓到了你
看看我的问题导致了这个发现，以及发现这个问题的博主。
简而言之，DataContext保存了你曾经加载过的所有Linq-to-Sql对象的缓存。如果其他人对您之前加载的记录进行了任何更改，则您将无法获得最新数据，即使您显式地重新加载该记录!
这是因为DataContext上有一个名为ObjectTrackingEnabled的属性，默认为true。如果您将该属性设置为false，则记录将每次重新加载…但是…你不能使用SubmitChanges()持久化对该记录的任何更改。
明白了!
LinqToSQL和空集聚合
看这个问题。
如果你有一个LinqToSql查询，你正在运行一个聚合——如果你的结果集是空的，Linq不能计算出数据类型是什么，即使它已经声明了。
例:假设你有一个带有Amount字段的Claim表，它在LinqToSql中是十进制类型。
var sum = Claims.Where(c => c.ID < 0).Sum(c => c.Amount);
显然，没有任何声明的ID小于零，因此应该看到sum = null，对吧?错了!您会得到一个InvalidOperationException，因为Linq查询底层的SQL查询没有数据类型。你必须明确地告诉Linq它是一个小数!因此:
var sum = Claims.Where(c => c.ID < 0).Sum(c => (decimal?)c.Amount);
这真的很愚蠢，在我看来，这是微软的设计错误。
明白了!
也许不是真的抓住你，因为行为写得很清楚在MSDN中，但已经打破了我的脖子，因为我发现它相当反直觉:
Image image = System.Drawing.Image.FromFile("nice.pic");
这家伙留下了“不错”。图片“文件锁定，直到图像被处置。在我面对它的时候，我认为它会很好地加载图标，并没有意识到(一开始)，我最终有几十个打开和锁定的文件!Image一直跟踪它从哪里加载文件…
如何解决这个问题?我以为只用一行就行了。我期望FromFile()有一个额外的参数，但没有，所以我写了这个…
using (Stream fs = new FileStream("nice.pic", FileMode.Open, FileAccess.Read))
{
image = System.Drawing.Image.FromStream(fs);
}
LinqToSql批处理速度随着批处理大小的平方而变慢
以下是我探索这个问题的问题(和答案)。
In a nutshell, if you try to build up too many objects in memory before calling DataContext.SubmitChanges(), you start experiencing sluggishness at a geometric rate. I have not confirmed 100% that this is the case, but it appears to me that the call to DataContext.GetChangeSet() causes the data context to perform an equivalence evaluation (.Equals()) on every single combination of 2 items in the change set, probably to make sure it's not double-inserting or causing other concurrency issues. Problem is that if you have very large batches, the number of comparisons increases proportionately with the square of n, i.e. (n^2+n)/2. 1,000 items in memory means over 500,000 comparisons... and that can take a heckuva long time.
为了避免这种情况，您必须确保对于预计有大量项目的任何批处理，您都在事务边界内完成整个工作，在创建每个项目时保存它，而不是在最后进行一次大保存。
