Обновление: Я зарегистрировал отчет об ошибках с Microsoft Connect, голосуйте за нее!
Обновление 2: Microsoft отметила отчет об ошибках, как зафиксировано
Отправленный Microsoft 18.08.2010 в 17:25
Эта ошибка будет исправлена в будущей версии времени выполнения. Я боюсь, что слишком рано, чтобы сказать, будет ли это в пакете обновления или следующей главной версии.
Начиная с обновления до VS2010 я добираюсь, некоторое очень странное поведение с 'является' ключевым словом.
Программа ниже (test.cs) выводов, Верных при компиляции в режиме отладки (для x86) и Ложь при компиляции с оптимизацией на (для x86). Компиляция всех комбинаций в x64 или AnyCPU дает ожидаемый результат, Верный.
Все комбинации компиляции под.NET 3.5 дают ожидаемый результат, Верный.
Я использую пакетный файл ниже (runtest.bat), чтобы скомпилировать и протестировать код с помощью различных комбинаций компилятора платформа.NET.
using System;
public class Program
{
public static bool IsGuid(object item)
{
return item is Guid;
}
public static void Main()
{
Console.Write(IsGuid(Guid.NewGuid()));
}
}
@echo off
rem Usage:
rem runtest -- runs with csc.exe x86 .NET 4.0
rem runtest 64 -- runs with csc.exe x64 .NET 4.0
rem runtest v3.5 -- runs with csc.exe x86 .NET 3.5
rem runtest v3.5 64 -- runs with csc.exe x64 .NET 3.5
set version=v4.0.30319
set platform=Framework
for %%a in (%*) do (
if "%%a" == "64" (set platform=Framework64)
if "%%a" == "v3.5" (set version=v3.5)
)
echo Compiler: %platform%\%version%\csc.exe
set csc="C:\Windows\Microsoft.NET\%platform%\%version%\csc.exe"
set make=%csc% /nologo /nowarn:1607 test.cs
rem CS1607: Referenced assembly targets a different processor
rem This happens if you compile for x64 using csc32, or x86 using csc64
%make% /platform:x86
test.exe
echo =^> x86
%make% /platform:x86 /optimize
test.exe
echo =^> x86 (Optimized)
%make% /platform:x86 /debug
test.exe
echo =^> x86 (Debug)
%make% /platform:x86 /debug /optimize
test.exe
echo =^> x86 (Debug + Optimized)
%make% /platform:x64
test.exe
echo =^> x64
%make% /platform:x64 /optimize
test.exe
echo =^> x64 (Optimized)
%make% /platform:x64 /debug
test.exe
echo =^> x64 (Debug)
%make% /platform:x64 /debug /optimize
test.exe
echo =^> x64 (Debug + Optimized)
%make% /platform:AnyCPU
test.exe
echo =^> AnyCPU
%make% /platform:AnyCPU /optimize
test.exe
echo =^> AnyCPU (Optimized)
%make% /platform:AnyCPU /debug
test.exe
echo =^> AnyCPU (Debug)
%make% /platform:AnyCPU /debug /optimize
test.exe
echo =^> AnyCPU (Debug + Optimized)
При выполнении runtest.bat я получаю следующие результаты на своей установке Win7 x64.
> runtest 32 v4.0
Compiler: Framework\v4.0.30319\csc.exe
False => x86
False => x86 (Optimized)
True => x86 (Debug)
False => x86 (Debug + Optimized)
True => x64
True => x64 (Optimized)
True => x64 (Debug)
True => x64 (Debug + Optimized)
True => AnyCPU
True => AnyCPU (Optimized)
True => AnyCPU (Debug)
True => AnyCPU (Debug + Optimized)
> runtest 64 v4.0
Compiler: Framework64\v4.0.30319\csc.exe
False => x86
False => x86 (Optimized)
True => x86 (Debug)
False => x86 (Debug + Optimized)
True => x64
True => x64 (Optimized)
True => x64 (Debug)
True => x64 (Debug + Optimized)
True => AnyCPU
True => AnyCPU (Optimized)
True => AnyCPU (Debug)
True => AnyCPU (Debug + Optimized)
> runtest 32 v3.5
Compiler: Framework\v3.5\csc.exe
True => x86
True => x86 (Optimized)
True => x86 (Debug)
True => x86 (Debug + Optimized)
True => x64
True => x64 (Optimized)
True => x64 (Debug)
True => x64 (Debug + Optimized)
True => AnyCPU
True => AnyCPU (Optimized)
True => AnyCPU (Debug)
True => AnyCPU (Debug + Optimized)
> runtest 64 v3.5
Compiler: Framework64\v3.5\csc.exe
True => x86
True => x86 (Optimized)
True => x86 (Debug)
True => x86 (Debug + Optimized)
True => x64
True => x64 (Optimized)
True => x64 (Debug)
True => x64 (Debug + Optimized)
True => AnyCPU
True => AnyCPU (Optimized)
True => AnyCPU (Debug)
True => AnyCPU (Debug + Optimized)
Чтобы ответить на ваш последний вопрос, вы можете добавить атрибут MethodImpl
с опцией MethodImplOptions.NoInlining
в метод IsGuid
в качестве обходного пути для решения проблемы.
Я только что провел простой тест переключения между конфигурацией Debug и Release для x86 в .NET 4.0, и это, похоже, решило проблему. Я еще не запускал ваш runtests.bat.
Вы также должны отправить проблему в Connect , если она еще не отправлена, и связать ее со своим вопросом.
Это не круто. Я думаю, вам следует написать об ошибке. (connect.microsoft.com)
Также, похоже, это работает (я проверял только для вашего случая отказа):
public static bool IsGuid(object item)
{
return item.GetType() == typeof(Guid);
}
Я разработал аналогичный пример, который не работает точно так же:
using System;
using System.Runtime.CompilerServices;
public class Program {
static void Main() {
Console.Write(Verify(Test.Create()));
Console.ReadLine();
}
//[MethodImpl(MethodImplOptions.NoInlining)]
static bool Verify(IDisposable item) {
return item is Test;
}
struct Test : IDisposable {
public void Dispose() { }
public static Test Create() { return new Test(); }
}
}
Это ошибка оптимизатора JIT. Трудно сказать, это сильно оптимизирует код. Но мне кажется, что у него проблемы, когда он оптимизирует преобразование бокса. Честно говоря, довольно серьезная ошибка.
Эта ошибка исправлена, я больше не могу ее воспроизвести. Моя текущая версия clrjit.dll - 4.0.30319.237 от 17 мая 2011 года. Я не могу точно сказать, какое обновление исправило ее. 5 августа 2011 года я получил обновление безопасности, которое обновило clrjit.dll до версии 235 с датой 12 апреля, которая была самой ранней.
Вот мои результаты на XP SP3 (x86):
>runtest
Compiler: Framework\v4.0.30319\csc.exe
False => x86
False => x86 (Optimized)
True => x86 (Debug)
False => x86 (Debug + Optimized)
False => AnyCPU
False => AnyCPU (Optimized)
True => AnyCPU (Debug)
False => AnyCPU (Debug + Optimized)
>runtest v3.5
Compiler: Framework\v3.5\csc.exe
True => x86
True => x86 (Optimized)
True => x86 (Debug)
True => x86 (Debug + Optimized)
True => AnyCPU
True => AnyCPU (Optimized)
True => AnyCPU (Debug)
True => AnyCPU (Debug + Optimized)
Интересным моментом в этом результате является то, что цель .NET 4 не работает на AnyCPU (работает как x86), но работает на AnyCPU (работает как x64).
Интересно, что это работает правильно:
using System;
public class Program
{
public static bool IsGuid(object item)
{
return item is Guid;
}
public static void Main()
{
Guid s = Guid.NewGuid();
Console.Write(IsGuid(s));
}
}
Вот разница в il:
.method public hidebysig static void Main() cil managed
{
.entrypoint
// Code size 23 (0x17)
.maxstack 1
.locals init (valuetype [mscorlib]System.Guid V_0)
IL_0000: call valuetype [mscorlib]System.Guid [mscorlib]System.Guid::NewGuid()
IL_0005: stloc.0
IL_0006: ldloc.0
IL_0007: box [mscorlib]System.Guid
IL_000c: call bool Program::IsGuid(object)
IL_0011: call void [mscorlib]System.Console::Write(bool)
IL_0016: ret
} // end of method Program::Main
За исключением нескольких ошибок, рефлектор указывает, что единственные различия заключаются в методе IsGuid:
DEBUG:
.method public hidebysig static bool IsGuid(object item) cil managed
{
.maxstack 2
.locals init (
[0] bool CS$1$0000)
L_0000: nop
L_0001: ldarg.0
L_0002: isinst [mscorlib]System.Guid
L_0007: ldnull
L_0008: cgt.un
L_000a: stloc.0
L_000b: br.s L_000d
L_000d: ldloc.0
L_000e: ret
}
RELEASE:
.method public hidebysig static bool IsGuid(object item) cil managed
{
.maxstack 8
L_0000: ldarg.0
L_0001: isinst [mscorlib]System.Guid
L_0006: ldnull
L_0007: cgt.un
L_0009: ret
}
Я не владею свободно достаточно, чтобы объяснить эти различия, но это ответ вики сообщества, так что, может быть, кто-то еще может просветить нас?
Изменение метода, чтобы сделать его универсальным, работает вокруг этой проблемы (возможная ошибка?)
public static bool IsGuid<T>(T item)
{
return item is Guid;
}
Как принудительное включение его в локальную переменную ( но он должен использоваться в методе, чтобы предотвратить запуск оптимизаций):
public static bool IsGuid(object item)
{
bool a = item is Guid;
a.ToString();
return a;
}