Add Windows Form does not nest .designer.cs under .cs

[jnm2]

I was not able to tell if this issue was already tracked.

Start with this .csproj (15.0.26014.0):

<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net452</TargetFramework>
    <RuntimeIdentifier>win</RuntimeIdentifier>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="**\*.cs" />
    <EmbeddedResource Include="**\*.resx" />
  </ItemGroup>
  <ItemGroup>
    <Reference Include="System.Windows.Forms" />
  </ItemGroup>
</Project>

Select Windows Form in Add New Item and see Form1.cs and Form1.designer.cs nodes are siblings in Solution Explorer, and this is the .csproj:

<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net452</TargetFramework>
    <RuntimeIdentifier>win</RuntimeIdentifier>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="**\*.cs" />
    <EmbeddedResource Include="**\*.resx" />
  </ItemGroup>
  <ItemGroup>
    <Reference Include="System.Windows.Forms" />
  </ItemGroup>
  <ItemGroup>
    <Compile Update="Form1.cs">
      <SubType>Form</SubType>
    </Compile>
    <Compile Update="Form1.Designer.cs">
      <SubType>Form</SubType>
    </Compile>
  </ItemGroup>
</Project>

[jnm2]

I hate to complain because of the amazing results you've already had, but six lines feels a bit more verbose than it needs to be. Is something like this possible? (Is SubType needed in the .csproj itself or can that info be cached after examining the contents? Could the nesting be automatic as well?)

    <Compile Update="Form1.cs" SubType="Form" />
    <Compile Update="Form1.designer.cs" SubType="Form" DependentUpon="Form1.cs" />

[jnm2]

More differences:

• The icon for Form1.cs is not the Form icon.
• Double-clicking does not open the designer.
• Once the designer is opened, the Text property is blank. Usually it would be Form1.
• Once the form is edited in the designer, Form1.resx shows up and Form1.designer.cs nests under that. Usually they'd nest as siblings with the parent Form1.cs.

[jnm2]

Correction: This is not an absolute showstopper, just very tedious to work around.

• Every time the form is edited in the designer, Form1.designer.cs gets replaced by the codegen for Form1.resx. This loses the partial modifier so the code does not compile, and moves InitializeComponent and all the field declarations into Form1.cs which is less than ideal.
  Every time, I have to manually remove the internal modifier and add the partial modifier to Form1.designer.cs and delete the constructor.
  I don't have the option to not use the resx. It gets created just by me setting a form property in the designer and saving.
  I'm pretty sure that the fact that the form is a partial class with the RESX code will be a major problem at some point- for example, if I don't want a parameterless constructor.

I tried deleting the .resx and the resx-generated designer file and now the designer will not open. Two errors:

NotImplementedException, call stack:

at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at Microsoft.VisualStudio.Design.Serialization.LicenseService.GetLicenseDocData(FileAccess access)
at Microsoft.VisualStudio.Design.Serialization.LicenseService.FillLicensedTypes()
at Microsoft.VisualStudio.Design.Serialization.LicenseService.get_LicensedTypes()
at Microsoft.VisualStudio.Design.Serialization.LicenseService.OnComponentAdded(Object sender, ComponentEventArgs e)
at System.ComponentModel.Design.ComponentEventHandler.Invoke(Object sender, ComponentEventArgs e)
at System.ComponentModel.Design.DesignerHost.AddToContainerPostProcess(IComponent component, String name, IContainer containerToAddTo)
at System.ComponentModel.Design.DesignerHost.PerformAdd(IComponent component, String name)
at System.ComponentModel.Design.DesignerHost.System.ComponentModel.Design.IDesignerHost.CreateComponent(Type componentType, String name)
at System.ComponentModel.Design.Serialization.DesignerSerializationManager.CreateInstance(Type type, ICollection arguments, String name, Boolean addToContainer)
at System.ComponentModel.Design.Serialization.DesignerSerializationManager.System.ComponentModel.Design.Serialization.IDesignerSerializationManager.CreateInstance(Type type, ICollection arguments, String name, Boolean addToContainer)
at System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializeInstance(IDesignerSerializationManager manager, Type type, Object[] parameters, String name, Boolean addToContainer)
at System.ComponentModel.Design.Serialization.ComponentCodeDomSerializer.DeserializeInstance(IDesignerSerializationManager manager, Type type, Object[] parameters, String name, Boolean addToContainer)
at System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializeExpression(IDesignerSerializationManager manager, String name, CodeExpression expression)
at System.ComponentModel.Design.Serialization.CodeDomSerializer.DeserializeStatementToInstance(IDesignerSerializationManager manager, CodeStatement statement)
at System.ComponentModel.Design.Serialization.CodeDomSerializer.Deserialize(IDesignerSerializationManager manager, Object codeObject)
at System.Windows.Forms.Design.ControlCodeDomSerializer.Deserialize(IDesignerSerializationManager manager, Object codeObject)
at System.ComponentModel.Design.Serialization.TypeCodeDomSerializer.DeserializeName(IDesignerSerializationManager manager, String name, CodeStatementCollection statements) 

and "The variable 'buttonEdit1' is either undeclared or was never assigned." which takes me to the code, wherein buttonEdit1 is most certainly both declared and assigned.

[jnm2]

The point of this exercise was to be able to see if the new .csproj offers deliverance from the madness that is licenses.licx, but I wasn't able to get that far. I'm guessing the NotImplementedException above, plus the message boxes I was getting earlier while moving controls around with the same NotImplementedException message, are indicative of a license system failure.

Here's what I'm hoping will eventually be the case:

• I can migrate all built-in csproj types to the new project system. WinForms, WPF, anything. This was the main justification for the decision to unify everything under .csproj and I'm still looking forward to the list of benefits across the board.
• No more listing .cs files and the resulting merge conflicts and careful source control diffing on each checkin!
• No more licenses.licx appearing in the .csproj! It's fine existing locally (even though it's truly pointless and should be cached outside of the source code), but the file itself is filtered from source control because of the inevitable thrashing that happens and the inevitable version errors on both dev machines and the build server. The last remaining piece of the puzzle is to keep it from appearing in the .csproj at all, because it's hard to notice and catch that before accidentally checking in the .csproj and having the build server choke on the missing file.

[jnm2]

I was able to confirm that a call to LicenseManager.Validate in a custom control constructor causes the NotImplementedException.

That brings this issue to a total of seven issues. Should I start issues for these or are they closely related enough for your purposes?

[davkean]

@jnm2 Hey thanks for trying out these scenarios.

As you noticed, we don't support WinForms yet. For the time being we're focused on .NET Core and only build and deploy for .NET Framework. The designers, etc do not/will not work until post VS 2017 RTM.

I think it's helpful to get issues filed on these and let's get them tagged so that we can understand what it takes to bring up WinForms (it's a going to be peeling of the onion).

The sub type issue is already being tracked here: #997.

The nesting issue is being tracked here: #159.

The other issues we are not tracking - would you like to file them or do you want me to?

[jnm2]

As you noticed, we don't support WinForms yet. For the time being we're focused on .NET Core and only build and deploy for .NET Framework. The designers, etc do not/will not work until post VS 2017 RTM.

Understood. My goal is to make these things visible so they happen sooner rather than later, because until there's a strong UI library for Core I'll be using WinForms for a while.

The other issues we are not tracking - would you like to file them or do you want me to?

Doesn't matter to me. They will probably be of more value if you file them since you know what's under the hood.

[PawelTroka]

When it will be done? It's important to me because it is the last thing remaining on my way to new csproj format :)

[damageboy]

This is also bugging me.

I'm trying to move entirely into new csproj land, and while most of my stuff will work as is, I have one(!) WinForms app that is holding me back.

Is there anyway, even if undocumented, to make new csproj deal with WinForms projects (while keeping the designer functional)?

[jnm2]

Yes, @onovotny, I've been meaning to ask if you have inside information to swoop in and save the day again?