19

I'm getting the following error

Could not find type 'My.Special.UserControl'. Please make sure that the assembly that contains this type is referenced. If this type is a part of your development project, make sure that the project has been successfully built using settings for your current platform or Any CPU.

But what doesn't make any sense is that My.Special.UserControl is in the same assembly as the form. What's more, if I view code on the Designer.cs file, There are references to My.Special.UserControl that seem to be fine. The assembly builds fine, and runs fine as well. It's the just the designer that's having issues.

As such we have to do all our design work by making adjustments to the Designer.cs file by hand. How can I make the designer work again?

Breeze
  • 2,010
  • 2
  • 32
  • 43
Jonathan Beerhalter
  • 7,229
  • 16
  • 68
  • 78
  • The only way I was able to go around this bug, is to restart VS. It takes a lot, but it is still better than changing Designer.cs. – Vale Apr 05 '13 at 13:36
  • What's the inheritance or My.Special.UserControl, is it direct from UserControl or does it have a few other bits inbetween. What version of Visual Studio are you using? – James Apr 05 '13 at 15:52
  • @Jonathan were you able to fix the error? – Th 00 mÄ s Apr 12 '13 at 11:26
  • 4
    Switched the target to x86 and now I can open the designer. Something in my control must not be x64 compatible. Going through the list of controls, I don't see anything that jumps out at me. It's weird that the control can be built x64 when I click run, but not for the designer. – Jonathan Beerhalter Apr 19 '13 at 14:54
  • I have upvoted you back to 0. I see nothing wrong in this question. – Joel Oct 01 '13 at 16:22
  • I thought surely they'd have this fixed by now. How can the designer still not support 64-bit in 2020? Rebuilding for 32-bit worked for me on one form. But I have another form that has a 3rd party control for which I have to change the dll reference to a 32-bit version of the control to get into the designer and back to 64-bit when building for production. – dwilliss Oct 06 '20 at 13:51

12 Answers12

15

The following procedure has worked for me:

  1. Delete the /bin and /obj folders in your source code directory.
  2. Restart VS (be sure the offending Form Designer is closed)
  3. Compile
  4. Open the Form in Designer again. The problem should be resolved.

I'm sure deleting both /bin and /obj are not necessary, but I haven't been able to reproduce the error and come to a more specific solution. (My projects are typically small enough that re-compiling the whole thing is no big deal.)

Usually, this error seems to occur after refactoring / renaming objects of the offending class. So my guess is that there is a VS bug that doesn't recompile the appropriate object file after a User Control or Custom Control is refactored.

CarlC
  • 151
  • 1
  • 2
  • 1
    This is exactly what happened to me due to renaming of namespace and project. However, these steps didn't appear to work for me. I'm investigating few other alternatives and will post working answer when I'm done. – redditmerc Dec 14 '16 at 05:11
  • Restart worked for me. The oldest trick in the book! – SZT Jul 19 '20 at 17:11
13

Change the project type temporarily to x86, compile and open the Designer. Visual Studio is a 32 bit application.

Hartmut Schreiber
  • 131
  • 1
  • 2
  • Thank you so much! This was the answer for me. – szMuzzyA Jun 03 '21 at 00:01
  • Spot on! All the other solutions I've read on this get very technical for what is a very simple cause. For future development this is a real bind. I'm targeting x64 only, so having to swap each time is a pain. This has to be sorted as more and more target x64 only. – VariableSquid Feb 27 '22 at 15:26
  • 1
    The same happened to me for Visual Studio 2022 (that is a 64 bit process now): change the project configuration temporarily to x64, compile and reopen the Designer. – Ste Apr 04 '22 at 11:30
  • My last comment is valid only for .NET Framework projects. See [link](https://developercommunity.visualstudio.com/t/WinForms-NET-Framework-Projects-cant-d/1601210) for details. – Ste Apr 04 '22 at 11:46
3

There is propably an exception happening in the Load or Initialize Part of your Form / UserControl. Can you try to comment out any code there and retry opening in designer?

You can use another instance of Visual Studio to attach a debugger to your Visual Studio instance not letting you open the Form. Once an exception occurs you will be able to pinpoint the location where something goes wrong.

Th 00 mÄ s
  • 3,776
  • 1
  • 27
  • 46
2

I had similar problem when shifted from VS 2017 community edition to professional.

  1. Close VS
  2. Go to Project folder
  3. Delete .vs folder. Back up if you need.
  4. Start VS

This should solve the problem

udaya kumar
  • 169
  • 8
  • 1
    It ended up being the `.suo` file in a `.vs` sub-directory for me. Even without changing VS editions. Deleting `bin` and `obj` directories didn't help. – Nathan Jan 04 '22 at 21:36
2

I have experienced the exact same problem. I am fairly certain that it is connected to the platform target x64. Here is a related post mentioning it as a bug in Visual Studio:

https://stackoverflow.com/a/11582828/7665665

How I deal with it: Although my solution is actually only x64, I have created another platform target x86 for the projects just to be able to use the designer. Now I switch the target to x86 in order to see my controls in VS Designer. For everything else, I switch back to x64.

user74696c
  • 324
  • 4
  • 12
1

I had the same problem with a user control which was derived from the standard .NET control within my form.cs. Nothing of the above worked for me (my solution is compiled as x64 because of other unmanaged components which only support x64).

I finally ended up with creating a separate project "Utils" and moving the offending derived controls to this project. This worked like a charm !

Helmut
  • 117
  • 1
  • 2
1

In my case I just unload project and reload again

rizkidzulkarnain
  • 61
  • 1
  • 12
1

Switching the project target to x86 was the only possible solution for me

oo_dev
  • 777
  • 7
  • 20
  • 2
    It is only a side effect of doing that. Not a reasonable solution. And it unnecessarily changes the target architecture which is undesirable in most cases. – Kissaki Jan 20 '20 at 09:12
0

This happened to me today. Cleaning, Rebuilding, restarting Vs and even rebooting did not help. Everything ran as expected, the only thing that would not work was the designer in VS.

In my case, since nothing lese worked, I went to designer file, removed the faulty control and then added a new one. Renamed, re-assigned event listeners and it worked.

Designer now works, but if this must be some kind of VS bug, I don't know.

This is not the answer I'd like to read when coming to SO, but I'll post it in case it helps anyone later.

Joel
  • 7,401
  • 4
  • 52
  • 58
0

For me, I deleted the .resx file for the form, and it built and showed up in the designer, no problem. Go figure....

Donald.Record
  • 301
  • 3
  • 7
0

I had a similar experience when I sub-classed DataGridView. The following procedure has worked for me:

  1. Close the Form Designer tab
  2. Close VS (2015)
  3. Delete the /bin and /obj folders of the project
  4. Restart VS
  5. Rebuild the solution

I don't know which steps could be skipped as I have not taken the time to refine the process.

alberto
  • 11
  • 1
  • 2
  • 4
0

On my project, it only worked if I made the custom user control in a separate project in the solution:

  1. Add new project "Class Library (.NET Framework)"
  2. Add references to System.Windows.Forms & System.Drawing
  3. Add the source of the new user control in the new project
  4. Build the solution
  5. Open the designer
  6. Drag the new user control in the form

In my case the designer automatically added a reference to the new project when I dragged the custom user control in my form.

Hope this help others who stumble upon this question.

Pieter
  • 124
  • 4