ASP.NET corrupt assembly “Could not load file or assembly App_Web_*

以下是从overFlow 复制过来的问题

I've read through many of the other questions posted on the same issue, but I still do not understand the cause and how to prevent it from happening.

In my case, this happens on the production server. I get the same error that has been described in other questions, and I resolve it by re-copying the assemblies into the bin directory. They are not even recompiled files, they are the same ones that were in there before - copied in again, and then it starts working without problems.

The weird part of it is that I am using Web Deployment Projects to rename all of my assembly files into folder-based dll's. So folder.dll and folder.subfolder.dll instead of App_Web_jt8nxllz.dll. Yet the error still names the original App_Web_jt8nxllz.dll file.

Deleting the contents of the C:\WINDOWS\Microsoft.NET\Framework[64]\v...\Temporary ASP.NET Files folder works and is all fine, but does anyone know how to prevent this error from happening? Also, shutting down IIS or restarting it is really not so feasible when it's happening on the production server. Perhaps cleaning out the Temp folder on a scheduler automatically?

What is the real issue here? Is there something in particular that causes this to happen? The site will be humming along no problem at all, and then all of the sudden, one entire folder stops working and produces this error.

Could not load file or assembly 'App_Web_jt8nxllz, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
Exception type 'System.IO.FileNotFoundException' was caught.
Source: App_Web_whv5zsvd
Target Site: Void __BuildControlTree(ASP.artists_controls_artistheader_ascx)
Stack Trace:
   at ASP.artists_controls_artistheader_ascx.__BuildControlTree(artists_controls_artistheader_ascx __ctrl)
   at ASP.artists_controls_artistheader_ascx.FrameworkInitialize()
   at System.Web.UI.UserControl.InitializeAsUserControlInternal()
   at System.Web.UI.UserControl.InitializeAsUserControl(Page page)
   at ASP._artists_artist_master.__BuildControlctlArtistHeader()
   at ASP._artists_artist_master.__BuildControlctlContent(Control __ctrl)
   at System.Web.UI.CompiledTemplateBuilder.InstantiateIn(Control container)
   at ASP.master_mysite_master.__BuildControlMainContent()
   at ASP.master_mysite_master.__BuildControlform1()
   at ASP.master_mysite_master.__BuildControlBody()
   at ASP.master_mysite_master.__BuildControlTree(master_mysite_master __ctrl)
   at ASP.master_mysite_master.FrameworkInitialize()
   at System.Web.UI.UserControl.InitializeAsUserControlInternal()
   at System.Web.UI.MasterPage.CreateMaster(TemplateControl owner, HttpContext context, VirtualPath masterPageFile, IDictionary contentTemplateCollection)
   at System.Web.UI.MasterPage.get_Master()
   at System.Web.UI.MasterPage.ApplyMasterRecursive(MasterPage master, IList appliedMasterFilePaths)
   at System.Web.UI.Page.ApplyMasterPage()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Not to just link up my site but i have run into this issue and i wrote a blog post on the topic. Check it out, it has links to more info on this topic. But to sum it up here are the details:

Problem:

The website is throwing an error trying to load a custom web control. You see in the last release, we added a new custom control to another custom web control that is displayed as needed. Because the outer most/parent control and the new child control are separate controls in source, when the .Net Framework goes to compile one of these two controls and does not recompile the other one at the same time you will have a an out of date file trying to reference the old version of the assembly. The fact that the .Net framework appends a random string to the name of the assembly at compile time the name of the newly compiled file and the previous version of the file cause a file name mismatch and therefore the outer/parent control is looking for a file that no longer exists.

Possible Work Around(s) or Temporary Fixes:

1) By setting the batch property of the compilation tag to false in the web.config file

<compilation debug="false" batch="false" />

2) You can also decrease how often it happens by setting by the numRecompileBeforeAppRestartproperty:

<compilation debug="false" numRecompilesBeforeAppRestart="50" />

See the KB Article 934839 for more details

Fixes for the Issue after it has already taken place:

1) Delete temp ASP.Net files (this takes down the site)

2) Force the parent/outter control to recompile, edit and save the code file. This is a better option for a fix than #1 because this does not bring down the website.

My Suggestion:

1) First I think that we should put in place the temporary fix #1 from above, this might prevent all issues in the future and could be the only answer we need.

2) Second I would download and install the 934839 hotfix from Microsoft in the QA environment to verify that it does not cause any problems. After some time of testing the hotfix in QA I would install the hotfix to have a permanent fix for this issue. At this time we could remove the temporary work around #1.

Note: After putting Temp fix #1 I have not had the problem again. I have had this fix in place for over 12 months and all is good!