"Could not load type [Namespace].Global" causing me grief

Viewed 140912

In my .Net 2.0 Asp.net WebForms app, I have my Global.asax containing the following code:

<%@ Application CodeBehind="Global.asax.cs" Inherits="MyNamespace.Global" Language="C#" %>

However when I build I get an error stating-

Could not load type 'MyNamespace.Global'.

This seems to be because the MyNamespace namespace (defined in the code behind file Global.asax.cs) is not seen by the compiler in the Global.asax file (does not show in R# intellisence..). This turned out to be a very hard nut to crack... any help will be appreciated!

Note: The Global.asax and the Global.asax.cs are located in the same folder.

Note2: When compiling from the vs prompt with csc it compiles o.k.

34 Answers

Have you changed the namespace of your project? I've seen this happen occasionally where I've changed the namespace in the Project Properties dialog but Visual Studio hasn't changed the namespace declaration in existing code files.

Check the Build Action of Global.asax.cs. It should be set to Compile.

In Solution Explorer, Right-click Global.asax.cs and go to Properties. In the Properties pane, set the Build Action (while not debugging).

It seems that VS 2008 does not always add the .asax(.cs) files correctly by default.

If you rebuild or change a project and move over files from an old one, make sure to check the Inherit block of your global. In my case, the former project/solution was named intranet, and I had recreated it as Intranet, but when I moved over the files, it didn't like the lowercase (duh). Just do a general look-through of the names of the files.

Having been in the development game for almost 20 years, this chestnut has continued to plague me across multiple projects.

As such, today whilst experiencing this same problem again, against another project, I decided to investigate further and I do believe this is related to Bin folder location... or more specifically, the output path of the bin folder.

For me, for a simple service based web application configured to run/debug through IIS, it was changing the output path from bin\debug to bin\ that resolved it

Project > Properties > Build > Output path

Seriously hopes this helps.

I experienced this problem when I accidentally set "Chrome" to be the default browser for debugging. When I set it back to "IE" the problem disappeared. I am not sure why...


EDIT: I was about to delete this answer, because I wasn't sure about it, but then I had the problem again. I switched to browsing with Chrome, then back again to IE and it stopped! What gives!?

You need to set your Output path to bin\

We have a .net app running on a PROD server. When we copied the bin folder to the server for the latest release, we got the same error. We couldn't understand what was going on. It worked fine locally and on the TEST server. After some digging I noticed that some of the uploaded files had a size of 0 bytes.

It turned out it was the FTP client (Filezilla) that corrupted some of the uploaded files, which understandably made .net think some libraries was located elsewhere or missing.

We tried another FTP client and re-uploaded all files. And that seemed to have done the trick.

Related