Мне трудно найти причину, по которой происходит следующая ошибка. Я опишу загадочные аспекты под описанием ошибки.
[A] ASP.common_resultmessagepanel_ascx нельзя преобразовать в
[B] ASP.common_resultmessagepanel_ascx .
Тип A происходит от 'App_Web_resultmessagepanel.ascx.38131f0b.2c4hpv_z, версия = 0.0.0.0, культура = нейтральная, PublicKeyToken = ноль'
в контексте «По умолчанию» в местоположении
'C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Временные файлы ASP.NET \ MyWebApp \ dc3e0df6 \ ba1606c8 \ App_Web_resultmessagepanel.ascx.38131f0b.2c4hpv_z.dll'.
Тип B происходит от 'App_Web_wz3shqfq, версия = 0.0.0.0, культура = нейтральная, PublicKeyToken = ноль'
в контексте «По умолчанию» в местоположении
'C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Временные файлы ASP.NET \ MyWebApp \ dc3e0df6 \ ba1606c8 \ App_Web_wz3shqfq.dll'.
Класс, на который ссылается ошибка, является пользовательским веб-элементом управления, унаследованным от System.Web.UI.UserControl и реализующим System.Web.UI.ITextControl.
Элемент управления зарегистрирован и используется на главной странице. Ни у одной из родительских главных страниц или страниц реализации нет экземпляров элемента управления.
Класс и страница разметки находятся в проекте веб-приложения.
Исключение не происходит как прямой результат кода приложения. , это происходит во время внутреннего выполнения кода .NET Framework.
Проект - это веб-приложение, а не веб-сайт.
Веб-приложение компилируется в один двоичный файл, а ресурсы, специфичные для культуры, компилируются в один двоичный культура.
Контекст, указанный для каждого типа в исключении, одинаков, но я смог убедиться, что при возникновении исключения в папке Temporary ASP.NET Files для приложения фактически есть два отдельных определения класса.
Пользовательский элемент управления всегда существовал и использовался в приложении, но впервые возникла исключительная ситуация после добавления пользовательского элемента управления на главную страницу.
Исключение не происходит последовательно. После создания временных файлов исключение будет происходить каждый раз, когда запрашивается страница. Если что-либо вызывает очистку или воссоздание временных файлов, случайным образом возникает вопрос о том, будут ли повторные временные определения классов / DLL создаваться заново. Это может быть изменение web.config, перезапуск пула приложений, иногда даже просто обновленный / перестроенный двоичный файл веб-приложения.
Последний бит трассировки стека:
ASP.Default.__BuildControl__control35(Control ctrl) in C:\Projects\ABC.Web\App_Themes\Default\CheckBox.skin:3
System.Web.UI.ControlSkin.ApplySkin(Control control) +12
System.Web.UI.PageTheme.ApplyControlSkin(Control control) +119
System.Web.UI.Control.ApplyStyleSheetSkin(Page page) +61
ASP.masterpages_mymaster_master.__BuildControlpnlResults() in C:\Projects\ABC.Web\MasterPages\MyMaster.master:10
ASP.masterpages_mymaster_master.__BuildControl__control2(Control __ctrl) in C:\Projects\ABC.Web\MasterPages\MyMaster.master:9
System.Web.UI.CompiledTemplateBuilder.InstantiateIn(Control container) +12
System.Web.UI.MasterPage.InstantiateInContentPlaceHolder(Control contentPlaceHolder, ITemplate template) +87
Предполагаемый источник-нарушитель (единственная строка в файле скина C: \ Projects \ ABC.Web \ App_Themes \ Default \ CheckBox.skin):
<asp:CheckBox runat="server" SkinID="FormInput" CssClass="FormLabel FormInputCheckBox" />
На данный момент я не знаю, вызвана ли эта проблема решением, его конфигурацией, IIS и пулом приложений, или чем-то связанным с самим каталогом временных файлов, где, возможно, старые файлы не удаляются. Я убедился, что временная папка не индексируется операционной системой.
Я обеспокоен тем, что в производственной среде пул приложений будет перезагружен или изменятся некоторые параметры конфигурации, в результате чего эти временные файлы будут воссозданы с повторяющимся определением класса и, следовательно, с ошибкой. Мы не можем позволить кому-либо тестировать приложение каждый раз, когда пул приложений перезагружается, и удалять временные файлы, если ошибка происходит до тех пор, пока приложение не загрузится правильно. Поэтому мне нужно выяснить, что является причиной дублирования, но на данный момент я не знаю, где еще провести расследование.
Есть идеи?
Я удалил пользовательский элемент управления с главной страницы и поместил его непосредственно на каждую страницу, которая требовала его и выполняла главную страницу.
Пока исключение больше не повторялось. Я собираюсь дать ему еще пару дней тестового времени, чтобы увидеть, не всплывет ли он снова.
Я все еще хочу знать, почему вообще произошло исключение. Кто-нибудь с глубокими знаниями о том, как IIS запускает веб-приложения .net или как создаются временные файлы?
Новая теория!
Хотя это веб-проект со скомпилированным двоичным файлом, экземпляр IIS, который я запускаю для разработки, указывает на папку проекта. Таким образом, файлы исходного кода на самом деле находятся в веб-пути. Я думаю, что IIS может компилировать файлы исходного кода в отдельные двоичные файлы, особенно если пул приложений перезагружается. Таким образом, учитываются дублирующиеся временные файлы, которые создаются, и ошибка.
Другие разработчики испытывали ошибки при запуске проекта из Visual Studio. Я не знаю, как это могло бы объяснить эти случаи, но я не исключаю, что это также является причиной.