Обнаружил проблему, которая возникает при использовании .NET x64 (под вистой). Если собирать проект (например, сам компилятор) MSBuild-ом из .NET x86, то компилятор вылетает с ICE при попытке загрузить mscorlib. А дело вот в чём.

В проекте установлено, что не нужно грузить стандартные библиотеки, и добавлена как reference сама mscorlib. MSBuild, запущенный в режиме x86, ресловит путь к ней используя свой путь к фреймворку, и передает компилятору не просто "mscorlib", а "c:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll ". Компилятор же запускается в режиме x64 и у него путь к фреймворку соотв-но "c:\Windows\Microsoft.NET\Framework64\v2.0.50727". Логично, что при попытке загрузить mscorlib из не того каталога он получает BadImageFormatException.

Выходом из положения кажется просто использовать MSBuild из x64. Но! Студия (devenv) работает по каким-то своим причинам в режиме x86, и msbuild она запускает вроде бы внутри себя, а не отдельным процессом. Даже если и отдельным, то x86. Что делать?

Еще вариант — отключить флаг NoStdLib и убрать из ссылок mscorlib. Для всего кроме Nemerle.dll это вроде бы приемлимо, а его можно собирать и батником.

Здравствуйте, Алексей П, Вы писали:

АП>Выходом из положения кажется просто использовать MSBuild из x64. Но! Студия (devenv) работает по каким-то своим причинам в режиме x86, и msbuild она запускает вроде бы внутри себя, а не отдельным процессом.

Все очень просто. Сама студия — это x86-процесс. Естественно, что и фрэймворк она грузит тоже x86-ой.

АП>Даже если и отдельным, то x86. Что делать?

АП>Еще вариант — отключить флаг NoStdLib и убрать из ссылок mscorlib. Для всего кроме Nemerle.dll это вроде бы приемлимо, а его можно собирать и батником.

Черт его знает как лучше поступить. Чтобы отлаживать такие вещи нужно иметь 64-битную ОСь установленной. А я честно говоря потрахался в свое время с 64-битной вистой и не нашел смысла в ее использовании. Так что остается только (гы-гы) на сервере отлаживаться.

Если кто-то возьмется и сделает варианты компиляции под обе платформы (разными батниками), то ему будет честь и хвала!

Здравствуйте, VladD2, Вы писали:

АП>>Еще вариант — отключить флаг NoStdLib и убрать из ссылок mscorlib. Для всего кроме Nemerle.dll это вроде бы приемлимо, а его можно собирать и батником.

Оказалось, не вариант. Кроме mscorlib и другие сборки сопротивляются.

VD>Черт его знает как лучше поступить. Чтобы отлаживать такие вещи нужно иметь 64-битную ОСь установленной. А я честно говоря потрахался в свое время с 64-битной вистой и не нашел смысла в ее использовании. Так что остается только (гы-гы) на сервере отлаживаться.

А я нормально перешел на х64 висту. Смысл прост — 4 и больше гига памяти.

VD>Если кто-то возьмется и сделает варианты компиляции под обе платформы (разными батниками), то ему будет честь и хвала!

Нашел неплохое решение В общем, если жестко сказать системе, что компилятор надо запускать в x86 режиме, то всё нормально. Остается проблема — как это лучше сделать. Я обнаружл только такой способ — "corflags /32bit+ ncc.exe". При этом сборка должна быть неподписанной, или ее надо будет переподписывать как-то, короче, это надо при компиляции выставлять. Но как это сделать, мне неведомо.

P.S. Еще хотелось бы увидеть в возможностях мсбилдной таски запускать компилятор под Mono, в особо сложных случаях это нужно (ну кривой у MS System.Reflection.Emit). Как я понимаю, это несложно — добавить свойство и по нему запускать вместо ncc "mono ncc.exe".