vb.net COMPILATION debug=false 正在杀死我的 ASP.NET 站点

COMPILATION debug=false is killing my ASP.NET site

提问by PTansey

I have a large (to me) ASP.NET (4.5 Framework) application that was working fine when developed in and published from VS2012.

我有一个大型（对我而言）ASP.NET（4.5 框架）应用程序，在 VS2012 中开发和发布时运行良好。

I've since upgraded from VS2012 to VS2013 and I opened the solution without issue and it runs fine locally (on IIS Express).

我已经从 VS2012 升级到 VS2013，我打开了解决方案，没有问题，它在本地运行良好（在 IIS Express 上）。

I don't know if this is a red-herring, but I used NuGet to update the AJAX Control Toolkit for the first time (and its dependencies) and it appears to have worked.

我不知道这是否是一个红鲱鱼，但我第一次使用 NuGet 更新 AJAX 控制工具包（及其依赖项），它似乎已经奏效。

When I publish (file system publish) the site to our web server (IIS 8 in Windows Server 2012) it loads fine UNTIL I change <compilation defaultLanguage="vb" debug="true" targetFramework="4.5">to debug="false".
When I do, the site runs like a pig, sometimes pages don't even load, and its IIS Worker Process spikes the CPU and holds, growing in % until it consumes essentially all the CPU.

当我将站点发布（文件系统发布）到我们的 Web 服务器（Windows Server 2012 中的 IIS 8）时，它加载良好，直到我更改<compilation defaultLanguage="vb" debug="true" targetFramework="4.5">为debug="false".
当我这样做时，该站点像猪一样运行，有时甚至无法加载页面，它的 IIS 工作进程会刺激 CPU 并保持，以 % 的速度增长，直到它基本上消耗掉所有的 CPU。

EDIT: this happens on the server and on my PC (IIS Express)

编辑：这发生在服务器和我的 PC 上（IIS Express）

This test site's AppPool is running with the identical settings as our live site's AppPool. Of note:

此测试站点的 AppPool 以与我们的实时站点的 AppPool 相同的设置运行。值得注意的是：

• Enable 32-bit applications: True
• .NET Framework Version: v4.0
• Managed Pipeline Mode: Integrated

• 启用 32 位应用程序：True
• .NET 框架版本：v4.0
• 托管管道模式：集成

I expect you'll need more information, but I honestly don't know where to begin and I don't want to overwhelm with unnecessary detail.
Thank you in advance

我希望您需要更多信息，但老实说我不知道​​从哪里开始，我不想被不必要的细节淹没。
先感谢您

EDIT: I REALLY should have mentioned this:
the site is precompiled during publish in Release mode. I've never had to change to debug=false in my development environment prior to publish in the past.

编辑：我真的应该提到这一点：
该站点是在发布模式下发布期间预编译的。在过去发布之前，我从未在我的开发环境中更改为 debug=false。

I get this for each of the Projects in my solution: (0,0): warning : The following assembly has dependencies on a version of the .NET Framework that is higher than the target and might not load correctly during runtime causing a failure: [projectname], Version=1.0.0.0, Culture=neutral, PublicKeyToken=null. The dependencies are: Microsoft.VisualBasic, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. You should either ensure that the dependent assembly is correct for the target framework, or ensure that the target framework you are addressing is that of the dependent assembly.

我为解决方案中的每个项目都得到了这个： (0,0): warning : The following assembly has dependencies on a version of the .NET Framework that is higher than the target and might not load correctly during runtime causing a failure: [projectname], Version=1.0.0.0, Culture=neutral, PublicKeyToken=null. The dependencies are: Microsoft.VisualBasic, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. You should either ensure that the dependent assembly is correct for the target framework, or ensure that the target framework you are addressing is that of the dependent assembly.

EDIT:it appears this solution I inherited is a web SITE not APP. I don't know if that comes into play.

编辑：看来我继承的这个解决方案是一个网站而不是应用程序。我不知道这是否起作用。

采纳答案by PTansey

I ended having to call Microsoft on this. They used ProdDumpand LogManto analyze what was happening. In less than 24hrs came back to me and said:

我结束了不得不就此致电微软。他们使用ProdDump和LogMan来分析正在发生的事情。不到 24 小时，我回来对我说：

"Thread 19 seems to be pretty badly bogging down the CPU. The top of the stack indicates that AjaxMin is trying to do FindEntry on a Dictionary object and this was triggered from AjaxControlToolKit, specifically there appears to be something “CombineScripts” attribute defined on either the Master page or in the design page of OrderDetails.aspx. Basically this combines all the JS files and minifies them.

A quick test would be to disable the logic of CombineScript from AjaxControlToolKit and see if that improves performance"

“线程 19 似乎非常严重地阻塞了 CPU。堆栈的顶部表明 AjaxMin 正在尝试对 Dictionary 对象执行 FindEntry，这是从 AjaxControlToolKit 触发的，特别是似乎有一些“CombineScripts”属性定义在母版页或 OrderDetails.aspx 的设计页。基本上这组合了所有 JS 文件并缩小它们。

一个快速的测试是从 AjaxControlToolKit 中禁用 CombineScript 的逻辑，看看这是否能提高性能”

Google told me CombineScriptswas an attribute of ToolkitScriptManagerand since AJAX was always a suspect (for no real good reason, just a hunch) I jumped on it.

Google 告诉我CombineScripts是ToolkitScriptManager 的一个属性，因为 AJAX 一直是一个可疑的对象（没有真正的充分理由，只是一种预感）我就跳了进去。

Sure enough, changing my reference to the ToolkitScriptManagerto include CombineScripts="false"completely fixed the problem!

果然，将我对ToolkitScriptManager 的引用更改为包含CombineScripts="false"完全解决了问题！

<ajaxToolkit:ToolkitScriptManager ID="ToolkitScriptManager1" runat="server" CombineScripts="false" ScriptMode="Release" />

Related posts: I'm not the only one: https://www.google.ca/#q=ToolkitScriptManager+combinescripts+problem

相关帖子：我不是唯一一个：https: //www.google.ca/#q=ToolkitScriptManager+combinescripts+problem

Two helpful posts: http://forums.asp.net/t/1696523.aspxhttp://ajaxcontroltoolkit.codeplex.com/workitem/27558

两个有用的帖子：http: //forums.asp.net/t/1696523.aspx http://ajaxcontroltoolkit.codeplex.com/workitem/27558

回答by VovanF

Try to change .Net version for Application Pool to v4.0

尝试将应用程序池的 .Net 版本更改为 v4.0

回答by Maddy29

In the project project properties check for any reference to old version of Ajax control toolkit. If found any then remove the same and try again.

在项目项目属性中检查是否有任何对旧版 Ajax 控件工具包的引用。如果找到，则删除相同的并重试。

回答by Seyed Morteza Mousavi

I some times gave same error when I use nuget. I think conflict is your web.config assembly reference. Please compare your dll reference and web.config reference.

当我使用 nuget 时，有时会出现同样的错误。我认为冲突是您的 web.config 程序集参考。请比较您的 dll 参考和 web.config 参考。