Cannot Place User Control on Form

Question

I've created a C# WinForms application using VS2010. I'm new to creating user controls so I created a new user control (as part of the same project).

When I rebuild the project, the new control appears in the toolbox. And when I drag the control from the toolbox onto a form, I get the following error.

Failed to load toolbox item 'TagGroup'. It will be removed from the toolbox.

This happened the only other time I created a user control as well. I've searched the web but most answers I found seemed related to having the control in a separate assembly. (Note that I found plenty of questions with the same problem I'm having.)

Can anyone suggest where I should look next?

Agglutination

It would help to show some code. Show us the class declaration and the constructor at the least, although the whole class would be most helpful. – Mccabe

Isolate this. Does it happen when a plain UserControl with nothing in it => VS problem. No problem => watch out for code that runs at design time. – Dhammapada

Do you do anything in the constructor? IIRC, the designer will call it so it's best not to have anything that does any external calls in it. – Plier

@Mathew: There is no code! I explained what I did. There's nothing else. – Agglutination

@Hans: It's not related to code but just to remove all doubt, I created another user control and did nothing but rebuild the project. Exact same result. As mentioned, this has happened before. It's never worked for me. – Agglutination

@Austin: I don't do anything. There is an issue siting the control. – Agglutination

Answer 1

I finally figured this one out.

The project I'm working with uses two class-library assemblies. Although these have nothing to do with the control I'm discussing, I looked and saw both libraries have Platform Target in the Properties|Build tab set to "Any CPU".

On the other hand, my application had this setting set to "x64". By changing my application's setting to "Any CPU", I can now place my user controls onto my forms.

Go figure...

Agglutination

Totally odd how this particular symptom stems from that problem, but it worked for me too! Thanks. +1 – Wallachia

Note the same thing will happen if the .NET framework in the class library with the control is higher than your project. It makes sense for this to not be allowed, but the IDE should just say 'hey, this control is in a .NET 4.5.1 dll - upgrade your project from .NET 4.5' instead of silently failing. – Petronius

Answer 2

My application need to be 64-bit. In order to use custom user controls in the designer I just added a new project to my solution. This new project use the "AnyCPU" setting and contains all my user controls.

My solution contains the following projects:

• MyApp which is my main project (Windows Form Application) compiled in 64-bit and referencing my second project
• MyApp.UI.UserControls (class library) is compiled for "Any CPU" and contains all my user controls

Works like a charm and it's clean

---

By the way, there is a Microsoft support article about that issue.

• Action: You attempt to use a 64-bit component within the Microsoft Visual Studio Integrated Development Environment (IDE).
• Error cause: This behavior is by design. Visual Studio is a 32-bit process, and therefore can only execute 32-bit modules. While Visual Studio allows you to add a reference to a 64-bit assembly, it cannot actually JIT compile it to 64-bit and execute it in process.
• Resolution:
  1. Rebuild the assembly using the "AnyCPU" setting. This would allow the component to run within a 32-bit process (such as Visual Studio), or in a 64-bit process.
  2. Add the assembly as a reference and load the control dynamically at run-time. Although you still would be unable to use the control within any designer inside Visual Studio, you can still write the code needed to instantiate the control and set it's properties accordingly.

Source: http://support.microsoft.com/kb/963017

Rosie

Sadly enough my app and all my controls has to be x64 because they are using native types :( They really should make VS x64! – Winkler

Yess!!! I had no other option but to be x64 with my AutoCAD builds. The previous solutions didn't work! Furthermore, prior to this crashing and burning, if I had to make a modification on that given form, I had to go into the designer and tweak it ... EVERY TIME. This worked flawlessly! YES! – Keratoid

Just as a warning, this x64 / user control issue can be caused by something as simple as a field on the user control set to a constant loaded from a 64 bit assembly; it's best to not use anything from an x64 dll on a UserControl. – Banwell

Answer 3

I had this problem too, but the answer couldn't fit for me. My project has some issues it can only target x86 and x64 separately. In other words, I can't use AnyCPU configuration (that's because I reference different libraries for each configuration, since those libraries are not fit to AnyCPU).

The solution I came up with was: when I need to use the form designer, I change the setting to x86. Do the job, then set back to x64 and test. The problem occurs only with the designer, but the solution builds and runs fine.

Senhauser

Answer 4

I had this problem in VS2015 and the solution turned out to be simple.

I had created a user control by cutting and pasting a few existing controls from a form (with the aim of grouping them into the custom control). The custom control was okay (no compile errors), however the removal of the controls from the existing form meant that the application wouldn't compile. Of course not being able to add the new control meant that I couldn't update the code referencing the previous controls with code referencing the custom control.

All I did was hack and slash (commenting-out, creating temporary controls, etc.) so that the entire application would compile. After it compiled I found that I could drag the custom control onto the form (without the error that prompted this question). I then had to unhack and unslash so that the code properly referenced the new custom control.

Radborne

Worked for me, recompiled with x86 configuration, now user controls can be added. – Lashing

This! If you got a build error when dropping it for first time, the problem will stay there until you do a successful clean rebuild. – Amylose

Answer 5

Same problem here. I am guessing it is related to the fact that the VS2010 installed on x64 OS is still a 32bit program in the heart.

An alternative solution one might want to try is simply open TheFormThisUserControlIsSupposedToBeAddedTo.Designer.cs and use code to add the user control. Basically, you are doing the dirty work that the Designer is supposed to do.

It is not as difficult as it sounds, esp. considering that there are probably plenty of sample code in that file already (e.g. the buttons you added using Designer). The only difficult part is figuring out the right coordinates in the form to place the control.

The end result is that you can not see the user control in Desinger, but they are added on debugging/running.

Corpsman

I don't think Visual Studio's "bitness" is related to this. VS can still produce 64-bit executables. I think it more related to the fact that I was taking components from different projects, which apparently were using different settings. – Agglutination

Answer 6

I also experienced this problem but the cause was different. In my case a component (form) constructor or Load event invoked a method elsewhere that used reflection to find all classes that implemented a certain interface.

While that works fine at runtime, it generated the above mentioned exception at Design Time. (Type Initialization exception with a Type Load Exception as inner exception).

Gruver

Answer 7

An hour of confused, weary troubleshooting at 3:36AM is again easily resolved with a fresh mind the next day!
I fixed a simple spelling mistake in the control's filename, so it now matched the UserControl name, cleaned and re-built and Bobs your weird uncle's cat. :]

Snowslide

Answer 8

GO project property then 'Build' tab and check 'Target Platform' was 'AnyCPU'.

Baku