Unable to cast object of type 'X' to type 'X'

The actual projects structure is:
+ MyServerFramework
|---QueryComponent.cs
...
+ MyServerFramework.Design
|---QueryComponentDesigner.cs
...

The MyServerFramework.Design project has a reference to MyServerFramework, and is compiled alone in its own solution which also contains MyServerFramework, and then placed in a folder that is referenced the SOFTWARE\Microsoft\.NETFramework\AssemblyFolders key so the IDE can find it.

The MyServerFramework project is then used in other solutions which don't contain the MyServerFramework.Design assembly. And here is where I'm seeing this error.

This happens in the following line, which is in the verb handler in QueryComponentDesigner:

QueryBuildStorProcDialog dlg = new QueryBuildStorProcDialog((QueryComponent)this.Component);

I've checked this at runtime with the debugger and this.Component IS of type QueryComponent.

Since it can't cast an object of a type to EXACTLY THE SAME TYPE, I guess either the error message is wrong or the problem lies in some versioning problem. Neither of the assemblies are strong-named, and I've tried changing the reference method: adding MyServerFramework.Design to the solution and referencing it as a project, referencing it by file name (Browse... in the add reference dialog), and adding it to the AssemblyFolders folder).

Is it possible the IDE is caching a previous version of my .Design assembly and using it instead of the current one (that it should find through the reference in the project or in the AssemblyFolders folder



Answer this question

Unable to cast object of type 'X' to type 'X'

  • pradeepta

    The problem is often that the assemblies are in a different directory. All you have to do is set all of the build output paths to the same folder. That way there will only be one copy of the dll. Then delete all of the old bin directories. This is much more like the environment after installation so this is perfectly valid. Worked for me, YMMV.
  • jvanderbeek

    I just can't believe there's noone at Microsoft being able to answer these questions, I just hope they are busy trying to come up with some solutions to the myriad of problems in VS2005.

    This particular problem apparently arises because of several factors:
    The IDE caches versions of assemblies in the following folder:

    "x\Documents and Settings\user\Local Settings\Application Data\Microsoft\VisualStudio\8.0\ProjectAssemblies"

    And at least in my case doesn't detect the particular assembly containing the type has a new version and it doesn't update the cache.

    If you attach to a running instance of VS2005 and check what Modules are loaded (you may need to add the Modules window command from the Debug category in Tools > Customize...) you'll probably see two versions of your assembly are loaded, or even the same version of the assembly loaded twice: in both cases you'll see the same error message.

    So first step, delete all folders in ProjectAssemblies. Next, make sure the IDE can only find ONE copy of your assembly, which is easier if you only have one copy of the DLL in your disk, and only one reference to it (or exactly the same reference from all projects) in your solution.

     


  • RBowden

    You can enter a blank line in your master page, then delete it, rebuild your program and your code should work after that.

    This will work.

    Kataria Bipin

  • Alan K

    Yes, I don't recall having this problem with the ProjectAssemblies folder, but then again I didn't work too much on the design-time area... was it there too

    In any case, I think this is aggravated on 2005 because they also automatically add components in projects to the toolbar, which I suspect adds another binding to the cache or another cache alltogether, augmenting the chances of caching an old version.

    I wonder if they do the correct thing in the DataSources window model or we have the same problems there...


  • Prabu.P

    I have no idea why it makes a difference that they're in different directories, but unifying the build paths for my projects into a single bin\ directory did indeed fix the problem. So add another vote for the single build directory solution.

  • Stacy Rothwell

    The properties that you defined are read-only that's why the designer is complaining.
  • VBKeith

    Anyone Please.
  • pranka

    Try this

    QueryComponent comp = (QueryComponent)this.Component;
    QueryBuildStorProcDialog dlg = new QueryBuildStorProcDialog(comp);

  • cjms

    Hi and THANKS a lot in advance.

    I'm getting this error in a different scenario, and I'm in a big urge to get this done, so please MS people and guys of the forum, any help is greatly appreciated.

    I'll use a simplified scenario of my case, but the error happens the same. I'm creating a new User Control, I add a DataGridView to it, that's the only control in it.  I then create a public property called "Columns" to expose the DataGridView Columns property so I can access the property to the Desingner Editor.  I do that this way:

    namespace WindowsApplication3
    {
        public partial class myUC : UserControl
        {
            public myUC()
            {
                InitializeComponent();
            }

            [Editor("System.Windows.Forms.Design.DataGridViewColumnCollectionEditor, System.Design, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a", typeof(UITypeEditor))]
            [MergableProperty(false)]
            [DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]
            public DataGridViewColumnCollection Columns
            {
                get { return this.dataGridView1.Columns; }
            }
        }
    }

    I took all that Attributes code from the System.Windows.Forms.DataGridView metadata, just as the Columns property appears in it.

    Then, I add a Windows Forms item to my application and drag&drop one MyUC control from the toolbox into it.  Then I click the MyUC and go to its properties page to modify the Columns properties just as with an ordinary DataGridView.  The property is there but when clicking on its "..." button to open de Edit Columns Dialog I get the mentioned error.  Something like this:

    "Unable to cast object of type 'WindowsApplication3.myUC" to type "System.Windows.Forms.DataGridView".

    I tried what you have mentioned but it doesn't work. I still get this error.

    I really really need the Columns property to be accesible in Desing Time this way.  I don't know how to work this out.

    As I said, I get this error with an almost blank project.  Just add a User Control Item, put a DataGridView into it. Ade the code above to make the Columns property visible and then try to access the property in the Property page. 

    Thank you so much in advance.

    Fernando.

     PD: I'm using the shipped VS.NET 2005.

     


  • Rahul Shende

  • Kris Phillips

    I had the "unable to cast from x to x" error when the designer tried to load my main form which contained a custom control. If I simply put the cast within a try-catch block, everything worked fine. Note, the code never hit the catch block, so i don't know why that hack works, but it has held up so far.

    -Tony

    tony_held@yahoo.com



  • JohnLR

    Hello,

    The problem persists. Is this a bug How to reproduce
    - Create C# class library project
    - Add usercontrol : MyGridControl
    - Add a DataGridView control to the user control.
    - Add a public property "ABC" to the user control,
    public DataGridViewColumnCollection ABC
    {
    get { return datagridView1.Columns;}
    }
    - Add a public property "XYZ" to the user control,
    public DataGridView XYZ
    {
    get { return datagridView1;}
    }

    - In another (winforms) project, add the previous assembly to the toolbox
    - Drag the "MyGridControl" component to the Winform
    - In the designer, try to edit the ABC property => errors
    - In the designer, try to edit XYZ.Columns property => NullReferenceException.

    Please advice...



  • Michael G. Emmons

    public DataGridViewColumnCollection Columns

    It's a read-only property by the way you defined your property.

  • CHiLLD

    The story is not new -- this is the same behaviour as in 2002/2003. An additional source of problems is the "Local Copy" property of references: Even if the same dll is copied and then loaded from a different location, its types differ from those of the original dll.

    Just make a test: At the point where the types are found to be different compare _all_ their attributes (after all types are just objects and they can differ only if their attributes differ). Print them out. You will see exactly the difference, that matters.

    HTH,

    D.Raiko

     


  • Unable to cast object of type 'X' to type 'X'