Другой .NET 4.5 в Windows 7 и 8?

Я написал приложение .NET 4.5 на машине с Windows 7 с Visual Studio 2012, и оно отлично устанавливается и работает на Windows 7.

Когда я пытаюсь развернуть его на машине с Windows 8, он дает довольно катастрофический сбой с не очень полезным выводом в средстве просмотра событий.
Трассировка с помощью Dependency walker предполагает, что метод не может быть найден в одной / некоторых из основных dll Windows. Например:

LoadLibraryExW("C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscoreei.dll", 0x0000000000000000, LOAD_WITH_ALTERED_SEARCH_PATH) returned 0x00007FFDEA780000.  
GetProcAddress(0x00007FFDEA780000 [MSCOREEI.DLL], "RegisterShimImplCallback") called from "MSCOREE.DLL" at address 0x00007FFDEA82F3A9 and returned 0x00007FFDEA783444.  
GetProcAddress(0x00007FFDEA780000 [MSCOREEI.DLL], "RegisterShimImplCleanupCallback") called from "MSCOREE.DLL" at address 0x00007FFDEA82F3BC and returned NULL. Error: The specified procedure could not be found (127).

Изучая mscoreei.dll, я замечаю:

Компьютер с Windows 7
v4.0.30319.18408
613 456 байт

Компьютер с Windows 8
v4.0.30319.33440
633 424 байта

Обе машины (согласно детектору версии ASoft .NET) имеют .NET 4.5 Full.

Почему на моих машинах разные сборки .NET, и как я могу убедиться, что компилятор на моем компьютере с Windows 7 нацелен на правильную версию, которая есть на машинах с Windows 8?


.net windows-8.1 .net-4.5 visual-studio-2012
person DefenestrationDay    schedule 31.10.2013    source источник
comment
Предположительно - пакеты обновлений / патчи безопасности. Возможно, запустить обновление Windows?   -  person Bridge    schedule 31.10.2013
comment
@Bridge: я запускал обновление Windows миллион раз на обоих.   -  person DefenestrationDay    schedule 31.10.2013
comment
Я вижу, вы отметили Windows 8.1, которая поставляется с .net 4.5.1, но использует Visual Studio 2012 в Windows 7, которая поставляется с .net 4.5.0, поэтому номер версии отличается. Понятия не имею, почему он потерпит катастрофу!   -  person JMK    schedule 31.10.2013
comment
@JMK: Я установил 4.5.1 на свой компьютер с Windows 7 на случай, если проблема возникла.   -  person DefenestrationDay    schedule 31.10.2013
comment
Странно, похоже, что LOAD_WITH_ALTERED_SEARCH_PATH устарел в Windows 7, может быть, он вообще не существует в Windows 8.1?   -  person JMK    schedule 31.10.2013
comment
@JMK: Хорошее наблюдение. Я загрузил 4.5.1 SDK и настроил его на случай, если вопрос .. Но вообще без изменений ..   -  person DefenestrationDay    schedule 31.10.2013
comment
Вы используете LOAD_WITH_ALTERED_SEARCH_PATH где-нибудь в своем коде для загрузки C ++ DLL или чего-либо подобного?   -  person JMK    schedule 31.10.2013
comment
@JMK: Не я - но, возможно, сторонняя dll?   -  person DefenestrationDay    schedule 31.10.2013
comment
Я добавил ответ, просто резюмируя в основном то, что я вставил в комментарии.   -  person JMK    schedule 31.10.2013

Ответы (3)


arrow_upward
5
arrow_downward

Да, это нормально. В Windows 8 также есть собственная версия .NET 3.5. Ничего необычного, .NET Framework сильно зависит от версии операционной системы. И причина, по которой он предустановлен в Windows 8.

Эта зависимость особенно примечательна для MSCoree, «прокладки загрузчика» для .NET framework. Это довольно драматичный трюк: он может заставить Windows создать 64-битный процесс из 32-битного EXE-файла. В этом нет ничего простого, он тесно взаимодействует с загрузчиком в Windows, чтобы это произошло, исправляя внутренние структуры данных, чтобы заставить его создать 64-битный процесс.

В появлении ошибки «Не удалось найти указанную процедуру» тоже нет ничего необычного. Вот почему он использует GetProcAddress () вместо неявной зависимости импорта. Использование GetProcAddress () - очень распространенный метод, позволяющий узнать, действительно ли поддерживается конкретная функция api.

Я серьезно сомневаюсь, что вы уже нашли настоящую причину сбоя вашей программы. Никогда не забывайте реализовывать событие AppDomain.CurrentDomain.UnhandledException для сообщения о необработанных исключениях, информация о сбоях, которую вы получаете из Windows, совершенно бесполезна.

person Hans Passant    schedule 31.10.2013

arrow_upward
1
arrow_downward

Похоже, что где-то в вашем коде или в сторонней DLL используется значение LOAD_WITH_ALTERED_SEARCH_PATH.

Это связано с тем, что функция LoadLibraryEx является звать куда-то. Это импортирует kernel32.dll , который отличается в Windows 7 по сравнению с Windows 8.

LOAD_WITH_ALTERED_SEARCH_PATH, который упоминается в ошибке уже устарел в Windows 7, возможно, этого вообще нет в Windows 8.

Я думаю, вам нужно установить Visual Studio в Windows 8.1 и оттуда отлаживать код, пока не произойдет исключение. Это, вероятно, поможет вам определить, где проблема быстрее, чем компиляция на 7 и попытка запустить на 8 при попытке расшифровать загадочные сообщения об ошибках. Как только вы найдете проблемную библиотеку, вы можете связаться с поставщиком, чтобы узнать, есть ли у него обновленная версия.

person JMK    schedule 31.10.2013
comment
Хороший совет попробовать отладку на 8.1. К сожалению, он компилируется и отлично работает с одним и тем же файлом проекта и исходным кодом ... - person DefenestrationDay; 04.11.2013
comment
Никаких ошибок. Нет проблем. Код тот же (компилируется машиной 8.1 на жестком диске 7 машин). Теперь проект ориентирован на .NET 4.5. - person DefenestrationDay; 04.11.2013

arrow_upward
0
arrow_downward

Это не особенно полезный ответ, но это была сторонняя dll, которая не могла справиться с запуском в процессе x64 на Win 8. Нет дополнительной информации о том, что именно вызвало реальную проблему.

person DefenestrationDay    schedule 07.04.2014