COMPOLATION debug = false убивает мой сайт ASP.NET

У меня есть большое (для меня) приложение ASP.NET(4.5 Framework), которое отлично работает при разработке и публикации VS2012.

С тех пор я обновил VS2012 до VS2013, и я открыл решение без проблем, и он работает нормально локально (в IIS Express).

Я не знаю, является ли это red-herring, но я использовал NuGet для обновления набора инструментов AJAX Control Toolkit в первый раз (и его зависимостей), и он, похоже, сработал.

Когда я публикую (файловую систему публиковать) сайт на нашем веб-сервере (IIS 8 в Windows Server 2012), он загружает прекрасные UNTIL, я меняю <compilation defaultLanguage="vb" debug="true" targetFramework="4.5"> на debug="false".
Когда я это делаю, сайт работает как свинья, иногда страницы даже не загружаются, а его рабочий процесс IIS увеличивает процессор и удерживается, увеличиваясь в%, пока не потребляет практически весь процессор.

EDIT: это происходит на сервере и на моем ПК (IIS Express)

Этот тестовый сайт AppPool работает с идентичными настройками, такими как наш живой сайт AppPool. Примечание:

Включить 32-разрядные приложения: True
Версия .NET Framework: v4.0
Управляемый режим трубопровода: интегрированный

Я ожидаю, что вам понадобится дополнительная информация, но я честно не знаю, с чего начать, и я не хочу подавлять ненужные подробности.
Заранее благодарю

РЕДАКТИРОВАТЬ: Я ДЕЙСТВИТЕЛЬНО должен был упомянуть об этом:
сайт предварительно скомпилирован во время публикации в режиме Release. Мне никогда не приходилось менять debug = false в моей среде разработки до публикации в прошлом.

Я получаю это для каждого из проектов в моем решении: (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.

РЕДАКТИРОВАТЬ: кажется, что это решение, которое я унаследовал, является веб-сайтом, а не APP. Я не знаю, входит ли это в игру.

Ответ 1

Мне пришлось позвонить Microsoft по этому вопросу. Они использовали ProdDump и LogMan, чтобы проанализировать, что происходит. Менее чем через 24 часа вернулся ко мне и сказал:

"Нить 19, похоже, сильно увязнет с процессором. стек указывает, что AjaxMin пытается выполнить FindEntry на Объект словаря, и это было вызвано из AjaxControlToolKit, в частности, похоже, что-то атрибут" CombineScripts "определенные на главной странице или на странице дизайна OrderDetails.aspx. В основном это объединяет все JS файлы и их сокращает.

Быстрый тест - отключить логику CombineScript от AjaxControlToolKit и посмотрите, улучшает ли производительность"

Google сказал мне, что CombineScripts был атрибутом ToolkitScriptManager, и поскольку AJAX всегда был подозреваемым (без какой-либо реальной причины, просто догадка), я прыгнул на него.

Конечно, меняя ссылку на ToolkitScriptManager, чтобы включить CombineScripts = "false" полностью , исправлена проблема!

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

Похожие сообщения: Я не единственный: https://www.google.ca/#q=ToolkitScriptManager+combinescripts+problem

Два полезных сообщения: http://forums.asp.net/t/1696523.aspx http://ajaxcontroltoolkit.codeplex.com/workitem/27558

Ответ 2

В свойствах проекта проекта проверяйте любую ссылку на старую версию инструментария управления Ajax. Если найдутся какие-либо, удалите их и повторите попытку.

Ответ 3

Я несколько раз выдавал ту же ошибку, когда я использую nuget. Я думаю, что конфликт - это ссылка на сборку web.config. Пожалуйста, сравните ссылку на dll и ссылку web.config.

Ответ 4

Попробуйте изменить версию .Net для пула приложений на v4.0