dotnet
WinForms SDK should explicitly contribute WindowsForms ProjectCapability
Currently the WinForms SDK does not contribute the "WindowsForms" ProjectCapability. It is contributed by Microsoft.Managed.DesignTime.targets but that does not apply outside of VS.
The ProjectCapability should be explicitly contributed by the SDK, so that proper detection of project type can be done outside of VS.
@bwateratmsft could you clarify this a bit? What is the need here? What is the impact of moving these?
Is this something that needs to change by 3.0 GA (VS 16.3 GA)?
@livarcocc are you aware of any need for the SDK to supply these to VS?
/cc @dagood @vatsan-madhavan
proper detection of project type can be done outside of VS.
@bwateratmsft could you clarify some of these scenarios? VSCode?
@zsd4yr Our main use case is in VS so technically the problem doesn't apply to us directly (since we have the DesignTime target). My team works on the Docker tools in VS, and our extension uses ProjectCapability to know whether or not to show the options to add Docker/Docker-Compose/etc. support. Of course it makes no sense to containerize a UI application so WinForms (and WPF) should not show those options.
Because of the designer we are able to rely on the WindowsForms/WPF ProjectCapability, but it seems to me that the fact that it's WinForms is intrinsic to the app itself, not to the fact that it's open in VS--so it makes more sense to me that the ProjectCapability should be in the SDK rather than the DesignTime targets.
In VS Code--for which we also do the Docker extension--this ProjectCapability isn't available (no DesignTime target). Hence, we couldn't depend on it as a way to hide the option to add Docker support.
In terms of urgency--No, it's not urgent enough that we need it in 3.0 GA. The severity is very low. Most users would never attempt it since it doesn't make sense in the first place. Worst case, users add Docker support to their WinForms app, it doesn't work, and we tell them it doesn't make sense to containerize a UI app.
@bwateratmsft thanks for the followup!
@merriemcgaw I am moving this to 5.0.
Without any additional reports of a need for this we're unlikely to try and make this change. Closing for now.
