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