Could not find type 'xxx.xxx.xxx'. Please make sure that the assembly

.Netvb.netVisual Studio-2012Visual Studio-Designer

.Net Problem Overview


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)

.Net Solutions


Solution 1 - .Net

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. https://stackoverflow.com/questions/12878169/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.

Solution 2 - .Net

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

Solution 3 - .Net

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

Solution 4 - .Net

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.

Solution 5 - .Net

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.

Solution 6 - .Net

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.

Solution 7 - .Net

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.

Solution 8 - .Net

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.

Solution 9 - .Net

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

Solution 10 - .Net

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

Solution 11 - .Net

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.

Solution 12 - .Net

You can change to any CPU:

Project => properties => Build

Platform target: Change to Any CPU

Clean and Rebuild, Reopen the Design file.

Solution 13 - .Net

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.

Solution 14 - .Net

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.

Solution 15 - .Net

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.

Solution 16 - .Net

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.

Solution 17 - .Net

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

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionAndy Macnaughton-JonesView Question on Stackoverflow
Solution 1 - .NetrboyView Answer on Stackoverflow
Solution 2 - .NetAntonView Answer on Stackoverflow
Solution 3 - .NetjcwrequestsView Answer on Stackoverflow
Solution 4 - .NetTaegostView Answer on Stackoverflow
Solution 5 - .NetOldDogView Answer on Stackoverflow
Solution 6 - .NetTLTView Answer on Stackoverflow
Solution 7 - .NetAndy Macnaughton-JonesView Answer on Stackoverflow
Solution 8 - .NetWhirl MindView Answer on Stackoverflow
Solution 9 - .NetShamal SabahView Answer on Stackoverflow
Solution 10 - .NetMartin.MartinssonView Answer on Stackoverflow
Solution 11 - .NetMuhammad SaqibView Answer on Stackoverflow
Solution 12 - .NetAAliView Answer on Stackoverflow
Solution 13 - .NetAMMAR ELHAMDOView Answer on Stackoverflow
Solution 14 - .NetGavin SchmidtView Answer on Stackoverflow
Solution 15 - .NetsanrnsView Answer on Stackoverflow
Solution 16 - .NetbinkiView Answer on Stackoverflow
Solution 17 - .NetandyctedView Answer on Stackoverflow