Note that there are some explanatory texts on larger screens.

plurals
  1. POcannot be cast to [B]; Same context (Default); Different Temp File
    text
    copied!<p>I'm having difficulty finding why exactly the following error is happening. I'll outline the puzzling aspects below the error description.</p> <p>[A]<strong>ASP.common_resultmessagepanel_ascx</strong> cannot be cast to<br/>[B]<strong>ASP.common_resultmessagepanel_ascx</strong>.</p> <p><strong>Type A</strong> originates from 'App_Web_resultmessagepanel.ascx.38131f0b.2c4hpv_z, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'<br/> <strong>in the context 'Default'</strong> at location<br/> 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\MyWebApp\dc3e0df6\ba1606c8\App_Web_resultmessagepanel.ascx.38131f0b.2c4hpv_z.dll'.</p> <p><strong>Type B</strong> originates from 'App_Web_wz3shqfq, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'<br/> <strong>in the context 'Default'</strong> at location<br/> 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\MyWebApp\dc3e0df6\ba1606c8\App_Web_wz3shqfq.dll'.</p> <p>The class referenced in the error is a web user control inheriting from System.Web.UI.UserControl and implementing System.Web.UI.ITextControl.<br/> The control is registered and used on a master page. None of the parent master pages or implementing pages have instances of the control.<br/> The class and the markup page are both in the web application project.<br/> The exception does not happen as a direct result of the application code, it happens during internal .NET Framework code execution.<br/> The project is a web application, not a web site.<br/> The web application is compiled into a single binary, with culture specific resources compiled into one binary per culture.<br/></p> <p>The context reported for each type in the exception is the same, but I was able to verify that when the exception occurs there are in fact 2 separate class definitions in the Temporary ASP.NET Files folder for the application.</p> <p>The user control has always existed and was used in the application, but the exception first started happening after the user control was added to a master page.</p> <p>The exception does not happen consistently. Once the temporary files get created, the exception will happen every time the page is requested. If anything causes the temporary files to be cleared or recreated, it is random as to whether the duplicate temporary class definitions/DLLs will be created again. This could be a web.config change, recycling the app pool, sometimes even just an updated/rebuilt web application binary. </p> <p>The last bit of the stack trace:</p> <pre><code> 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 </code></pre> <p>The supposed offending source (the only line in the skin file C:\Projects\ABC.Web\App_Themes\Default\CheckBox.skin):</p> <pre><code>&lt;asp:CheckBox runat="server" SkinID="FormInput" CssClass="FormLabel FormInputCheckBox" /&gt; </code></pre> <p>At this point I don't know if this issue is caused by the solution, its configuration, IIS and the app pool, or something related to the actual temp file directory itself where maybe old files are not getting cleared out. I've verified that the temp folder is not being indexed by the OS.</p> <p>I'm worried that in a production environment, the app pool will recycle or some configuration setting will change and cause those temp files to be recreated with the duplicate class definition, and thus the error. We can't have someone testing the application every time the app pool recycles and deleting temp files if the error occurs until the application loads correctly. So I need to find out what is causing the duplication, but at this point I don't really know where else to investigate.</p> <p>Any ideas?</p> <hr> <p>I've removed the user control from the master page, and put it directly into each of the pages that required it and were implementing the master page.</p> <p>So far the exception hasn't happened again. I'm going to give it another couple days of test time to see if it crops up again.</p> <p>I still want to know why the exception was happening at all. Anyone with in-depth knowledge of how IIS runs .net web apps, or how the temp files are created?</p> <hr> <p>New theory!</p> <p>While it is a web project with a compiled binary, the IIS instance I am running for development is pointed to the project folder. So the source code files are actually in the web path. I think IIS might be compiling the source code files into separate binaries, especially if the app pool recycles. Thus accounting for the duplicated temp files that are being created and the error.</p> <p>Other developers were experiencing the errors while running the project from within visual studio. I don't know how this would account for those cases, but I wouldn't rule it out as being the cause either.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload