"Сообщение об ошибке Parser: не удалось загрузить тип" в Global.asax
Я работаю над проектом MVC3 и получаю следующую ошибку:
Сообщение об ошибке синтаксического анализатора: не удалось загрузить тип "GodsCreationTaxidermy.MvcApplication".
Ошибка источника:
Строка 1:
<%@ Application Codebehind="Global.asax.cs" Inherits="GodsCreationTaxidermy.Core.MvcApplication" Language="C#" %>
Ошибка, которую я получаю, не может загрузить GodsCreationTaxidermy.Core.MvcApplication, но на этом снимке экрана основная часть не отображается в ошибке:
У кого-нибудь есть идеи или решение этой ошибки?
43 ответа
Ваш локальный веб-сервер выполняет код, отличный от того, над чем вы работаете. Убедитесь, что вы прекратили отладку, остановите свой локальный веб-сервер, очистите и восстановите, как предложил Питер, дважды проверьте ваши global.asax и global.asax.cs и попробуйте снова.
Если это не работает, и вы используете локальный IIS, попробуйте удалить сайт в IIS Manager и заново создать его вручную.
Убедитесь, что путь выхода проекта (свойства проекта / Сборка) установлен в bin и не bin\Release или же bin\Debug
По какой-то причине IIS (сервер разработки VS или локальный IIS) всегда обращается к библиотекам из bin каталог (и не будет искать подкаталоги)
Попробуйте изменить файл global.asax (просто где-то добавить пробел) и перезапустить. это заставит встроенный веб-сервер обновить и перекомпилировать файл global.asax.
Также сделайте чистку и перестройте - должны решить проблему
Это иногда случается, если вы изменяете информацию о пространстве имен (уровень проекта или класс) после global.asax генерируется.
Щелкните правой кнопкой мыши на Global.asax файл и выберите "Открыть с помощью", а затем выберите "XML (текст) редактор с кодировкой" (другие редакторы также могут работать, но это то, что я использую).
Затем отредактируйте раздел "Наследование" в директиве XML
<% @ Application Codebehind = "Global.asax.cs" Inherits = "GodsCreationTaxidermy.MvcApplication" Language = "C#"%>)
так, чтобы оно соответствовало фактическому полному имени вашего класса приложения. И это все.
Другой вариант - скопировать весь ваш код из Global.asax.cs, а затем удалить и создать другой файл Global.asax (а затем скопировать код обратно в Global.asax.cs).
Я должен был пойти в BUILD -> MANAGER КОНФИГУРАЦИИ и - хм - поставить галочку рядом с моим проектом, чтобы убедиться, что он действительно будет построен.
У меня была эта проблема сегодня, и мне потребовалось некоторое время, чтобы найти причину.
По сути, мой основной проект VS2015 включал подпроект, который был построен с использованием более высокой версии.Net Framework.
Как ни странно, когда у вас возникнет эта проблема, VS2015 с радостью сообщит, что решение построено нормально, но когда вы попытаетесь запустить веб-сайт, он просто выдаст вам вводящую в заблуждение ошибку, предполагая, что ваш Global.asax.cs файл неверный.
Итак, если вы видите эту ошибку, и Очистка / Восстановление не помогает, откройте свой Проект References дерево, и проверьте восклицательные знаки.
Кроме того, проверьте ваш Output окно для таких сообщений:
The primary reference "C:\Projects\Business Objects 4\bin\Release\BusinessObjects.dll"
could not be resolved because it was built against
the ".NETFramework,Version=v4.5" framework.
This is a higher version than the currently targeted framework
".NETFramework,Version=v4.0".
Решение, конечно же, состоит в том, чтобы щелкнуть правой кнопкой мыши по основному проекту, выбрать верхнюю вкладку "Приложение" и изменить версию Target Framework на более высокую версию, соответствующую вашему подпроекту.
Раздражает, что Visual Studio 2015 позволит вам полностью создавать и запускать Решения, которые спокойно содержат эту проблему. Это напрашивается на неприятности..!
"СТРОИТЬ -> МЕНЕДЖЕР КОНФИГУРАЦИИ и - гм - поставьте галочку рядом с моим проектом, чтобы убедиться, что он действительно будет построен". Это и пошло в папку проекта в проводнике Windows, нажав опции и сняв флажок "Только для чтения", помогло.
Я только что столкнулся с этим в приложении MVC5, и у меня ничего не получалось. Это произошло сразу после того, как я попытался вернуть SVN к более старой версии проекта.
Мне пришлось удалить global.asax.cs, а затем добавить новый, щелкнув правой кнопкой мыши Project -> Add New Item -> Global.asax, и ТО, наконец, исправило это.
Просто подумал, что это может кому-то помочь.
Я работал над старым "основанным на папках" веб-проектом ASP.NET (который мне не нравится) - и обнаружил, что это мое исправление:
Создать App_Code папка (если у вас ее еще нет)
Переместить Global.asax.vb подать в App_Code папка
Разметка в Global.asax может пропускать любые пространства имен (по крайней мере, для этого стиля проекта, afaik):
<%@ Application Codebehind="Global.asax.vb" Inherits="MyApp" Language="VB" %>
... где "MyApp" - это имя класса, определяемого в Global.asax.vb
Да, я прочитал все ответы. Однако, если вы - я, и вы вытаскиваете все, что осталось от ваших волос, попробуйте проверить папку \bin. Как и большинство файлов proj, может быть несколько конфигураций, сгруппированных под элементом XML.PropertyGroup, затем я изменил OutputPathзначение из bin\Debug, чтобы удалить часть \Debug и перестроить. Это поместило файлы в папку \bin, что позволило Express IIS найти и загрузить сборку. Мне остается только гадать, как правильно управлять этими разными сборками, чтобы локальное развертывание отладки могло найти и загрузить целевую среду.
Удалить .vs каталог из корня решения. Clean. Перестроить.
Эта проблема иногда сводит меня с ума, и я неизбежно заканчиваю поиском ответов. Я подозреваю, что есть несколько причин, которые могут вызвать это исключение, это когда-то работает для меня.
У меня та же проблема, когда у меня есть 2 экземпляра Visual Studio, работающие в одном проекте. Я закрыл Visual Studio и открыл только один экземпляр, и теперь он работает нормально!
Вы также можете проверить свойства вашего сайта в IIS. (В IIS щелкните правой кнопкой мыши сайт и выберите "Свойства".) Убедитесь, что параметр "Физический путь" указывает на правильный путь для вашего приложения, а не для какого-либо другого приложения. (Это исправило эту ошибку для меня.)
Очистите папку для мусора. Создайте все зависимые библиотеки классов и отошлите их в основной проект, и соберите полное решение.
Я должен сообщить, что я попробовал по крайней мере 4 предложения из этого поста. Никто из них не работал. Тем не менее, я рад сообщить, что выздоровел, вернувшись из резервной копии. Только пришлось обновить мои последние изменения кода из файла журнала. Заняло не более 10 минут. Потратил 3 раза, что читая этот пост и пробуя другие предложения. Сожалею.
Это была очень странная ошибка. Удачи всем, кто столкнулся с этим гремлином.
Эта проблема была решена путем предоставления прав доступа к папке, а также проверки из IIS.
Мне дали разрешение всем, когда я тестирую в моей местной среде. Но в режиме публикации я думаю, что мы даем только разрешение пользователю ASP.Net.
Я тоже столкнулся с той же проблемой. Несмотря на следование каждому ответу, это не сработало. Затем я изменил "Inherits =namespace.class" на "Inherits =полное имя сборки", т.е. "Inherits =namespace.class, имя сборки, Version =, Culture =, PublicKeyToken =" Надеюсь, это поможет.
Это также может произойти, если вы случайно забыли установить для своего решения VS "Несколько загрузочных проектов", если вы используете Web и WebApi из одного решения.
Вы можете проверить это, щелкнув правой кнопкой мыши Solution в Solution Explorer и выбрав "Properties". Затем найдите "Startup Projects".
Решение для меня не было ни одним из вышеперечисленных. Мне пришлось удалить (а не воссоздавать) Global.asax и Global.asax.cs. Эти файлы существовали в папке, даже если на них не было ссылки в проекте. Видимо билд их еще видел. Поскольку я использую OWIN с Startup.cs, файл Global.asax устарел, и проблем с его удалением не возникло.
Я провел несколько дней по этому вопросу. Я, наконец, решил ее с помощью следующей комбинации предложений из этого поста.
- Измените цель платформы на Любой процессор. У меня не было этой конфигурации в настоящее время, поэтому мне пришлось пойти в Configuration Manager и добавить ее. Я специально собирал для х64. Одно это не решило ошибку.
- Измените путь вывода на
bin\вместоbin\x64\Debug, Я пробовал это уже несколько раз, прежде чем сменил цель платформы. Это никогда не имело никакого значения, кроме получения ошибки, из-за которой не удалось загрузить сборку из-за неверного формата.
Чтобы было ясно, я должен был сделать оба из них прежде, чем это начало работать. Я пробовал их по отдельности несколько раз, но это никогда не исправляло, пока я не сделал оба.
Если я изменю один из этих параметров на исходный, я снова получу ту же ошибку, несмотря на то, что я запустил Clean Solution и вручную удалил все в bin каталог.
Я провел буквально день, пытаясь решить эту проблему.
Единственное, что сработало, - это удаление файла.sln, создание нового и добавление проектов обратно один за другим.
¯ \ _ (ツ) _ / ¯ - Программирование - ¯\_(ツ)_/¯
Мое приложение было построено в более старой версии VS и не имело папку bin. Я обновил его до более новой версии, и мне приснился кошмар. Я наконец отследил эту ошибку до Проекта> Свойства> Приложение. Целевая структура была установлена на 2,0; изменение этого параметра на сервере в IIS Manager/App Pool решило проблему для меня.
Я попробовал абсолютно все здесь и ничего не получалось. Мой проект был в VS 2013. С тех пор я обновился до VS 2015, и в 2015 году я создавал все свои новые приложения, но загружал, компилировал, собирал и т. Д. Все мои старые приложения, которые были созданы в 2013 году в этой версии.
В итоге я просто загрузил решение в 2015 году, и оно решило его для меня.
TL;DR: окончательное решение для меня, после 3 дней попыток всех других ответов, которые я мог найти здесь, заключалось в том, чтобы установить для параметра «Включить 32-разрядные приложения» значение «Истина» в расширенных настройках моего пула приложений IIS, а затем воссоздать каталог временных файлов ASP.NET. и добавление разрешений на изменение и запись для моей группы IIS_IUSRS.
Шаги, которые я пробовал:
- Полностью очистить и восстановить решение.
- Завершите работу и перезапустите Visual Studio.
- Удалите каталоги временных файлов ASP.NET (C:\Windows\Microsoft.NET\Framework*). Вот где действительно начались мои проблемы: я удалил слишком много.
- Перезагрузите машину разработки.
- Удалите папку .vs и перестройте решение.
- Воссоздайте C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files. Мои проекты представляют собой 64-битные приложения, несмотря на то, что платформа сборки
AnyCPU. - Убедитесь, что выходной каталог был установлен на
bin/на веб-проектах. - Сотрите и проверьте чистую копию моей ветки управления версиями.
- Сотрите и клонируйте новую копию моего репозитория контроля версий.
- Запустите обновление Windows до последних версий .NET Frameworks.
- Восстановите, удалите и переустановите .NET Frameworks 3.5 и 4.8.
- Удалите и переустановите Visual Studio 2019 Professional.
- Удалите и переустановите функцию информационных служб Интернета в Windows.
- Понизьте версию пакета ASP.NET NuGet и перестройте решение (выдаются справочные ошибки из-за изменений в сборках). Обновите ASP.NET до того, что использовали мои проекты, и перестройте решение.
- Воссоздайте виртуальный каталог IIS через веб-свойства веб-проекта.
- Созданы «пустые» файлы Global.asax. Восстановить мои файлы без изменений.
- Заменять
Codebehind="Global.asax.cs"сCodefile="Global.asax.cs". Это начало показывать мне ошибки загрузки для ссылок на сборки, которые действительно существовали в системе. - Включите 32-разрядные приложения в пуле приложений IIS. Это начало отображать ошибку доступа к 32-битному временному каталогу.
- Восстановите разрешения для всех каталогов временных файлов ASP.NET (добавьте все, кроме полного доступа). Это, наконец, заставило мое веб-приложение снова работать.
Мне удалось собрать достаточно информации из множества ответов, которые я нашел в Интернете. Найдя этот ответ после поиска iis, не найдя ссылки .net dll, я попробовал последние пару шагов, которые заставили меня снова работать, в начале моего 4-го дня борьбы с этой невероятно расплывчатой проблемой.
Это было бы намного быстрее, если бы был какой-то способ диагностировать, почему не удалось загрузить Global.asax вместо слишком общегоCould not load typeошибка без подробностей.
Мораль этой истории: при очистке каталогов Temporary ASP.NET Files удаляйте содержимое каталогов, а не сами каталоги. В противном случае разрешения могут быть потеряны.
Я недавно испытал это в веб-приложении. Проблема заключалась в пакете nuget, зависящем от Microsoft.Net.Compiler и Microsoft.Code.Dom.
Они поддерживают многоуровневые версии компиляторов.
Это преобразовало мое приложение в веб-сайт ASP.NET вместо веб-приложения.. Мне потребовалась вечность, чтобы решить эту проблему - 2,5 дня!!!
Я удалил их из диспетчера Nuget, удалил файлы в каталогах obj и bin - закрытая студия - а затем снова открыл и перестроил проект. Это исправило, но
ЧТО БЫЛО БОЛЬШЕ!!
Надеюсь, я сэкономлю время другим на этом!
Следующее может быть возможным, поскольку ни один из упомянутых случаев в других ответах не совпал.
Проверьте и исправьте, если сборка не удалась. Не запускайте последнюю успешную сборку, если текущая сборка не удалась.
В моем случае при сборке некоторых проектов произошел сбой, поэтому я решил запустить последнюю успешную сборку (поскольку Visual Studio запрашивает запуск последней успешной сборки). Итак, после повторения вышеуказанного шага несколько раз один или несколько проектов начали давать сбой с сообщениями об ошибках.
Я исправил это очень простым способом. Все, что вам нужно сделать, это просто удалить все файлы в
ProjectName\binпапка, затем из верхней строки меню Visual Studio
Build->Rebuild Solutionчтобы перестроить проект еще раз, и все готово. Попробуйте запустить проект сейчас. Этот процесс работал у меня в Visual Studio 2022.
Проблема для меня в том, что я не включил global.asax.cs в свой проект. И поскольку я копировал файлы из.net 4.5 в 4.0, я не закомментировал строки, которые не нужны в 4.0. Потому что он не был включен Visual Studio скомпилировал его в любом случае без проблем. Но когда я включил его, он выделил строки, которые вызывают проблемы.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
//using System.Web.Http;
using System.Web.Mvc;
//using System.Web.Optimization;
using System.Web.Routing;
namespace YourNameSpace
{
public class WebApiApplication : System.Web.HttpApplication
{
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
//GlobalConfiguration.Configure(WebApiConfig.Register);
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
//BundleConfig.RegisterBundles(BundleTable.Bundles);
}
}
}
Я обнаружил, что изменение пространства имен в проекте без рефакторинга всего решения было моей проблемой. Проверьте свойства вашего проекта и посмотрите, какое у вас пространство имен, убедитесь, что оно выстроено по всей доске.