InvalidCastException for Object of the same type - Custom Control Load

Question

I have a very wired error, one of my custom controls seems that is create two compiled files, and when I try to load it dynamically with LoadControl() is just f

Answer 1

I've recently encountered similar problem when i was compiling a modified version of asp.net MVC 4 and importing the new DLL into the project.

Somehow i was referencing the old versions of the DLLs in the web.config (including the web.config in the views folder)

The error in my case was thrown because the two DLLs were different versions. 4.0.0 and 4.1.0. Maybe you should look into that. Maybe specify a version of the compiled files (i'm guessing DLLs)

I hope this helps you fix the problem.

other tips: I'm guessing you have some sort of version control system? if yes , revert all the changes back before this started and look carefully at the code and which models/controls change and how. if you are not using VCS... there isn't much you can do to revert the changes. And you should start using a VCS.

Answer 2

After a lot of debug on a upgraded ASP.NET website, my last bug was this one on runtime.

I just checked the Build/Publish option "use fixed naming and single page assemblies" and it solved my case :)

Here some useful links: https://msdn.microsoft.com/en-us/library/hh475319(v=vs.110).aspx

https://msdn.microsoft.com/en-us/library/aa479044.aspx

http://forums.asp.net/t/960707.aspx

Answer 3

This can happen when you have batching turned on and have some form of circular references at the directory level.

Please see this answer to see exactly what I mean by 'circular references' in this context, as the meaning is quite subtle.

If you manage to break the cycle (e.g. by moving a user control elsewhere), you will not hit this issue.

Update 1

I would think that in theory, this can only be caused by a cycle, but sometimes they can be hard to detect.

I'll give you an alternative solution which I think will work and is very easy to try (even though it is a bit of a hack). In the user control(s) that is giving you problems, add the following attribute in the directive:

<%@ Control Language="C#" [...] CompilerOptions="/define:dummy1" %>

If you see this with some other controls, you can add the same thing but with dummy2, dummy3, etc...

This will have the effect of not batching this one user control, since it has different compilation needs from the others. Technically, you can add any piece of C# command line as the CompilerOptions, but a dummy /define is the simplest and most harmless.

But unlike turning off batching globally, the perf impact will be minimal, since only a very small subset of pages will not be batched.

BTW, it goes without saying that what you're seeing is a bug in ASP.NET, and that bug has been there for probably 10+ years! Maybe at some point it should get addressed :)

Answer 4

In order to track the cause of the problem I believe that's important to know how your control was created. Please refer to this reading: Turning an .ascx User Control into a Redistributable Custom Control.

Step 1: Authoring the User Control

To author the user control, it is best to start with an empty app that contains nothing other than the ascx. While the authoring of the user control uses "standard" techniques, there are some restrictions that you need to be aware of in order for it to be successfully turned into a standalone custom control. The main restriction is that the user control needs to be self-contained. That is, it cannot be dependent on app global things like App_Code or global.asax. The reason for this is that since the goal is to turn the UserControl into a standalone DLL, it would break in other apps if it relied on code that is not part of that DLL. One exception to this rule is that the UserControl can be dependent on assemblies that live in the bin directory (or in the GAC). You just have to make sure that the other assemblies are always available when you use your custom control in other apps.

and

Step 3: Use the Publish Command to Precompile the Site

(...) Select "Use fixed naming and single page assemblies". This will guarantee that your user control will be compiled into a single assembly that will have a name based on the ascx file. If you don't check this option, your user control could be compiled together with other pages and user controls (if you had some), and the assembly would receive a random name that would be more difficult to work with.

In my opinion it's very likely that you have the user control compiled and registered in GAC as a separate assembly and also included in your web application DLL.

Note: Maybe this should have been a comment, but I wanted to include the quotes from the forementioned link. I hope it's helpful.

Answer 5

I have noticed sometimes the designer creates a second CodeBehind designer file, eg you would have:

OneProduct_MediumImage.ascx
OneProduct_MediumImage.ascx.cs
OneProduct_MediumImage.ascx.designer.cs
OneProduct_MediumImage.ascx.designer1.cs

You wont notice if you dont have "Show All Files" option in the Solution Explorer set, but for a web project the compiler will compile all files in the folder, not just the ones included in the project.

Second, if your project is a "Website Project", there are no namespaces, which can lead to many weird errors. Look at this SO question: Namespace problem .net

Finally, I managed to solve seeming random UserControl errors by setting the ClassName attribute on the control file, eg:

<%@ Control Language="cs" 
    AutoEventWireup="false" 
    CodeBehind="OneProduct_MediumImage.ascx.cs" 
    Inherits="ASP.Modules_OneProduct_MedioumImage"
    ClassName="OneProduct_MediumImageControl" %>