Ответ 1
Убедитесь, что самая новая платформа (та, с которой вы скомпилировали ваше приложение) является первой в PATH. Это решило проблему для меня. (Найдено на форуме)
Я пытаюсь установить службу Windows с помощью InstallUtil.exe и получаю сообщение об ошибке
System.BadImageFormatException: Не удалось загрузить файл или сборку '
{xxx.exe}
' или одну из его зависимостей. Была сделана попытка загрузить программу с неправильным форматом.
Что дает?
РЕДАКТИРОВАТЬ: (не OP) Полное сообщение, извлеченное из дублирования, получило больше хитов [для googleability]:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319 > InstallUtil.exe C:\xxx.exe Утилита Microsoft (R).NET Framework для установки Версия 4.0.30319.1 Copyright (c) Корпорация Microsoft. Все права защищены.
Исключение произошло при инициализации установки: System.BadImageFormatException: Не удалось загрузить файл или файл сборки:///C:\xxx.exe или одну из его зависимостей. Была сделана попытка загрузить программу с неправильным форматом.
Убедитесь, что самая новая платформа (та, с которой вы скомпилировали ваше приложение) является первой в PATH. Это решило проблему для меня. (Найдено на форуме)
Более подробная информация о полноте, если она помогает кому-то...
Обратите внимание, что самая распространенная причина этого исключения в эти дни - попытка загрузить 32-битную (/platform:x86
) DLL-версию в процесс с 64-разрядным или наоборот (загрузка 64-разрядной версии (/platform:x64
) DLL в процесс, который 32 бит). Если ваш platform
неспецифичен (/platform:AnyCpu
), это не будет возникать (при условии, что никакие ссылки не имеют неправильной битности).
Другими словами, запуск:
% windir%\Microsoft.NET\Framework\v2.0.50727\installutil.exe
или
% windir%\Microsoft.NET\Framework 64\v2.0.50727\installutil.exe
не будет работать (замените в других версиях фреймворка: v1.1.4322
(только 32-разрядная версия, поэтому эта проблема не возникает) и v4.0.30319
, как указано выше).
Очевидно, что, как описано в другом ответе, вам также понадобится номер версии .NET для installutil
, который вы используете, чтобы быть >= (предпочтительно =), из файла EXE/DLL, на котором запущен установщик.
Наконец, обратите внимание, что в Visual Studio 2010, инструмент по умолчанию будет генерировать бинарные файлы x86 (а не любой CPU, как ранее).
Полная информация о System.BadImageFormatException (заявив, что единственная причина - несогласованная сущность - действительно грубое упрощение!).
Другой причиной для BadImageFormatException
установщика x64 является то, что в Visual Studio 2010, по умолчанию .vdproj
Install Project тип генерирует 32-разрядную InstallUtilLib
прокладку, даже в системе x64 (поиск "64-разрядных управляемых пользовательских действий выдает исключение System.BadImageFormatException" на странице).
Я думаю, что вы используете 64-битную версию инструмента для установки 32-битного приложения. Я также столкнулся с этой проблемой сегодня и использовал этот путь Framework для удовлетворения.
C:\Windows\Microsoft.NET\Framework\v4.0.30319
и он должен установить ваше 32-битное приложение просто отлично.
ОК, это проблема, которая у меня была, и, что исправлено, кажется очень актуальным для вышеперечисленного.
Я использую Visual Studio 2010 Express. Я написал тестовую службу, которая на самом деле ничего не сделала. Это было просто практикой для настоящей вещи позже.
Я написал службу и попытался установить ее с помощью installutil.exe
и получил следующую ошибку:
System.BadImageFormatException: Не удалось загрузить файл или сборку '{filename.exe}' или одну из его зависимостей. Была сделана попытка загрузить программу с неправильным форматом.
До сих пор то же, что и оригинальный автор.
Обзор Ruben выше о 32-битном выходе Visual Studio 2010 был спасителем здесь.
Я использовал 64-битную версию installutil.exe
и, конечно же, результат сборки Visual Studio 2010 был 32-битным. Чтобы добавить здесь немного дополнительную ценность, вы можете найти 32-битную версию последней платформы .NET и связанной с ней installutil.exe
в папке C:\Windows\Microsoft.NET\framework. Использование этой версии installutil.exe
исправило мою проблему; сервис, установленный без заминки!
Я надеюсь, что это поможет кому-то еще.
В случае, если это помогает кому-либо, я смог исправить это же исключение, используя этот ответ по аналогичному вопросу, но я не получил исключения от использования installutil. ехе.
У меня была эта проблема с WinForms Project с использованием VS 2015. Мое решение было:
У меня была такая же проблема. Я использую стандартную команду для выполнения. Это вызов X64 ro для тестирования X86. Мне нужно было указать X86, а не версию nunit-runner версии X64.
Подводя итог, как Build, так и Project\Build\Platform должны быть установлены на x64, чтобы успешно установить 64-разрядную службу на 64-разрядную систему.
Моя проблема была другой. Это произошло после неожиданного отключения моей машины Windows 7. Я выполнил чистое решение, и он побежал, как ожидалось.
После попытки всех упомянутых решений я нашел PlatformTarget
как - то добавил к AnyCPU
конфигурации в моем проекте .csproj.
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<PlatformTarget>x64</PlatformTarget>
</PropertyGroup>
Удаление линии работало на меня.
В случае наличия этого сообщения в реальных тестах, но не в модульных тестах, оно потому, что выбранные сборки копируются на лету в $(SolutionDir)\.vs\$(SolutionName)\lut\0\0\x64\Debug\
, Но иногда можно выбрать несколько сборок, например, dll VC++ в случае проектов взаимодействия c++/С#.
Пост-сборка xcopy
не решит проблему, потому что скопированный файл будет удален живым тестовым движком.
Единственный обходной путь на сегодняшний день (28 декабря 2018 г.) состоит в том, чтобы избегать живых тестов и выполнять все в модульных тестах с атрибутом [TestCategory("SkipWhenLiveUnitTesting")]
примененным к тестовому классу или методу тестирования.
Эта ошибка видна в любой Visual Studio 2017 до 15.9.4 и должна быть устранена командой Visual Studio.
Целевая сборка x64 Целевой сервер Хостинг IIS 64 Bit
Щелкните правой кнопкой мыши на хостинге appPool, на котором запущен веб-сайт/веб-приложение, и установите для включения 32-битное приложение = false.
Я столкнулся с этой проблемой сегодня. В моем случае цель моего приложения (имела ссылку на 64-битную DLL) была установлена на AnyCPU
но флажок Prefer 32-bit
разделе цели платформы был установлен по умолчанию. Это было проблемой, и все работало нормально после того, как вы Prefer 32-bit
выбор параметра Prefer 32-bit
.
Мы нашли другое решение проблемы с тем же симптомом:
Мы увидели эту ошибку, когда обновили проект с .net 4.7.1 до 4.7.2.
Проблема заключалась в том, что, хотя мы больше не ссылались на System.Net.Http в проекте, он был указан в разделе зависимых сборок нашего web.config. Удаление этой и любых других неиспользуемых ссылок на сборки из web.config решило проблему.
Ключ должен установить соответствующие настройки процессора для проекта, которые являются двумя местами.
А также убедитесь, что настройки archtecuture такие же, как в меню "Тест" >> "Настройки теста" >> "Архитектура процессора по умолчанию" >>, как показано ниже.