Может ли оператор C# is пострадать при оптимизации режима выпуска в .NET 4? ⇐ C#

[Anonymous]

Ниже приведен простой тестовый пример. Он успешно работает в отладочных сборках и терпит неудачу в выпускных сборках (VS2010, решение .NET4, x64):

Код: Выделить всё

[TestFixture]
public sealed class Test
{
[Test]
public void TestChecker()
{
var checker = new Checker();
Assert.That(checker.IsDateTime(DateTime.Now), Is.True);
}
}

public class Checker
{
public bool IsDateTime(object o)
{
return o is DateTime;
}
}

Похоже, оптимизация кода сеет некоторый хаос; если я отключу его в сборке Release, он тоже будет работать. Для меня это было довольно озадачивающим. Ниже я использовал ILDASM для дизассемблирования двух версий сборки:
Отладка IL:

Код: Выделить всё

.method public hidebysig instance bool IsDateTime(object o) cil managed
{
// Code size       15 (0xf)
.maxstack  2
.locals init (bool V_0)
IL_0000:  nop
IL_0001:  ldarg.1
IL_0002:  isinst     [mscorlib]System.DateTime
IL_0007:  ldnull
IL_0008:  cgt.un
IL_000a:  stloc.0
IL_000b:  br.s       IL_000d
IL_000d:  ldloc.0
IL_000e:  ret
} // end of method Validator::IsValid

Выпуск IL:

Код: Выделить всё

.method public hidebysig instance bool IsDateTime(object o) cil managed
{
// Code size       10 (0xa)
.maxstack  8
IL_0000:  ldarg.1
IL_0001:  isinst     [mscorlib]System.DateTime
IL_0006:  ldnull
IL_0007:  cgt.un
IL_0009:  ret
} // end of method Validator::IsValid

Кажется, сохранение и загрузка оптимизированы. Использование более ранних версий .NET Framework позволило устранить проблему, но это может быть просто случайностью. Меня такое поведение несколько нервирует. Может ли кто-нибудь объяснить, почему компилятор считает безопасным проводить оптимизацию, которая приводит к другому наблюдаемому поведению?

Подробнее здесь: https://stackoverflow.com/questions/554 ... n-on-net-4