ASP.NET 损坏程序集“无法加载文件或程序集 App_Web_*”

发布于 2024-07-17 10:38:54 字数 2337 浏览 5 评论 0原文

我已经阅读了同一问题上发布的许多其他问题,但我仍然不明白原因以及如何防止它发生。

就我而言,这发生在生产服务器上。 我遇到了其他问题中描述的相同错误,我通过将程序集重新复制到 bin 目录中来解决它。 它们甚至不是重新编译的文件,它们与之前的文件相同 - 再次复制,然后它就可以毫无问题地开始工作。

奇怪的是,我正在使用 Web 部署项目将所有程序集文件重命名为基于文件夹的 dll。 所以folder.dll和folder.subfolder.dll而不是App_Web_jt8nxllz.dll。 但该错误仍然命名原始 App_Web_jt8nxllz.dll 文件。

删除C:\WINDOWS\Microsoft.NET\Framework[64]\v...\Temporary ASP.NET Files文件夹的内容有效并且一切正常,但有谁知道如何防止这种错误的发生? 此外,当发生在生产服务器上时,关闭 IIS 或重新启动它确实不太可行。 也许会自动清除调度程序上的 Temp 文件夹?

这里真正的问题是什么? 有什么特别的原因导致这种情况发生吗? 该网站将毫无问题地正常运转,然后突然间,整个文件夹停止工作并产生此错误。

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)

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)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

白首有我共你 2024-07-24 10:38:54

不仅仅是链接我的网站,但我遇到了这个问题,我写了 有关该主题的博客文章。 查看一下,它包含有关此主题的更多信息的链接。 但总结一下详细信息:

问题:

网站在尝试加载自定义 Web 控件时抛出错误。 您会看到,在上一个版本中,我们向另一个根据需要显示的自定义 Web 控件添加了一个新的自定义控件。 因为最外层/父控件和新的子控件在源代码中是单独的控件,所以当 .Net Framework 编译这两个控件之一并且不同时重新编译另一个控件时,您将得到一个过时的控件文件尝试引用旧版本的程序集。 事实上,.Net 框架在编译时将随机字符串附加到程序集的名称中,新编译的文件的名称和文件的先前版本会导致文件名不匹配,因此外部/父控件正在寻找一个不再存在的文件。

可能的解决方法或临时修复:

1) 通过在 web.config 文件中将编译标记的批处理属性设置为 false

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

2) 您还可以通过设置来减少发生的频率numRecompileBeforeAppRestart 属性:

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

请参阅知识库文章 934839 了解更多详细信息

问题发生后的修复:

1) 删除临时 ASP.Net 文件(这会关闭站点)

2) 强制父/外部控件重新编译、编辑和保存代码文件。 这是比#1 更好的修复选项,因为这不会导致网站瘫痪。

我的建议:

1) 首先,我认为我们应该实施上面的临时修复#1,这可能会防止将来出现所有问题,并且可能是我们需要的唯一答案。

2) 其次,我会在 QA 环境中下载并安装 Microsoft 的 934839 修补程序,以验证它不会导致任何问题。 在 QA 中测试修补程序一段时间后,我将安装该修补程序以永久修复此问题。 此时我们可以删除#1 周围的临时工作。

注意:
在进行临时修复 #1 后,我就没有再遇到这个问题了。 我已经进行此修复超过 12 个月了,一切都很好!

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 numRecompileBeforeAppRestart property:

<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!

甩你一脸翔 2024-07-24 10:38:54

我也遇到过这个问题,有一个修复程序。

http://weblogs.asp.net/scottgu/archive/2007/04/11/public-hotfix-patch-available-for-asp-net-compilation-issues.aspx

虽然它没有较新的机器/设置不再发生这种情况。

I've been hit with this, there is a hotfix for it.

http://weblogs.asp.net/scottgu/archive/2007/04/11/public-hotfix-patch-available-for-asp-net-compilation-issues.aspx

Although it doesn't happen with newer machines/setups anymore.

谈场末日恋爱 2024-07-24 10:38:54

清除临时文件或更改 web.config 对我来说不起作用。 对我来说,修复它的是重新启动我的计算机。

Clearing out the temp files or changing web.config didn't work for me. For me, what fixed it was restarting my computer.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文