Archive for the ‘Assemblies’ Category

Visual Studio 2005 ‘Could Not Load Type Global.asax’ and ‘Cannot Copy Assembly After Build Because It Is Being Used By Another Process’ and ‘Control Name is not a member of Page Name’

May 18, 2010

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 Build error 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 Inherits attribute, 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 CodeFile attribute 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.

Cannot Load File Or Assembly After Renaming DLL

May 22, 2008


Use an Elephant gun.


DDK renamed one of our DLLs from AgentMaintenance.dll to CompanyMaintenance.dll. After my next ‘Get Latest’ from our source code repository the solution failed to build saying ‘Could not load file or assembly AgentMaintenance’. No-one else in the project team was getting this error. It was obviously a conspiracy.

I did the following:

  • Searched through all References in my Visual Studio Projects looking for AgentMaintenance
  • Deleted everything in Temporary ASP.NET Files folder
  • Deleted all obj and bin files from my main project
  • Courtesy of Eric Falston, I stopped the World Wide Web Publishing Service, closed Visual Studio then re-opened Visual Studio and re-started the Service (this worked once).
  • Commenced video and phone surveillance of my workmates.

None of this solved the Assembly loading issue but the dossier on my Brazilian workmate proved to have significant omissions.

Returning to the issue at hand, DDK suggested using ‘Find In Files’ in Notepad++ to look for occurences of AssetMaintenance and I found a few in intruiging locations such as a Subversion .tmp file, the Visual Studio .suo file and a redundant project, AgentMaintenance.Persistence, which was no longer part of our VS solution.

I deleted the SVN .tmp file and the .suo file and the solution successfully built (once). Thereafter I found that deleting the .suo file after every build would allow the solution to load and run succesfully without compaining that it could not load AgentMaintenance.dll.

This kept me happy for a while as I reasoned I could find the real problem at a later time instead of just dealing with the problem symptomatically by deleting the suo file prior to each build. But then IT DIDN”T WORK. Not even deleting the .suo file could prevent the Godzilla-like re-emergence of “Cannot Load file or assembly…”

So, finally, and not before time, I pulled out the Elephant gun.

KER-BLAM! I exterminated my SVN Working Copy, did a clean SVN Checkout and re-built successfully. 1,000 builds later Godzilla still sleeps.

If the above doesn’t help, try this very informative thread.

For astounding video footage of what is possible with half a lobster, twelve cubic yards of Helio brand ball-bearings and a rubber mallet, please contact Blog Author and quote BRAZIL-808-MA.
Caution: Some scenes may disturb younger viewers