Winforms: Designer doesn't work for 32-bit projects

[filipnavara]

• .NET Core Version: 3.1, 5.0 RC1

• Have you experienced this same bug with .NET Framework?: No

Problem description:

The new WinForms designer seems to always run as 64-bit process. This causes an issue when the application that is being developed is targeted to use 32-bit runtime (eg. <RuntimeIdentifier>win-x86</RuntimeIdentifier> specified in .csproj file). The designer process then tries to load the project assembly and fails:

[01:20:10.4528879] [DesignerInheritenceBug]: fail: WinFormsSurface.Services.TypeResolutionService[0]
[01:20:10.4528879] [DesignerInheritenceBug]:       Failed to load assembly: C:\Users\Filip Navara\AppData\Local\Temp\WinFormsCache\vhfep02y.e1h\DesignToolsServer\UserAppData\DesignerInheritenceBug.dll
[01:20:10.4528879] [DesignerInheritenceBug]:       System.IO.FileLoadException: Could not load file or assembly 'DesignerInheritenceBug, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
[01:20:10.4528879] [DesignerInheritenceBug]:          at System.Runtime.Loader.AssemblyLoadContext.LoadFromPath(IntPtr ptrNativeAssemblyLoadContext, String ilPath, String niPath, ObjectHandleOnStack retAssembly)
[01:20:10.4528879] [DesignerInheritenceBug]:          at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
[01:20:10.4528879] [DesignerInheritenceBug]:          at WinFormsSurface.Services.TypeResolutionService.LoadFromAssemblyPath(String filePath)
[01:20:10.4538890] [DesignerInheritenceBug]: fail: WinFormsSurface.Services.TypeResolutionService[0]
[01:20:10.4538890] [DesignerInheritenceBug]:       Failed to load assembly: DesignerInheritenceBug, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
[01:20:10.4538890] [DesignerInheritenceBug]:       System.IO.FileLoadException: Could not load file or assembly 'DesignerInheritenceBug, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. Could not find or load a specific file. (0x80131621)
[01:20:10.4538890] [DesignerInheritenceBug]:       File name: 'DesignerInheritenceBug, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
[01:20:10.4538890] [DesignerInheritenceBug]:        ---> System.IO.FileLoadException: Could not load file or assembly 'DesignerInheritenceBug, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
[01:20:10.4538890] [DesignerInheritenceBug]:          at System.Runtime.Loader.AssemblyLoadContext.LoadFromPath(IntPtr ptrNativeAssemblyLoadContext, String ilPath, String niPath, ObjectHandleOnStack retAssembly)
[01:20:10.4538890] [DesignerInheritenceBug]:          at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
[01:20:10.4538890] [DesignerInheritenceBug]:          at System.Runtime.Loader.AssemblyLoadContext.ResolveUsingLoad(AssemblyName assemblyName)
[01:20:10.4538890] [DesignerInheritenceBug]:          at System.Runtime.Loader.AssemblyLoadContext.Resolve(IntPtr gchManagedAssemblyLoadContext, AssemblyName assemblyName)
[01:20:10.4538890] [DesignerInheritenceBug]:          at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, RuntimeAssembly assemblyContext, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, AssemblyLoadContext assemblyLoadContext)
[01:20:10.4538890] [DesignerInheritenceBug]:          at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, StackCrawlMark& stackMark, AssemblyLoadContext assemblyLoadContext)
[01:20:10.4538890] [DesignerInheritenceBug]:          at System.Reflection.Assembly.Load(AssemblyName assemblyRef, StackCrawlMark& stackMark, AssemblyLoadContext assemblyLoadContext)
[01:20:10.4538890] [DesignerInheritenceBug]:          at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyName(AssemblyName assemblyName)
[01:20:10.4538890] [DesignerInheritenceBug]:          at WinFormsSurface.Services.TypeResolutionService.LoadAssembly(AssemblyName assemblyName)

The .dll compiled with these options has the following headers:

File Header:
  Machine:                       0x014C (Intel x86)
  Number of Sections:            3
  Time Date Stamp:               0xCD7DCE1C (4/1/2079 1:27:24 PM)
  Pointer to Symbol Table:       0x00000000
  Number of Symbols:             0
  Size of Optional Header:       0x00E0 (224)
  Characteristics:               0x0102
    File is executable
    32 bit word machine

CLR Header:
  .NET 2.0+ Assembly
  Flags:                         0x00000003
    IL only
    32 bit required

Expected behavior:

The designer should work.

Ideally it should run as 32-bit process since that would allow loading 32-bit native libraries that may be required by the project. If that is not possible for some reason than it should be properly documented and report a more reasonable error to the user than "base type XY could not be loaded".

Minimal repro:

DesignerInheritenceBug.zip

[RussKie]

I appreciate you have spent the time to raise the issue, but issues with VS and VS Designer should be sent via VS Feedback channel (the icon in the top right hand side corner). The reason for this - the VS Feedback tool captures a lot of additional information (such as screenshots, memory dumps, stack traces, assembly versions, etc.) that can help us to investigate your issue and identify the cause.
Thank you.

[filipnavara]

While I can do it through the VS Feedback tool this seemed easier because I could clearly reduce it to the underlying cause and provide a project that reproduces the error. It was tested on Visual Studio 16.8.0 Preview 3.0 but the issue was present in all the previews so far.

[weltkante]

This team is not working on the designer, so while it may be easier for you, it isn't for the team fixing the bugs ;)

[filipnavara]

@weltkante That's not the messaging that I got for the past 2 years (both on this repository and in conversations elsewhere). Part of the design-time stack and some documentation is hosted in this repository so naturally it's the place where I report it. I am happy to report the issue through the VS Feedback tool but tracking the problems in two separate places is not helpful at all from the customer perspective.

To expand on that, some of the issues with the designer were directly caused by code in this repository that is responsible for type conversion or some other design-time building blocks. These issues clearly belong to this repository. I realize this particular issue is affecting the non-public part of the code that is part of Visual Studio. However, from our viewpoint, it is still something that affects the same end user component, and tracking it on two places is more burden for us.

[RussKie]

This team is not working on the designer, so while it may be easier for you, it isn't for the team fixing the bugs ;)

A little correction - there's one team that looks after Windows Forms. However the team's focus is currently split into two streams - the runtime (this repo, with me guarding it), and the designer.

Part of the design-time stack and some documentation is hosted in this repository so naturally it's the place where I report it.

As I said above this repo is for the runtime aspects of the Windows Forms, the designer is built in a different repo, and reports for issues need to go through the VS Feedback channel. That channel collects quite a bit more information that just a stack trace, and this information is handled by dedicated engineers.

I am happy to report the issue through the VS Feedback tool but tracking the problems in two separate places is not helpful at all from the customer perspective.

VS and Designer issues are tracked via the VS Feedback, and not tracked here due to different release cadences.

These issues clearly belong to this repository.

I am afraid it doesn't.

[filipnavara]

These issues clearly belong to this repository.

I am afraid it doesn't.

I meant issues like https://github.com/dotnet/winforms/issues/2886 which are caused by broken code in this repository that happens to be used by the designer.

[filipnavara]

Cross-posted through VS Feedback as https://developercommunity.visualstudio.com/content/problem/1205607/net-core-winforms-designer-doesnt-work-for-32-bit.html. I am happy to do that for this kind of issues but the VS Feedback tool lacks public attachments. That makes it harder for me to share it with my coworkers.

[RussKie]

Thank you, I'll make sure your report gets in the team's radar.

[merriemcgaw]

@Shyam-Gupta - can you take a look at this? It doesn't seem like the expected behavior.

[Shyam-Gupta]

@filipnavara Instead of RuntimeIdentifier, could you use <Platforms>x86</Platforms> to specify target platform ? You can use Visual Studio Configuration Manager dialog to set target platform for the project or solution.

[kirsan31]

Good point from @Shyam-Gupta.

And strictly in your case:

Also I must to notice that visual inheritance still not working at new designer...

[Shyam-Gupta]

@filipnavara I hope using <Platforms>x86</Platforms> would have resolved this issue. Since there is no action item left, I am closing this bug.

@kirsan31 Thank you for the validation.
Regarding inherited Forms: They should work after the application is built. If not then let me know and we can discuss it on the other issue.