COMPILATION debug=false is killing my ASP.NET site

Question

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

I've since upgraded from VS2012 to VS2013 and I opened the solution without issue and it runs fine locally (on 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.

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.

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

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

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

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.

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.

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

Answer 1

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

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

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

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

<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

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