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

Viewed 294328

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:

Error Page Screenshot

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

38 Answers

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

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.

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.

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.

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.

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.

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.

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.

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!

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.

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.

Recreating the virtual directory solved the issue for me.

(Before this, I tried the other suggestions listed here like cleaning the solution, deleting bin folder, rebuilding the solution etc.. None of them work until I recreate the virtual directory)

Debug -> Debug Properties -> Web -> Create Virtual Directory Where to find Create Virtual Directory

Related