Winforms: WinForms Designer cannot design From inheriting from another Form

[fitdev]

• .NET Core Version:

.NET SDK (reflecting any global.json):
 Version:   5.0.100
 Commit:    5044b93829

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\5.0.100\

Host (useful for support):
  Version: 5.0.0
  Commit:  cf258a14b7

.NET SDKs installed:
  5.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.NETCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

• VS: 2019 16.9 Preview 1 Community

• Have you experienced this same bug with .NET Framework?:
  No. On .Net Framework in the same VS version it works quickly and flawlessly.

Problem description:

Not sure if it is related to VB or is also applicable to C#, but I have the case:

FormIWantToDesign.vb

Friend Class FormIWantToDesign : Inherits ContainerForm

End Class

FormIWantToDesign.Designer.vb

<Global.Microsoft.VisualBasic.CompilerServices.DesignerGenerated()> _
Partial Class FormIWantToDesign : Inherits ContainerForm

End Class

ContainerForm.vb

Public Class ContainerForm : Inherits System.Windows.Forms.Form

End Class

ContainerForm.Designer.vb

<Global.Microsoft.VisualBasic.CompilerServices.DesignerGenerated()> _
Partial Class ContainerForm
    Inherits System.Windows.Forms.Form
'Designer generated code here
End Class

All classes / files are part of the same .Net 5 project. Project compiles, is built, rebuilt, and at runtime everything works.

Expected Behavior:
When I click on FormIWantToDesign.vb I want the VS to show me a WF designer so I can interact with controls on the form, _just as is the case with .Net Framework version of it_.

Actual Behavior:

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: 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: \r\n FormIWantToDesign --- The base class 'MyProjectNamespace.ContainerForm' could not be loaded. Ensure the assembly has been referenced and that all projects have been built.     

Instances of this error (1)  

at Microsoft.VisualStudio.WinForms.RemoteClient.Loader.RemoteCodeDomDesignerLoader.EnsureDocument(IDesignerSerializationManager manager)
at Microsoft.VisualStudio.WinForms.RemoteClient.Loader.RemoteCodeDomDesignerLoader.PerformLoad(IDesignerSerializationManager manager)
at Microsoft.VisualStudio.Design.Serialization.CodeDom.VSCodeDomDesignerLoader.PerformLoad(IDesignerSerializationManager serializationManager)
at Microsoft.VisualStudio.Design.Serialization.CodeDom.VSCodeDomDesignerLoader.DeferredLoadHandler.Microsoft.VisualStudio.TextManager.Interop.IVsTextBufferDataEvents.OnLoadCompleted(Int32 fReload)  

Why it says MyProjectNamespace.ContainerForm cannot be loaded I have no idea. The project has been built, and is the same project as the one that contains the form I try to open in a designer.

Minimal repro:
See files samples above.

[kirsan31]

https://github.com/dotnet/winforms/issues/3338 Again?

[fitdev]

@kirsan31 I was not aware of that issue. But, yes, mine seems to be exactly the same, and is happening with Net 5 RTM build and latest VS Preview - 2019 16.9 P1.

[merriemcgaw]

Duplicate of #3338

[merriemcgaw]

Thanks guys!

[kirsan31]

@merriemcgaw the problem here is that #3338 is closed too ...
In my post I meant _that seems #3338 is rised again_...

[fitdev]

@merriemcgaw But that issue _is closed_, and apparently without a resolution (linked to a different issue which was closed as well). Besides, this issue is specifically about .Net 5, not .Net 3.1 as the referred issue was.

[FyiurAmron]

@merriemcgaw the problem still appears in the wild in .NET 5.0; why was this closed?

[merriemcgaw]

Sorry for the confusion all. I saw that #3338 was closed because we tested C# and things seemed to be good. My bad for not checking VB .NET 😊

In my testing on 16.8.2 I'm not having any difficulty designing an inherited for in C# for either .NET Core 3.1 or .NET 5. So VB Specific? @KlausLoeffelmann can you check this out? I'll try VB.NET again too later this evening. @Olina-Zhang can you try this with both 16.8.2 and the latest 16.9 Preview bits?

[Olina-Zhang]

@merriemcgaw Verified in both 16.8.2, 16.9.0 Preview1 and the latest 16.9 Preview build, this issue cannot repro for WinForms VB .Net Core app.
Test app:
WinFormsApp1.zip

[fitdev]

@Olina-Zhang Thank you very much for looking into this. I was very surprised myself that I could not repro the issue on my VS 16.9 Preview 1 either. Your demo worked.

After fiddling for a few hours trying to see what's substantially different between your demo and my project I cam across publish settings.

  <PropertyGroup>
    <RuntimeIdentifier>win-x86</RuntimeIdentifier>
    <PublishTrimmed>false</PublishTrimmed>
    <TrimMode>copyused</TrimMode>
    <TrimmerRemoveSymbols>true</TrimmerRemoveSymbols>
    <DebuggerSupport>false</DebuggerSupport>
    <EnableUnsafeBinaryFormatterSerialization>true</EnableUnsafeBinaryFormatterSerialization>
    <EnableUnsafeUTF7Encoding>false</EnableUnsafeUTF7Encoding>
    <EventSourceSupport>false</EventSourceSupport>
    <HttpActivityPropagationSupport>false</HttpActivityPropagationSupport>
    <UseSystemResourceKeys>true</UseSystemResourceKeys>
    <SuppressTrimAnalysisWarnings>false</SuppressTrimAnalysisWarnings>
    <IlcDisableReflection>false</IlcDisableReflection>
    <IlcInvariantGlobalization>false</IlcInvariantGlobalization>
  </PropertyGroup>

These settings, AFAIK are only used / valid during publish or executable generation and should not (or so I thought) affect design-time / coding experience. But apparently some of them do. As soon as I included the above snippet in your vbproj file, reopened the project, rebuilt the project, I could _no longer_ design the form.

So, then the issue is almost surely not with VB but with these settings. And the questions are thus:

1. Which of the setting(s) above cause WinForms Designer to misbehave in the reported way, as well as in other ways potentially?
2. Which _other_ MSBuild/DotNet settings could negatively affect the designer?
3. Perhaps this should be clearly conveyed in the VS UI or at the very least documentation for the WF Designer. That it will not work with certain Publish / MSBuild settings.
4. Finally, why these seeming publish-only-related settings impact WF Designer in the first place? And how can one have those settings applied for publishing, _while still being able to use the designer_?

Thank you.

[fitdev]

Oh And forgot to add: once these settings are included in the project, even after removing them, or commenting them out, the designer would no longer work. Even after clean-rebuilding the project. It would only start working once the settings are removed, _and VS is restarted_.

[weltkante]

The RuntimeIdentifier may be used beyond publishing, maybe the VS designer is running 64 bit and setting the RuntimeIdentifier conflicts? Just a random guess.

[kirsan31]

The RuntimeIdentifier may be used beyond publishing, maybe the VS designer is running 64 bit and setting the RuntimeIdentifier conflicts? Just a random guess.

Yes, there was an issue about that.
@fitdev
I am worry if you will have both RuntimeIdentifier and Platforms - will it work?
Also we have https://github.com/dotnet/sdk/issues/1553 :)

[RussKie]

I am worry if you will have both RuntimeIdentifier and Platforms - will it work?
Also we have dotnet/sdk#1553 :)

@clairernovotny @dsplaisted shooting from the hip here, is it something you could provide guidance with?

[dsplaisted]

What is Platforms even supposed to do? I only see one reference to it in the .NET SDK or MSBuild:

https://github.com/dotnet/sdk/blob/14faf3a5542df6d0c2d8e0e4746814ea23e1484b/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.props#L22

[merriemcgaw]

@Shyam-Gupta may know a bit more about Platforms (he's mentioned it before at least 😃 )

[Shyam-Gupta]

@fitdev From the project settings you shared, it looks like you are trying to create a Self Contained WinForms app. At present WinForms .NET Core designer does not support Self Contained apps though at runtime the project binaries will work fine. It is in our backlog to add its support to the designer.

The reason why these settings impact designer is that the WinForms .NET Core designer spins up a child .NET Core process which loads the same .NET Core version as specified in project settings. It works fine for framework dependent apps. But support for Self Contained apps is yet to be added.

[fitdev]

@Shyam-Gupta Thank you for looking into this and the explanation. A few questions though:

1. Which particular setting then causes WinForms Designer to not work properly? Is it the <RuntimeIdentifier>win-x86</RuntimeIdentifier>? Should I therefore _not_ have _any_ RuntimeIdentifier defined?
2. What is then the recommended way to specify it, if not via project-imported MSBuild props? Should I instead use dotnet publish argument for that?

Thank you.

[Shyam-Gupta]

@fitdev Yes its mainly due to RuntimeIdentifier. Once you remove it then other related settings such as PublishTrimmed etc. will be of no use either. So you can remove those as well.
As you mentioned you can use dotnet publish to create Self Contained app till this scenario gets supported in WinForms designer.

[dsplaisted]

I believe you can also set up publish profiles which can specify the RuntimeIdentifier to use for publish.

[RussKie]

Closing as there's no immediate action from the team.
The design support for self-contained apps is coming in the future.