56

I've searched StackOverflow and found similar problems when I try and open a form that references a UserControl in a different project.

I get the

To prevent possible data loss before loading the designer, the following errors must be resolved:

message relating to the following two errors:

Could not find type 'MyNamespace.CommonUi.InformationBox'. 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.

AND

The variable 'InformationBox1' is either undeclared or was never assigned.

InformationBox1 is an instance of the user control InformationBox that is on the form in the designer - it's just referenced as;

Friend WithEvents InformationBox1 As MyNamespace.CommonUi.InformationBox

The MyNamespace.CommonUi project builds successfully.

I get intellisense in the project so I'm reasonably confident that it's being referenced correctly.

So far, the same as other people have had:

This is a project that's been migrated from .NET2/x86 in VS2005 to .NET4/x64 in VS2012.

Now when the solution is running under 64 bit it doesn't work and I get this designer error. However, if I switch it to 32 bit (well technically AnyCPU) I can open the designer just fine.

I've read through the other suggestions in similar threads but they don't see to provide any solution (I've even gone as far as the "move it left & right to get it to rebuild" option)

J. Scott Elblein
  • 4,013
  • 15
  • 58
  • 94
  • 13
    Whenever I get something like this, I go through these steps, if you have not done this, maybe it will help: 1-Close all forms in the IDE, 2-Clean the solution, 3-Rebuild the solution. – Steve Sep 25 '13 at 19:07
  • Nope, tried that. Several times. There's nothing wrong with the .designer.vb code as far as I can tell and the rebuilding doesn't change any of it (tried a compare before & after) – Andy Macnaughton-Jones Sep 26 '13 at 10:17
  • Clearing and Rebuilding my project worked for me! – M. Fawad Surosh Feb 13 '19 at 17:15

18 Answers18

80

QUICK FIX: I believe the issue is that Visual Studio is natively 32bit and one cannot do GUI editing for some components (E.g. ListView) in 64bit. E.g. on forms where you have ListView, you need to change the solution to 32bit to edit the GUI.

So the answer in short is, when you're facing this issue:

  1. Change the solution to 32bit or AnyCPU
  2. Clean and rebuild the solution/project
  3. Open the GUI for editing
  4. Save, change the solution back to 64bit
  5. Clean and rebuild
  6. Run in 64bit

Unfortunately Visual Studio doesn't come in 64bit as yet, hence all controls need to be designed in 32bit mode (or AnyCPU mode).

See this question for reference. VS 2010 designer error 'Could not find type XYZ' in Windows7. Works fine in XP

UPDATED FIX: I finally found a proper fix for the problem to load and edit my custom/32bit controls in a 64bit environment using the VS GUI design editor. Note that this works up to Visual Studio 2019, the architecture of the designed editor has changed in VS 2022 so I'm not sure if this will still work there.

Essentially there are a couple of things happening with the Visual Studio Design editor which prevent you from editing custom/32bit controls in a 64bit design environment.

  1. You'll notice that your custom/32bit control doesn't show up in the designer Toolbox when you load any form while in a 64bit target environment. This is part of the root cause of the issue; because your control doesn't show up in the toolbox, when VS tries to load a form which is using that control (or a class which extends that control), it throws the error, Could not find type 'xxx.xxx.xxx' (in the toolbox, that's the part it doesn't specify)
  2. One of the reasons that the controls don't show up in the toolbox is because Visual Studio does NOT load custom controls from the current project into the toolbox (either automatically or even if you manually try to force it). So if your custom 32bit control is in the current project, the toolbox won't register it and consequently the editor will be unable to load the form. See reference

The solution here is to create a new project within the same solution and move your custom/32bit controls into a new namespace within that new project. Now Visual Studio will be able to see and load your controls into the Toolbox. This should happen automatically, optionally you can add the attribute [ToolboxBitmapAttribute(true)] to your public class definition on your custom control. Once your custom control shows up in the Toolbox then the Visual Studio design editor should have no problems finding the assembly and loading your form and allowing you to edit your custom 32bit control in the 64bit design environment.

rboy
  • 2,018
  • 1
  • 23
  • 35
17

I had this problem. It happened only in one form designer view, despite it was able to compile, start, show this form in runtime and show other forms / controls in designer mode.

These steps didn't help:

  • Clean & rebuild
  • Restart studio
  • Deleting all bin and obj directories
  • Removing and adding references
  • Denial, anger, bargaining, depression, acceptance

Solution for my case:

  1. Rename a type, which is missing (for example InformationBox => InformationBox2)
  2. Refresh designer (WOW, it works!)
  3. Rename the type to its initial name
roufamatic
  • 18,187
  • 7
  • 57
  • 86
Anton
  • 10,890
  • 8
  • 45
  • 54
  • 1
    Alas, the trick with renaming didn't work. I assume that "refresh designer" means close and open the designer window? – Harald Coppoolse Oct 14 '14 at 06:57
  • I don't have any UI projects available now, but as far as I recall there was "Refresh" item in context menu and/or press [F5]. – Anton Oct 14 '14 at 10:40
  • 1
    I was having this same issue in a windows form that contained a wpf textbox. Removing & adding the reference, then rebuilding the project solved my problem. – ShawnOrr Dec 05 '14 at 16:48
11

Change Any CPU to X86. Your control is 32bit trying to run on 64bit machine and cannot find the 64bit version of the control.

jcwrequests
  • 1,132
  • 1
  • 7
  • 13
  • 1
    My controls *should* all be 64bit but I think there must be *something* within the control that's forcing it to run as 32bit so I get a mismatch at design time. If I set my main application to run as 64bit only but switch the offending project to AnyCPU it works and I can view / edit the form in the Main application that references this other project (now anycpu). The only thing I can think of is that it's to do with embedded resources - there's a picture of a lightbulb on the usercontrol. Failing that, something must be encouraging it to not run as 64bit. Further digging required... – Andy Macnaughton-Jones Sep 26 '13 at 10:20
5

I had this same error recently with VB.Net in Visual Studio 2013 working with a custom WinForm User Control that itself was inheriting a custom user control base class in the same project, and took some doing to find out what the true cause was, which in my case was that neither base class nor the child class had a no-parameter constructor (Because that's not a valid scenario in this case).
To fix it, I added the missing constructor but left it empty (throwing a NotImplementedException caused another issue that prevented it from displaying). It's not pretty, but it works.

In order to see the underlying error through the one listed in this threads question, I had to do the following:

  1. Clean the entire solution
  2. Close Visual Studio
  3. Re-open Visual Studio
  4. Re-open the solution
  5. Build the solution by right-clicking it in Solution Explorer (Not Rebuild, that didn't work)
  6. View the User Control in Designer mode and the actual error shows up now

After adding the constructor, I had to take the above steps again to make it work properly.

Taegost
  • 1,208
  • 1
  • 17
  • 26
  • 1
    Wow. I had this issue, briefly fixed it by moving my user controls to a DLL, then it came back and I couldn't figure it out. Took these steps and then it fixed again. I'm mad at the developers of Designer, but greatly appreciate the response. – T.E.D. Aug 11 '23 at 19:38
4

Well here's some further information: the-designer-could-not-be-shown-with-platform-x64

And the resolution to run in AnyCPU, when you are trying to access the designer is a work-around and for our purposes will suffice.

Gandhi
  • 11,875
  • 4
  • 39
  • 63
  • This one worked for me: Although my program really needs to run in 64 bit, If I use the designer use "Any CPU" and switch off "prefer 32-bit". Had to close and reopen the solution though. Not sure if this is more then necessary – Harald Coppoolse Oct 14 '14 at 07:05
3

I changed a large solution with multiple projects to target x64 platform from AnyCPU. Tried opening the designer of one of the solution forms which referenced a control in one of the other projects and got the same error message as the OP. Opened the project that contained the control and saw it still targeted AnyCPU. Tried for an hour to get it to save as x64 with no luck. I eventually opened the csproj file in notepad, replaced AnyCPU with x64 and it all started working. Hopefully this helps someone else as frustrated as I was.

OldDog
  • 334
  • 4
  • 12
3

Just save your project, close it then reopen it again.

Shamal Sabah
  • 229
  • 2
  • 7
3

Recently I encountered the same problem with one of my custom controls (C#) in VS 2015.

I solved it by cleaning the solution (Build -> Clean Solution) and then rebuild the whole solution. Everything came back smoothly.

My project settings' platform target is already set to "Any CPU" and checkbox ticked for "Prefer 32-bit". Not sure why it happened though.

TLT
  • 45
  • 8
  • I swear i'm not crazy, i did try this and a bunch of other things, then came here and read this, tried it again, and now everything works fine again. – siggi_pop Mar 03 '19 at 19:28
3

I was on VS 2022 RC and I've tried everything possible listed here and in some other websites.

The only solution for me was to go back to VS 2019

andycted
  • 812
  • 6
  • 13
  • Yeah, Visual Studio makes this almost impossible to debug. I found [this link](https://social.msdn.microsoft.com/Forums/windows/en-US/3398a2da-a524-4c41-b762-8917d5c80b3d/inherited-winforms-control-doesnt-load-when-an-object-is-declared-from-another-assembly-in-the?forum=winformsdesigner) to be helpful and I maybe even had success rebooting my computer? But I care more about staying on 17.x. – binki May 06 '22 at 15:36
2

While there is a lot of reference to 32-bit etc, the steps that worked for me were :

  • Convert all references to the user control, say, 'InformationBox1 as InformationBox' into a fully qualified class reference such as 'MyNamespace.CommonUi.InformationBox', in all the designer.vb files.

    • Clean Solution

    • Rebuild Solution.

In my case, it was a migration project from VB6 to VS2008 and both the environments were 32-bit, and on the same machine, there was no sign of 64-bit involved.

Whirl Mind
  • 884
  • 1
  • 9
  • 18
1

This happens if you compiling for x64 because the Visual Studio designer cannot load x64 assemblies. The designer of Visual Studio can only load x86 assemblies because it's an 32 bit only process!

  1. You can either change to AnyCPU
  2. build for x86 then the Visual Studio designer is able to load your assemblies to show your controls at design time
  3. Don't design with x64 assemblies, build them only via batch or in Visual Studio and then switch back to AnyCPU or x86
Martin.Martinsson
  • 1,894
  • 21
  • 25
1

What i think that you should keep you controls UI in separate project from your 64 bit project and run it with settings any CPU. this will help to not clean and rebuild it with 64 version.

1

You can change to any CPU:

Project => properties => Build

Platform target: Change to Any CPU

Clean and Rebuild, Reopen the Design file.

J. Scott Elblein
  • 4,013
  • 15
  • 58
  • 94
AAli
  • 49
  • 3
1

I have the same problem and I solved it by:

  1. Going to properties of your solution in visual studio.
  2. Chaging 'Platform' to 'AnyCPU'.
  3. Rebuilding your solution.
  4. Restarting visual studio.
double-beep
  • 5,031
  • 17
  • 33
  • 41
AMMAR ELHAMDO
  • 519
  • 4
  • 12
1

I know this is a really old question/issue. However, I thought some should know that the latest VS 2022 (Preview) is now native 64-bit and can handle custom objects in a x64 designer mode when building a 64-bit application.

https://devblogs.microsoft.com/visualstudio/visual-studio-2022/#:~:text=Visual%20Studio%202022%20is%2064,without%20running%20out%20of%20memory.

Gavin S.
  • 31
  • 5
  • 1
    Please add further details to expand on your answer, such as working code or documentation citations. – Community Sep 08 '21 at 22:37
  • https://devblogs.microsoft.com/visualstudio/visual-studio-2022/#:~:text=Visual%20Studio%202022%20is%2064,without%20running%20out%20of%20memory. – Gavin S. Apr 26 '22 at 19:11
0

Nothing on here worked for me. Then, I just unloaded the project which contained the problematic design page. Reloaded it, cleaned solution and rebuilt solution. The designer came back like magic.

sanrnsam7
  • 131
  • 1
  • 2
  • 11
0

In a certain solution (i.e., .sln) I have, something seems to confuse Designer. I am using visualstudio-17.0.4. I get the following error:

Could not find type ‘System.Windows.Forms.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.

Note that the type in question is System.Windows.Forms.UserControl, a framework provided type not a type from my development project. I am referencing System.Windows.Forms and targeting .net-4.6 and AnyCPU. The project builds fine without any errors and even IntelliSense knows about the type. Designer might be trying to load dependencies in a different way than IntelliSense does. But it does not give me enough information to figure out why it is failing.

All of the normal resolutions did not work for me. However, I noticed that Designer would load sometimes. After further experimentation, I found that Designer would load if I tried to open it within a project which had no open editor windows when I opened the solution as long as I attempted to open Designer in a different project first. Note that simply unloading and reloading a project or closing all windows without restarting visualstudio is not enough. Follow these steps strictly if you are experiencing the same issue as me.

  1. Open your Solution in Visual Studio.
  2. Right-click on a project containing winforms Designer files and select Unload Project (L) OR close all windows using the menu action Window / Close All Tabs (M-w l).
  3. Exit Visual Studio.
  4. Open your Solution in Visual Studio.
  5. Try opening Designer on a file in a different project. It should fail to load.
  6. If you had unloaded the project earlier, right-click on the unloaded project and select Reload Project (L).
  7. Right-click on the project and select Rebuild.
  8. If you have run Rebuild on multiple projects, be sure to later select all projects and select Build.
  9. Double click (enter) on a winforms Designer file in that project. The Designer should successfully load.

If you need to edit winforms Designer files in multiple projects, you may need to unload and then load/build multiple projects instead of the single project.

This solution is temporary. If you close Visual Studio without unloading your projects container winforms Designer files first, you will no longer be able to open those winforms Designer files until you follow the procedure again.

If you do not use 100% DPI, you may want to replace steps 3 and 4 with restarting Visual Studio in 100% DPI mode. Note that these steps only work if you did not yet open any winforms Designer files (the 100% prompt only shows up for the first winforms Designer file you open):

  1. In a different project, double click on a winforms Designer file. It may fail to load, but if this is the first winforms Designer file you opened in this Visual Studio session, you should get a prompt:

    Scaling on your main display is set to 175%. Restart Visual Studio with 100% scaling Help me decide.

  2. Choose the “Restart Visual Studio with 100% scaling” option.

See also: an explanation of ProjectAssemblies (archive). When experimenting, I found that VisualStudio loaded and cached an old version of assemblies, so if you are updating the controls used by your designable control, you cannot escape from needing to restart VisualStudio sometimes.

binki
  • 7,754
  • 5
  • 64
  • 110
0

In Visual Studio 2022 17.5.2 I did the following to fix it:

  1. My custom control is in a separate project
  2. Set my debug to x86 for visual studio (drop down in top left next to debug)
  3. Clean and rebuild the project with the error (or both to be safe)
  4. When you release you can set it back to x64
Jeff
  • 155
  • 1
  • 10