Cannot be dropped on [B]; The same context (default); Various Temp Files

Question

I find it difficult to find out exactly why the following error occurs. I will talk about the mysterious aspects of the error description below.

[A] ASP.common_resultmessagepanel_ascx cannot be used to
[B] ASP.common_resultmessagepanel_ascx .

Type A comes from 'App_Web_resultmessagepanel.ascx.38131f0b.2c4hpv_z, Version = 0.0.0.0, Culture = neutral, PublicKeyToken = null'
in the "Default" context in the location
'C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET files \ MyWebApp \ dc3e0df6 \ ba1606c8 \ App_Web_resultmessagepanel.ascx.38131f0b.2c4hpv_z.dll'.

Type B comes from 'App_Web_wz3shqfq, Version = 0.0.0.0, Culture = neutral, PublicKeyToken = null'
in the "Default" context in the location
'C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET files \ MyWebApp \ dc3e0df6 \ ba1606c8 \ App_Web_wz3shqfq.dll'.

The class referenced by the error is a web user control that inherits from System.Web.UI.UserControl and implements System.Web.UI.ITextControl.
The control is registered and used on the main page. None of the parent master or implementation pages have control instances.
The class and markup page are in the web application project.
The exception does not occur as a direct result of the application code, it occurs during the execution of the internal .NET code.
A project is a web application, not a website.
The web application is compiled into a single binary file, and culture-specific resources are compiled into a single binary file culture.

The context specified for each type in the exception is the same, but I was able to verify that when an exception occurs, there are actually 2 separate class definitions in the Temporary ASP.NET Files folder for the application.

A user control has always existed and was used in the application, but an exception started after the user control was added to the main page.

The exception does not occur sequentially. After creating temporary files, an exception will occur every time a page is requested. If something causes temporary files to be deleted or recreated, the coincidence is whether duplicate temporary class definitions / DLLs will be created again. This can be a change to web.config, reuse of the application pool, sometimes even just an updated / restored binary application of the web application.

Last bit of the stack trace:

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 

The alleged source of the violation (the only line in the skin file is C: \ Projects \ ABC.Web \ App_Themes \ Default \ CheckBox.skin):

 <asp:CheckBox runat="server" SkinID="FormInput" CssClass="FormLabel FormInputCheckBox" /> 

At this moment, I do not know if this problem is caused by the solution, its configuration, IIS and the application pool, or something related to the actual file of the temp file itself, where, possibly, the old files are not cleared. I checked that the temporary folder is not indexed by the OS.

I am concerned that in a production environment, the application pool will be recycled or some configuration parameter will change, and these temp files will be recreated using the definition of a repeating class and therefore errors. We cannot test the application every time the application pool processes and deletes temporary files if an error occurs until the application loads correctly. Therefore, I need to find out what causes duplication, but at the moment I do not know where else to explore.

Any ideas?

---

I removed the user control from the main page and placed it directly on each of the pages that required it, and executed the main page.

So far, the exception has not been repeated. I'm going to give him a couple more days of test time to see if he appears again.

I still want to know why the exception occurred at all. Anyone with deep knowledge of how IIS runs .net web applications or how temporary files are created?

---

New theory!

While this is a compiled binary web project, the IIS instance that I run for development points to the project folder. Thus, the source code files are actually in the web path. I think IIS can compile source code files into separate binary files, especially if the application pool is being processed. Therefore, accounting for duplicate temp files that are created and errors.

Other developers experienced errors when starting the project from the visual studio. I do not know how this will explain these cases, but I do not exclude this as a reason.

Answer 1

After a year and a half, seeing that this error periodically appears for developers in our team, I finally was able to collect enough data to draw some conclusions.

The key elements of the script that causes the error are the source code files in the web path and the low available memory on the dev machine on which the application is running. The low memory state causes the application pool to recycle or release memory more often than in a dedicated web hosting environment. When the memory containing the compiled code of the web application is freed and then a page is requested, the compiled code is reloaded into the memory of the application pool. Because the source code files are in the web path, .NET recompiles from the source code files and reloads into memory.

This situation does not occur in a dedicated hosting environment where only compiled DLLs and static files are deployed and never happened in our production environment. In addition, the use of memory in a dedicated environment should ideally never go to the point where frequent use of the application pool is required.

A Visual Studio solution consists of several projects, and developers typically have multiple VS instances, Mgmt SQL Server instance, and various other processes that cause low available memory on dev machines. The lower the available memory, the more often and more reliably an error will occur.

To clear the error state, the flush / iisreset application pool will clear the memory, and then recovery will usually fix the problem. If the available memory is still low, the problem may persist until more memory is available to run the application. Just closing some applications or otherwise freeing memory back into the OS should do the trick.

I'm still not sure why running the application through the Visual Studio web server instead of IIS has the same problem, but if it handles the memory the same way as IIS, then it is reasonable that the behavior is the same.

Answer 2

I'm not sure what happens in your case, but it happened to me in the following circumstances:

The type of website project, not the web application.

/Controls containing many ascx user elements.

/Client/Controls , containing other ascx user elements, some of which are registered and refer to /Controls usercontrols.

/Controls/BadControl.ascx using /Client/Controls/DupedControl.ascx as a child control.

The compiler starts in a circular dependency, trying to compile each folder into a separate assembly.

/Controls/BadControl.ascx requires /Client/Controls to compile first.

/Client/Controls requires /Controls to compile first.

Thus, the compiler writes and compiles DupedControl.ascx into its own separate assembly. Then /Controls , then /Client/Controls , into which DupedControl is still included.

At this point, there are two different types for DupedControl in two separate assemblies. DupedControl.ascx (markup) points to the correct type — let TypeA call it in the folder assembly — while the BadControl link points to TypeB in a small additional assembly.

When a page using BadControl is executed, DupedControl TypeA receives the instance through markup, but BadControl tries to insert it into the TypeB variable, as a result of which you described the error.

The solution is to move the ascx files around to get rid of the circular reference. I don’t remember for sure, but I think that perhaps the options for “single pages” and “fixed names” can also resolve it.

All that said, web application projects are compiled into one assembly, so I did not think that such a link to circular folders would be possible. Perhaps the problem lies elsewhere.

Answer 3

SOLVE!

I had a similar problem caused by LoadControl() strange behavior .. and failed to instantiate my control before .

strange but true ..

---

 MyUserControl myuc = new MyUserControl(); myuo = (MyUserControl)Page.LoadControl("~/UserControls/MyUserCOntrol.ascx"); 

does not work

---

 MyUserControl myuc = (MyUserControl)Page.LoadControl("~/UserControls/MyUserCOntrol.ascx"); 

works