BadImageFormatException при переходе с ASP.Net Core 1.1 на 2.0

Я только что перенес приложение ASP.Net Core 1.1 в новую версию 2.0, которая только что была выпущена. Теперь я получаю следующее исключение:

System.BadImageFormatException: «Не удалось загрузить файл или сборку «dotnet-aspnet-codegenerator-design» или одну из ее зависимостей. Была предпринята попытка загрузить программу с неверным форматом.'

Исключение выдается в следующей строке (AddMvc):

public IServiceProvider ConfigureServices(IServiceCollection services)
{
    ...
    services.AddMvc(options =>
        {
            options.Filters.Add(new MiddlewareFilterAttribute(typeof(LocalizationPipeline)));
        })
        .AddJsonOptions(options =>
        {
            // Maintain property names during serialization. See:
            // https://github.com/aspnet/Announcements/issues/194
            options.SerializerSettings.ContractResolver = new DefaultContractResolver();
        })
        .AddViewLocalization(LanguageViewLocationExpanderFormat.Suffix)
        .AddDataAnnotationsLocalization();
}

неприятный скриншот исключения

Я ориентируюсь на .Net Framework 4.7, используя AnyCPU целевую платформу. Я использую win10-x64 RID, если это поможет . Каждый пакет Nuget обновлен и т. д.

Есть идеи? Мне не повезло с поиском в гугле.


c# asp.net asp.net-core asp.net-mvc asp.net-core-2.0
person ken2k    schedule 21.08.2017    source источник
comment
Любопытно, а что будет, если вырезать конфиг и просто сделать services.AddMvc();?   -  person DavidG    schedule 21.08.2017
comment
Кроме того, в вашем файле csproj какая версия Microsoft.VisualStudio.Web.CodeGeneration.Design у вас есть? (надеюсь 2.0.0)   -  person DavidG    schedule 21.08.2017
comment
@DavidG У меня такое же исключение с конфигурацией по умолчанию (services.AddMvc();). У меня есть версия 2.0.0 Microsoft.VisualStudio.Web.CodeGeneration.Design в моем csproj.   -  person ken2k    schedule 21.08.2017
comment
О, стоило попробовать. Возможно, вы могли бы переустановить этот пакет или проверить его зависимости, чтобы убедиться, что они тоже обновлены.   -  person DavidG    schedule 21.08.2017
comment
@DavidG Да, стоило попробовать! Я тоже пытался переустановить пакет, тоже безуспешно :/   -  person ken2k    schedule 21.08.2017
comment
Очистить кеш nuget и папки bin/obj? Также убедитесь, что у вас нет <PlatformTarget>x86</PlatformTarget> в вашем .csproj (было это один раз, другое было неправильным <RuntimeIdentifier>   -  person Tseng    schedule 21.08.2017
comment
@Tseng Нигде в моем csproj нет ссылок на x86:/Очистка кеша/пересборка не помогли:/   -  person ken2k    schedule 22.08.2017

Ответы (3)


arrow_upward
6
arrow_downward

такое же исключение возникло, когда я переключился с x86 на x64 (после обновления ядра 1.1 до 2.0).

Поскольку dotnet-aspnet-codegenerator-design на самом деле не нужен во время выполнения, я удалил эту ссылку. Но затем такое же исключение произошло со сборкой Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.

К счастью, эта проблема была связана с тем, что я не изменил идентификатор времени выполнения .NET Core (RID). Это все еще было установлено на win7-x86, поэтому я изменил его на win7-x64, и Libuv devepency мог загрузиться.

Я надеюсь, что будет какое-то исправление для dotnet-aspnet-codegenerator-design, поскольку эта зависимость, вероятно, необходима для формирования контроллеров и представлений...

Обновление: для этого есть проблема на Github (https://github.com/aspnet/Scaffolding/issues/601)

person David Urting    schedule 22.08.2017
comment
Я также удалил ссылку, это единственный обходной путь, который работает на данный момент. Тем не менее, мой проект всегда был нацелен на AnyCPU, поэтому я не уверен, откуда это взялось. Действительно похоже на баг. - person ken2k; 22.08.2017

arrow_upward
0
arrow_downward

Есть вероятность, что зависимость повреждена. Вы можете использовать такой инструмент, как Everything (https://filehippo.com/download_everything/), чтобы искать и находить коррумпированная зависимость. Скорее всего, он находится где-то в этой папке (C:\Program Files\dotnet\shared). Как только вы найдете его, попробуйте поискать в Google и повторно загрузить его (есть хороший шанс, вы найдете для него nuget), а затем замените старую\поврежденную версию (обязательно сделайте резервную копию).

Если у вас возникли проблемы с поиском замены для зависимости в Интернете, просто опубликуйте свой проект в папке, все зависимости будут скопированы в эту папку. Если вы публикуете свой проект и запускаете dotnet PROJECTNAME.dll, но по-прежнему получаете ту же ошибку, возможно, вам придется выполнить чистую установку или восстановление в Visual Studio.

Я надеюсь, что это сэкономит кому-то много времени, эта ошибка может занять некоторое время для отладки.

person Prince Owen    schedule 01.02.2019

arrow_upward
0
arrow_downward

Я тоже получал эту ошибку на хостинге SmarterASP.NET. Я не смог попробовать все предлагаемые здесь обновления файлов, но нашел другое решение, до которого я безуспешно пытался скомпилировать несколько целей. Наконец, все это только начало работать, когда я нацелился на Portable. На Smarter теперь он прекрасно работает как развертывание, зависящее от платформы, ASP 2.2 Core, Portable. Иногда мне кажется, что запустить Core — это все равно, что пройти через старый метод проб и ошибок. Как всегда, ваш пробег может отличаться.

person user3314553    schedule 08.06.2019