Had a berserk time trying to load one of our corporate websites for the first time on a new DEV machine. It was an exemplary Journey Of Pain which I will now share with you.
The web site comprises 12 projects. Even after I loaded them down from Visual Source Safe into a solution and put in the necessary references to each other via Add Reference I still had a kaleidoscope of errors and warnings which no one here had ever seen before. My colleague performed a ‘Clean Solution’ which miraculously removed a lot of the warnings and errors.
Learning Point #1: When downloading a non-trivial solution from Visual Source Safe, do a Clean Solution after adding in all the references. There is some forum chat that says a Rebuild All will do the same thing, but I found in practice that Clean Solution cut out a lot of warnings and errors which Rebuild All did not.
I was now left with Cannot Load Type Global.asax.
Opening up the Global.asax.vb page I found some unresolved references, so I added those, then rebuilt, but still got Cannot Load Type Global.asax., A bit of Googling told me that Cannot Load Type Global.asax meant by main dll was not being generated. So I excluded Global.asax.vb from the project to see if anything was being covered up and did a rebuild.
That rebuild revealed a squillion errors. Specifically, I got a Cannot Load Type on every single one of the User Controls (ASCX files), plus cannot copy assembly after build because it is being used by another process . Googling the Cannot Copy Assembly After Builderror I found that this can occur because hostingEnvironment shadowCopyBinAssemblies=”false” was set in web.config. I commented out that entry and lucked out on it working. Cannot Copy Assembly After Build was deaded.
Next thing was to add references to 3rd party DLLs required by the solution. The DLLs were not in our Source Control so i had to hunt them up on the Web. these Dlls were referenced in our Web.Config file and not directly anywhere else, but they came out as obvious errors during the build.
This left me with 96 errors along the line of Cannot Load Type whatever.ascx along with a generous sprinkling of ‘ControlName’ is not a member of ‘PageName’.
Attribute Blocks
These turned out to be sourced from the same basic issue: the aspx.designer file was not being recognised by the Code Behind file – they were not linking together as if they did not belong to the same Partial Class. Unusually the designer files were not nested below the ascx file along with the aspx.vb (code behind file). I spent ages trying to force these designer files to regenerate without flat out deleting them or converting to a Web Application Project and then hit the post by hennehelene in this ASP.NET forum thread which prescribed a weird alchemy, namely to include a CodeFile attribute to the aspx.vb file, compile then remove the CodeFile Attribute and compile again.
HenneHelene’s solution works for me because my pages had the same basic markup as hers: A CodeBehind attribute, an Inheritsattribute, but no CodeFile attribute. I was thus able to add then remove the CodeFile attribute as described above, but I subsequently returned the CodeFile attribute back to the page because I didn’t want any future developer encountering the same issue.
The presence of the CodeBehind attribute without the CodeFileattribute suggests that the web site I was loading originally began life as a .NET 1.1 application
Codebehind is a .NET 1.1 Page Attribute which is retained in.NET 2.0 for backwards compatibility. CodeFile is the corresponding .NET 2.0 attribute.