"Parser Error Message: Could not load type" in Global.asax

Question

I'm working on an MVC3 project and receive the following error:

Parser Error Message: Could not load type 'GodsCreationTaxidermy.MvcApplication'.

Source Error:

Line 1: <%@ Application Codebehind="Global.asax.cs" Inherits="GodsCreationTaxidermy.Core.MvcApplication" Language="C#" %>

The error I get is cannot load GodsCreationTaxidermy.Core.MvcApplication but in this screen shot the Core part isn't displaying in the error:

Does anyone have any ideas or a solution to this error?

Pantomime

Do you really have GodsCreationTaxidermy.Core.MvcApplication class in your application? If not please create the same and compile the project. It will work for sure. – Ignescent

Yes I do have GodsCreationTaxidermy.Core.MvcApplication (Global.asax.cs) – Pantomime

The Global.asax file that seems to be used (according to the screen shot) looks different than the one you have shown. – Pepe

check to see if the Inherits string is the same as the path to the class in your application (namespace + pathname), that is they are both GodsCreationTaxidermy.Core.MvcApplication – Rozele

That's one of the issues Darin, no matter what I do it always leaves the Core part out – Pantomime

delete global.asax file and add a new one and you will be alright. – Isthmus

helpful thread, cheers – Epimenides

This can happen if you change your project namespace, and don't update the namespace and using statements in all of the files in the project. – Benediction

Possible duplicate of "Could not load type [Namespace].Global" causing me grief – Earlearla

Abandon hope all ye who enter here. I tried almost every solution listed and still have this issue. – Dg

Answer 1

Your local web server is running different code than what you're actually working on. Ensure you have stopped debugging, stop your local web server, clean and rebuild as Peter suggested, double-check your global.asax and global.asax.cs, and try again.

If this doesn't work and you are using local IIS, try removing the site in IIS Manager and recreating it manually.

Hatbox

Very strange error indeed. I deployed to IIS on server and got this. Cleaned and recompiled worked for me too. – Hans

Clean/Rebuild + re-created the Virtual Directory, and then it worked. – Dactylic

Yes, working fine after deleting the existing application with same name in IIS and rebuild my project and then published. – Supertonic

Had the issue when I had the same project open in two Visual Studio instances. Therefore I had two instances of IIS Express running. I had to close one and then it was resolved. – Terricolous

You can also try deleting bin/obj folders in your project. – Heroin

got source control on a new PC, needed to build project... duhhhhhhhhhhhhhhhhhhhhh – Uncommon

I got this error as well. I assume the cause to be: I had changed IIS Express to run in x64 mode (for a different project). I went back to my other project, and got this error when running. I assume because nothing had to rebuild, it had been loaded up as an x86 app, in an x64 version of IIS Express. Cleaning the solution worked. – Libertylibia

I followed these instructions and threw in a few additional cleans/rebuilds, changed whitespace in the .asax file, reformatted my monitors, and did a jaunty jig accompanied by the pipes of Pan and that seemed to do the trick. – Chapiter

Sorry, I should have mentioned that last part. – Hatbox

Got this error, the Physical Path in IIS was pointing to the wrong directory. – Loathsome

You can also restart Windows, or reinstall it or get a new passport under new name, move to South America and start over there. Or just throw Windows in the rubbish container and move to Linux – Lutes

Answer 2

Check that the project output path (project properties / Build) is set to bin and not bin\Release or bin\Debug

For some reason IIS (VS development Server or Local IIS) always accesses the libraries from the bin directory (and won't look up for subdirectories)

Vocative

Credit where it's due. Fixed my problem, my application was set to use bin\Debug, changing it to bin resolved it. Many Thanks. – Adolfoadolph

It was interesting to learn that ASP.NET projects do not use the default output path bin/$(Configuration)/. Many thanks for the answer! – Keening

Well this was messing it up. Dlls were going to bin\debug. – Abecedarium

thank you !!! I was going crazy.. apparently another developer pointed the output to AppData\ – Personification

I was able to change it to bin, run it, then change it back to bin\Debug. Sometimes you just gotta shake it loose to get it back on track. – Weinhardt

@JamesPusateri: be careful though. Every time you launch, it will use what's in /bin. So probably the result of this one build you made after you changed it. – Vocative

Good call @Vincent I deleted the bin folder after this and it does in fact begin failing again. Odd little quirk that. – Weinhardt

Answer 3

Try modifying your global.asax file (simple add a space somewhere) and re-run. this will force the built in webserver to refresh and recompile the global.asax file.

Also do a clean and rebuild - should fix the problem

Mcevoy

Modifying global.asax didn't do anything for me, but a clean and rebuild fixed the problem :) – Jd

I had this problem when I ran out of power. Clean and rebuild helped. Thanks! – Nasya

Clean failed. Build failed. I had no issues with my build path. This, however, did the trick. Thanks! – Smectic

Thank you for your answer Mr. Munnings – Cleistogamy

Answer 4

This happens sometimes if you change namespace information (project or class level) after the global.asax is generated.

Right click on the Global.asax file and select "Open With" and then select "XML (Text) Editor with Encoding" (other editors may work as well, but this is what I use).

Then edit the "Inherits" section in the XML directive

<%@ Application Codebehind="Global.asax.cs" Inherits="GodsCreationTaxidermy.MvcApplication" Language="C#" %>)

so that it matches the actual full name of your Application class. And that's it.

Another option is to copy off all your code from Global.asax.cs and then delete and create another Global.asax file (and then copy the code back into Global.asax.cs).

Waybill

This worked for me also. I'd changed the namespace for the assembly for all projects in the solution. So had to edit the Global.asax file as stated in this answer, and make it match what's in the Project Configuration settings. – Interlocutor

How do I find out what the full name is of my application class? I've tried everything to sort this out but it still isnt working. Losing my mind – Tripos

Answer 5

I closed and reopened visual studio and it worked.

Bump

close ALL your visual studio – Germangermana

First we should all try getting out of the car, shutting all the doors, then getting back in again. – Tidbit

no, you have to close the doors on ALL your cars, at the same time. – Codicil

Yes I needed to close the doors too. – Divers

Answer 6

I had to go to BUILD -> CONFIGURATION MANAGER and -- ahem -- check the box next to my project to ensure it actually gets built.

Zamia

I don't understand the downvote. This could potentially have been a solution. This is actually more relevant than most think... If unchecked, it is not always the most obvious location. Especially when there are several configurations. – Marchese

I like your answer and your reasoning! – Overboard

This was my problem, too, and I have no idea how the projects got deselected from the configuration. – Marta

For me, my Active Solution Platform somehow got changed from "Any CPU" to "Mixed Platforms", where all the builds were unchecked. Switching back to "Any CPU" had the builds checked. – Heterochromatic

Tried all mentioned above solutions, but this one worked for me. Thanks – Actinolite

@RaulNoheaGoodness I had precisely this issue and this fixed it for me! – Grasso

Answer 7

I had this issue today, and it took me a while to find the cause.

Basically, my main VS2015 project was including a sub-project which had been built using a higher version of .Net Framework.

Bizarrely, when you have this problem, VS2015 will happily report that the solution has built okay, but when you try and run the website, it just gives you that misleading error, suggesting that your Global.asax.cs file is wrong.

So, if you see this error, and Cleaning/Rebuilding doesn't help, open your Project's References tree, and check for exclamation marks.

Also, check your Output window for messages like this:

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".

The solution, of course, is to right-click on your main project, select the top tab, "Application", and change the Target Framework version to a higher version which matches your sub-project.

It's annoying that Visual Studio 2015 will let you fully build and run Solutions which quietly contain this problem. It's asking for trouble..!

Avery

I have warnings like this, but I've not changed anything so I'm confused why rebuilding to a higher framework would resolve. – Tripos

Answer 8

"BUILD -> CONFIGURATION MANAGER and -- ahem -- check the box next to my project to ensure it actually gets built." That and going to the project folder in windows explorer, pressing options and unchecking the "Read only" checkbox helped.

Personable

simply it worked for me. The project has not has built option enabled I don't know why but this workaround was what I needed, thanks. – Prettypretty

Answer 9

I just encountered this on an MVC5 application and nothing was working for me. This happened right after I had tried to do an SVN revert to an older version of the project.

I had to delete global.asax.cs and then added a new one by right clicking Project -> Add New Item -> Global.asax and THAT finally fixed it.

Just thought it might help someone.

Supplant

If that fixes it for you, there's probably something messed up about the "Build action" property of the existing global.asax.cs file. It should be set to "Compile". The build action of the global.asax file itself should be set to "Content". – Freed

I did exactly what @Supplant did, and the problem was solved! – Charbonnier

Answer 10

I was working on an older 'folder based' ASP.NET web project (which I loathe) - and found this to be my fix:

Create an App_Code folder (if you didn't have one already)

Move the Global.asax.vb file into the App_Code folder

The markup in Global.asax can leave out any namespaces (at least, for this style of project, afaik):

<%@ Application Codebehind="Global.asax.vb" Inherits="MyApp" Language="VB" %>

...where "MyApp" is the name of the class being defined in Global.asax.vb

Boatswain

Perfect. As I don't use Visual Studio to maintain my websites, this is absolutely ideal. – Rubdown

Answer 11

Delete the .vs directory from the solution root. Clean. Rebuild.

This issue drives me bonkers once in awhile and I inevitably end up here paging through answers. I suspect there are multiple causes that can produce this exception, this once works for me.

Weihs

Several hours of trying a thousand other suggestions and this is the one that did it for me. My application was running fine in Visual Studio, both in debug and release configurations, but once published to IIS I was getting the error. Deleting the .vs folder and re-deploying fixed the issue. – Suwannee

For anyone finding this, here are the exact steps 1. Close Visual Studio (It won't work if you skip this step) 2. delete the .VS file 3. Restart Visual Studio – Candis

Answer 12

Yes, I read all the answers. However, if you are me and have been pulling out all of what's left of your hair, then try checking the \bin folder. Like most proj files might have several configurations grouped under the XML element PropertyGroup, then I changed the OutputPath value from 'bin\Debug' to remove the '\Debug' part and Rebuild. This placed the files in the \bin folder allowing the Express IIS to find and load the build. I am left wondering what is the correct way to manage these different builds so that a local debug deploy is able to find and load the target environment.

Sitnik

This is the only thing that worked. So many buried bodies... it's stuff like this that makes me seriously consider other vocations. – Mutt

Well, I don't have a bin folder. I am working on a web site. – Insubordinate

Answer 13

You can also check your site's properties in IIS. (In IIS, right-click the site and choose Properties.) Make sure the Physical Path setting is pointing to the correct path for your application not some other application. (That fixed this error for me.)

Poff

Answer 14

Empty the bin folder. Build all the dependent class libraries and refer them in the main project, and build the complete solution.

Source

Arda

Answer 15

I have to report that I tried at least 4 suggestions from this post. None of them worked. Yet I am happy to report that I recovered by retrieving from back up. Only had to update my last code changes from log file. Took less then 10 minutes. Spent 3 times that reading this post and trying other suggestions. Sorry.

It was a very weird error. Good luck to anyone else encountering this gremlin.

Insubordinate

Answer 16

I have same problem when I have 2 instance of Visual Studio running same project. So I closed both Visual Studio and opened only one instance and It works fine now!

Ape

Answer 17

I spent multiple days on this issue. I finally got it resolved with the following combination of suggestions from this post.

1. Change platform target to Any CPU. I did not have this configuration currently, so I had to go to the Configuration Manager and add it. I was specifically compiling for x64. This alone did not resolve the error.
2. Change the output path to bin\ instead of bin\x64\Debug. I had tried this several times already before I changed the platform target. It never made a difference other than getting an error that it failed to load the assembly because of an invalid format.

To be clear, I had to do both of these before it started working. I had tried them individually multiple times but it never fixed it until I did both.

If I change either one of these settings back to the original, I get the same error again, despite having run Clean Solution, and manually deleting everything in the bin directory.

Cryptography

Answer 18

This issue I was solved by giving right permission of the folder as well as check from IIS.

I was given permission to everyone as I am testing in my local environment. But in publish mode I think we give only permission to ASP.Net user.

Miranda

Answer 19

I too faced the same problem. Despite of following every Answer it didnt work. Then I changed the "Inherits=namespace.class" to "Inherits=fully qualified assemble name" i.e "Inherits=namespace.class,assemblyname, Version=, Culture=, PublicKeyToken=" Hope it helps.

Vowelize

Answer 20

This can also happen if you accidentally forget to set your VS solution to "Multiple Startup Projects" if you are running a Web and WebApi from the same solution.

You can check this by right-clicking on Solution in the Solution Explorer and select 'Properties". Then look for 'Startup Projects'.

Republic

Mine was similar to this: I was running the wrong API project in the solution. I actually had a compiler error in the API I thought I was running, but VS didn't pick up on it when I ran the solution, even after a clean. – Shockey

Answer 21

The solution for me wasn't any of the above. I had to delete (and not recreate) Global.asax and Global.asax.cs. These files existed in the folder, even though they weren't referenced in the project. Apparently the build still saw them. Since I use OWIN with Startup.cs, the Global.asax file was obsolete and there was no issue with deleting it.

Ventilate

Answer 22

I also got the same error...check the name of the Application you developed properly ie. the namespace and the assembly name alloted and also try physically changing the name of the folder created for the application, all of this should be same as the name in the above namespace present in the file global.asax

Interbedded

Answer 23

I also got the same error...check the IIS Configuration of your Virtual Directory and be sure that Properties - ASP.NET - ASP.NET Version is the same of Project Properties - Application - Target Framework. (That fixed this error for me.)

Nemesis

Answer 24

My app was built in an older version of VS, and didn't have a bin folder. I had upgraded it to a newer version, and had a nightmare getting it to deploy. I finally tracked this error down to the Project > Properties > Application. The Target Framework was set to 2.0; changing it on the server to match in the IIS Manager/App Pool solved the issue for me.

Devoice

Answer 25

I found that changing the Namespace on the project, without refactoring that across the whole solution was my problem. Check your project Properties and see what your namespace is, ensure that lines up, across the board.

Ornament

Answer 26

The problem for me is that I didn't include global.asax.cs in my project. And because I was copying files from a .net 4.5 to a 4.0 I didn't comment out lines that are not needed in 4.0. Because it was not included visual studio compiled it anyway without issues. But when I included it, it highlighted the lines that cause problems.

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);
        }
    }
}

Interdict

Answer 27

I spent literally a day trying to resolve this.

The only thing that worked was deleting the .sln file, creating a new one, and adding the projects back in one by one.

¯\_(ツ)_/¯ - Programming - ¯\_(ツ)_/¯

Helio

Answer 28

For my case, the web assembly was part of GAC... so after build, it need to installed in GAC and it worked.

Funches

Answer 29

I encountered this error message and eventually discovered that the error message was misleading. In my case there appears to have been a routing issue in IIS which caused the global.asax from another site on the web server to be read thus generating the error.

In IIS, my site was bound to http:*80:webservices.local and contained an application called MyAPI. I received the dreaded message when calling the MyAPI application using the web server's ip address.

In order to successfully call my application I had to add a host file entry for webservices.local on all of the machines that called the MyAPI application. Then all of my requests had to be prefixed with http://webservices.local/MyAPI/ in order to route correctly.

Stane

Answer 30

I tried absolutely everything here and nothing worked. My project was in VS 2013. I have since upgraded to VS 2015 and have been creating all of my new applications in 2015 but loading, compiling, building etc all of my old apps that were built in 2013 in that version.

I ended up just loading the solution in 2015 and it resolved it for me.

Rasla

Answer 31

Two ways to get this:

• The configuration manager shows the dll builds as a mix of '64' and 'any cpu' builds. Putting them all to the same build fixes it.

• When switching between branches, the IIS express path is sometimes not updated. Right click 'IIS Express' in the task bar > Show all applications and verifty that the path is to the correct branch.

Lavonda

Answer 32

I faced the problem in VS 2017 out of no where, took my whole day going through 100 of solutions any of these didnt work. I then took my whole solution and started it on different machine having VS 2017 installation.. IT FINALLY WORKED. Than reinstalled VS 2017 on the original one and it started running on that too. I strongly recommend you try your solution on a different machine before wasting much time to debug it, bcz it is a BUG in VS 2017 as it seemed for me, have reported same to VS TEAM. Hope this helps any one in grief. Cheers.

Involuntary

Answer 33

I experienced this recently in a Web Application. The problem was a nuget package brought in a dependency to: Microsoft.Net.Compiler and Microsoft.Code.Dom

They support multilevel compiler versions ..

That converted my application to an ASP.NET website instead of the Web Application .. took me forever to resolve this - 2.5 days!!!

I deleted those from the Nuget Manager, deleted the files in obj and bin directories - closed studio - and then reopened and rebuilt the project . That fixed it but

WHAT A PAIN THAT WAS!!

I hope I save some others time on this one!

Mandrill

Answer 34

I had this on a very old solution. Turns out the real problem was these projects were building to 4.6.1 instead of where the rest of the referenced DLLs were build - 4.7.2. After changing all the projects in the solution to 4.7.2 it built successfully and the app ran.

Fishnet

Answer 35

I fixed it in very simple way. All you have to do is just delete all files in ProjectName\bin folder then from Visual studio top menu bar Build->Rebuild Solution to rebuild the project once again and you are done. Try to run the project now. This process worked for me in Visual Studio 2022.

Strew

Answer 36

If cleaning the solution, deleting the bin folder, or rebuilding the solution does not solve the issue, try recreating the virtual directory. It should work.

Debug -> Debug Properties -> Web -> Create Virtual Directory

Mulder

Answer 37

TL;DR: The final resolution for me, after 3 days of trying all the other answers I could find here, was setting Enable 32-bit Applications to True in my IIS application pool advanced settings, then recreating the Temporary ASP.NET Files directory and adding Modify and Write permissions for my IIS_IUSRS group.

Steps I tried:

• Completely clean and rebuild solution.
• Shut down and restart Visual Studio.
• Delete Temporary ASP.NET Files directories (C:\Windows\Microsoft.NET\Framework*). This is where my problems really started: I deleted too much.
• Reboot development machine.
• Remove .vs folder and rebuild solution.
• Recreate C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files. My projects are 64-bit applications, even though build platform is AnyCPU.
• Verify output directory was set to bin/ on web projects.
• Wipe out and check out a clean copy of my version control branch.
• Wipe out and clone a fresh copy of my version control repository.
• Run Windows update to latest versions of .NET Frameworks.
• Repair, uninstall, and reinstall .NET Frameworks 3.5 and 4.8.
• Uninstall and reinstall Visual Studio 2019 Professional.
• Uninstall and reinstall the Internet Information Services feature in Windows.
• Downgrade ASP.NET NuGet package and rebuild solution (issued reference errors due to changes in assemblies). Upgrade ASP.NET back to what my projects were using and rebuild solution.
• Recreate IIS virtual directory through web project's Web properties.
• Created "empty" Global.asax files. Restore my files after no change.
• Replace Codebehind="Global.asax.cs" with Codefile="Global.asax.cs". This started showing me load errors for references to assemblies that actually existed in the system.
• Enable 32-bit applications in IIS application pool. This started displaying an access error to a 32-bit temporary directory.
• Restore permissions to all Temporary ASP.NET Files directories (add all but Full Control). This finally got my web application working again.

I was able to cobble enough information together from the myriad answers I found all over the Internet. After finding this answer after searching for iis not finding referenced .net dlls, I tried the final couple steps that got me working again, on the beginning of my 4th day wrestling with this incredibly vague problem.

This would have gone a lot faster if there were some way to diagnose why the Global.asax was unable to be loaded instead of the too-generic Could not load type error with no detail.

Moral of this story: when cleaning the Temporary ASP.NET Files directories, delete the contents of the directories, not the directories themselves. Otherwise, permissions can be lost.

Typology

Answer 38

My scenario was that I had just created an IIS Application and had not built the solution. I needed to rebuild it to make it work.

Midsummer

Answer 39

Following can be a possibility as none of the mentioned cases in other answers matched.

Check & correct if the build is failing. Do not run last successful build if current build is failing.

In my case, build was failing for some projects and so opted for running last successful build (as Visual Studio ask for starting last successful build). So, after repeating above step several times, one or more projects started failing with reported errors.

Olnek

Answer 40

None of the top voted answers worked for me.

This worked for me-

Make sure you have IIS Express selected in right click on Project => Properties => Web => Servers

Leitmotif

Answer 41

I fixed error as below.

My .dll was copying in bin\Debug folder. because of these reason it was throwing Could not load type assembly.

Fix: I change the Project output path to build my dll's inside bin\ folder

 <OutputPath>bin\</OutputPath>

Argyll

Answer 42

cant load errors with your project firstly Fix your errors and after rebuild project its working

Samal