More info:
This is a regression issue from d16.3 P3.
Minimal repro:
Actual behavior:
Two nodes ‘WPF’ and ‘.NET Core’ are missing on Add New item window.
Expected behavior:
These two nodes are showing correctly on Add New item window.
@Amy-Li02 our template "Windows Forms" is present in your screenshot. We do not maintian "WPF" and ".NET Core" templates.
@livarcocc , @vatsan-madhavan , @rladuca - this is a regression in the "Add New Item" dialog 16.4 P1 - which repo should take this issue (WinForms is there but nothing else)
/cc @zsd4yr
@chabiss, @diverdan92, @OliaG - can you help? I don't think IDE experience issues are tracked in any repo.
Should this issue be re-opened?
@jjmew @jmarolf did something change in the project system?
They are not supposed to show. See https://github.com/dotnet/project-system/issues/573
@jjmew - it would seem like things have changed regarding WPF/WinForms support in .NET Core from what that issue was filed. Do we want to update our definition of expected behavior to reflect the new support platforms?
I would expect both of these to show up for .NET Core WinForms development.
I can see at least two mistakes here:
Oh also, remember that WinForms (and WPF) added a 'class library' type, which should probably be incorporated into the mix.
winformslib and wpflib are the templates I'm talking about:
Windows Forms (WinForms) Application winforms [C#] Common/WinForms
Windows Forms (WinForms) Class library winformslib [C#] Common/WinForms
WPF Application wpf [C#] Common/WPF
WPF Class library wpflib [C#] Common/WPF
WPF Custom Control Library wpfcustomcontrollib [C#] Common/WPF
WPF User Control Library wpfusercontrollib [C#] Common/WPF
Should this issue be moved into https://github.com/dotnet/project-system/ repo?
/cc: @davkean
This is by design, .NET Core node was an accident, and WPF node doesn't exist when the project isn't a WPF project.
Thank you
@davkean this contradicts the WinForms on .NET Framework experience. The Add->New Item dialog includes the WPF node with the WPF User Control item template, which makes sense, because you can include such a control in the WinForms app using the WinForms ElementHost control.
@RussKie - can we consider reopening this issue as an issue with the design, if this is the current design?
cc @OliaG
@diverdan92 I perfer the issue moved as it is clearly has nothing to do with WinForms runtime.
@RussKie agreed. Sounds like it should be moved to project system as suggested above.
@diverdan92 We've discussed this issue lots of times in the past; unlike the Framework design where templates can just add references to add WPF to a project - there's no current way for a template/VS to reason about adding "WPF" to a project due to the current file format. If SDK/WinForms/WPF want to solve this problem end-to-end (they combined own the format & templates) - feel free to open a design issue against them. The current design is about preventing the user from adding a template that will not work in their project.
@davkean WPF does work in WinForms, always has been. Desktop Framework has had artificial boundaries through project types separating the frameworks, this separation is gone in .NET Core (there is only one SDK containing both WinForms and WPF !) and you just need to add a setting in the csproj (which is now editable in VS with text editor) so the barrier to using WPF in WinForms is adding one line of text. Looking statically at project types or templates is the wrong approach for .NET Core. This issue really should be moved to the appropriate place (which is still unclear, at least to me)
@weltkante I'm aware of how this works, I work on the project-system. I'm not against having the templates show up, its just that the underlying VS pieces haven't landed to make it work. You will see that if both WPF and WinForms properties are turned on, all the templates show up.
Most helpful comment
I can see at least two mistakes here: