Visual Studio designer in x64 doesn't work

P

6

44

In Visual Studio 2010 64bit I can't design my forms.
I keep getting this warning (and error):

Warning 18  
The designer could not be shown for this file because none of the classes within it can be designed.  The designer inspected the following classes in the file: 
MainForm --- The base class 'Blah' could not be loaded.  Ensure the assembly has been referenced and that all projects have been built.

This only happens with when I compile for x64 ... in x86 the designer works well.

Just want to be clear that I NEED the project to work on x64 because a lot of the project's components are compiled in x64 and won't work if the forms are in x86.

Has anyone else encountered this and found a solution ?

Philter answered 21/3, 2011 at 14:21 Comment(6)

Sorry if this is a dumb question, but are you running Visual Studio on a 64-bit O/S? Assuming the answer is "yes", do you have any dependencies (3rd-party libraries) that are not 64-bit capable? Or, maybe a control that wrappers a native dll (in which case, you will need a 64-bit version of the native dll) – Faunus 21/3, 2011 at 14:26

It's a 64bit OS, there are dependencies that are 64-bit. All components are 64-bit (verified). Only thing I can think of that isn't 64-bit is maybe something internal to VS2010. @SLaks - funny :) ... – Philter 21/3, 2011 at 14:50

Attach a debugger to VS and see what the exception is. – Jobbery 21/3, 2011 at 14:55

Currently fighting with this 64-bit problem in a WinForms project in VS2015. We removed AnyCPU. Do you know of any other solutions? – Galahad 10/3, 2016 at 11:18

I have hte same issue. MOving to AnyCPU produces an enormous list of errors. – Tortola 7/9, 2019 at 9:21

Finally in VS2022 this is no problem anymore (thanks to its 64 bit design) – Bonney 3/11, 2021 at 12:7

F

52

I can repro your problem by creating a WPF application with a user control (put the user control on the wpf app, and build x64).

Here's my guess as to what's going on:

Visual Studio is a 32-bit application and the WPF designer has to load referenced assemblies (you see that behavior all of the time when you use user controls, where you have to rebuild to get the designer to update). Windows does not support a sharing between 32-bit and 64-bit - you have to have either a 32 bit app or a 64-bit app, period, no sharing.

Since the WPF designer is 32-bit, the assemblies need to be 32 bit.

Here is a possible solution:

Design your app with the "Any CPU" option. This will cause your code to JIT to 32-bit on 32-bit platforms and 64-bit on 64-bit platforms.

The designer will work in "any cpu" because the assemblies get jitted to 32-bit.
When you need to debug 64-bit specifically, switch your build configuration to 64-bit (knowing that you must switch back to "32-bit or "any cpu" do form design)

Faunus answered 21/3, 2011 at 15:33 Comment(6)

@Hans Passant: I agree, it's the WPF Designer in VS, and it's by design. It's very easy to repro - give it a shot: Start a new WPF project in VS (leave all settings alone for now). Add a new UserControl (you can just leave it blank). Add the user control to your main form. Build (all fine so far). Now create an x64 build profile and rebuild solution (boom). Switch back to x86 and rebuild (good), lather, rinse repeat. – Faunus 21/3, 2011 at 19:24

For what it's worth, I can repro using the same steps with the Winform designer as well. It happens because the designer is a 32-bit app, and we hare handing it a 64-bit only assembly to load (because the user control is in our compiled output). "Any CPU" is the best answer. – Faunus 21/3, 2011 at 19:29

Currently fighting with this 64-bit problem in a WinForms project in VS2015. We removed AnyCPU. Do you know of any other solutions? – Galahad 10/3, 2016 at 12:17

@Galahad The Visual Studio designer is going to need 32-bit assemblies. Even if you don't release or Q/A your software with AnyCPU, create either an AnyCPU or x86 profile for development. If you are requiring x64 builds for release, you can always have your build server use the x64 profile for release and Q/A builds. – Faunus 10/3, 2016 at 16:8

Spent all morning chasing this one... Glad to see I came to the same conclusion. So tired of WPF being a 3rd class citizen in Visual Studio. – Aam 21/7, 2016 at 19:56

This is the correct answer. 2018 and we're still fighting with 32-bit problems from the previous century. C'mon MS: If it's that hard to build VS itself in x64, there's a lot of egg on your face – Harvester 3/7, 2018 at 21:27

M

10

This is a bug in VS 2008, 2010, 2013, 2015, 2017, and 2019.

Here's the bug report:

http://connect.microsoft.com/VisualStudio/feedback/details/646328/the-designer-could-not-be-shown-with-platform-x64

It seems there is no fix for this yet.

Mccartan answered 20/7, 2012 at 15:53 Comment(5)

I dont think it will be fix. It also cant use in UWP. – Younker 23/5, 2017 at 4:5

The connect link is now dead – Anti 18/6, 2018 at 21:2

I can't believe this is still a problem in 2021. – Slob 29/3, 2021 at 5:48

@Slob Welcome to Microsoft :) – Witness 13/5, 2021 at 5:38

winform can't use x64 to do user control design. – Acquit 4/7, 2022 at 7:20

L

9

The proposed solution from Microsoft is to move the base classes to a separate assembly, compiled using AnyCPU or x86 (if your actual project must be x64).

Unfortunately this applies to all base classes: if your inheritance is FormC : FormB : FormA, then both FormA and FormB must be in an (external) 32bit assembly, if you want to edit FormC in the designer.

Of course, this also applies to UserControls! I wish I had known this before our team decided to move to 64bit - a notice when changing the compile options would have been really nice, Microsoft...

Lenes answered 27/8, 2015 at 18:8 Comment(1)

microsoft seems to have stopped maintaining the winform now. – Acquit 4/7, 2022 at 7:21

Y

3

It is a limitation for Visual Studio since it does not have an x64 version.

See this support page.

Yogi answered 29/11, 2013 at 3:28 Comment(0)

T

1

I had similar issues when building an old .Net project using Visual Studio Enterprise 64 Bit. ViRuSTriNiTy's solution worked for me (I changed the platform from x86 to 'Any CPU'. But it is odd that this is exactly the opposite of Julio Nobre's solution (Workaround 1)

Trivalent answered 9/11, 2022 at 0:53 Comment(0)

H

0

It seems this a Visual Studio 2022 bug that affects only inherited forms whenever their base classes are stored on x86 dll assemblies.

As of today, using Microsoft Visual Studio Professional 2022 (64-bit) - Version 17.3.3, C# Form Designer is unable to design/load previous forms.

Fortunately there are several workarounds.

Workaround 1 (VS2022)

On Configuration Manager, locate the project that contains your form base class (the form class which your offending form as inherited from) and change Platform from Any CPU to x86, save and rebuild it. Your target form should load ok.

Workaround 2 (VS2022)

One guy, Frank Wenzl, figured out that changing Output type from Class Library (.dll) to Windows Application (.exe) on the project that contains the form base class and rebuilding it, allow Windows Form Designer to load inherited forms normally.

Workaround 3 (VS2019 or prior versions)

Using Microsoft Visual Studio Professional 2019 (32 bit, i guess) - Version 16.9.4, C# Form Designer allowed me to proceed my work.

For further info on this issue, check:

Hurdygurdy answered 1/9, 2022 at 9:33 Comment(0)

Workaround 1 (VS2022)

Workaround 2 (VS2022)

Workaround 3 (VS2019 or prior versions)

Recommended topics

Hot tags