Parsing Error Now Fixed -- But How?

[Steve Harclerode]

Hi,

I had an error with my Web app that I've seen many other people post, that
looked like this:

--------
Parser Error Message: Could not load type 'HealthData.Global'.

Source Error:

Line 1: <%@ Application Codebehind="Global.asax.cs"
Inherits="HealthData.Global" %>

Source File: c:\inetpub\wwwroot\HealthData\global.asax Line: 1
--------

Somewhere on google, I found a suggestion to change the word "Codebehind" in
Global.asax to "src" and see what happened. Well, that actually *resolved*
my issue (after doing the same thing for each .ASAX file in the app). My
question is, how? I then changed "src" back to "Codebehind" in all of the
files, and everything works great now!

I've checked the .DLL, and the date on it didn't change since this morning,
when I compiled it. What got changed as a result of my blind hacking?

Thanks -- I just like to learn about these things --

Steve Harclerode

 

[Marina]

The error was happening because you did not copy the DLL to your web server
(or you never compiled your project into a DLL to begin with).

The 'Codebehind' atttributes is used by VS.NET only, to know which
codebehind file contains the code for your class. You would then compile it,
you would get a DLL in your bin directory.You then have to copy this DLL to
your production server along with your .aspx pages. ASP.NET simply finds
your compiled code in the DLL, and does not need to do anything else. You do
not need to copy the .vb or .cs files.

By changing it to 'src', you told ASP.NET where the codebehind file is.
ASP.NET, then looks for the src attribute, and if it finds it, goes to that
file, and compiles it, the first time your web application is accessed. In
this scenario, you do not generate a DLL. ASP.NET compiles the file for you,
and generates a DLL which is then stored in some temp folder. In this
scenario the .vb and .cs files need to be copied to the production server,
so ASP.NET can find them to do the compilation.

 

[Steve Harclerode]

I think I found the issue -- the website is clustered, and the caching on
that sucker seems to be *too* good. Often the only way I can get the website
to look at new files is to delete a virtual directory and then re-create it.

- Steve