Similar to managing references to NuGet packages and other projects (P2P references), the CLI should provide a mechanism to manage reference to frameworks.
Looking at a few 3.0 apps being built, I have seen horrible workarounds to make library projects trying to make use of types in the ASP.NET Core shared frameworks for creating separate projects for things like controllers for certain APIs, reusable middleware, action filters and so on. One involves creating a web app with an empty Main function..
While users will need to learn about referencing frameworks using FrameworkReference, I think a CLI command should also be an option to manage these references because.
A bonus is that the CLI can know which frameworks are available for which TFM.
This may also apply to libraries using types of WinForms or WPF (even though XAML might not work, one may want to use the framework reference to write useful shareable types), but at least there are project templates for wpflib, winformslib.
Similar to managing references to NuGet packages and other projects (P2P references), the CLI should provide a mechanism to manage reference to frameworks.
Looking at a few 3.0 apps being built, I have seen horrible workarounds to make library projects trying to make use of types in the ASP.NET Core shared frameworks for creating separate projects for things like controllers for certain APIs, reusable middleware, action filters and so on. One involves creating a web app with an empty Main function..
While users will need to learn about referencing frameworks using
FrameworkReference
, I think a CLI command should also be an option to manage these references because.A bonus is that the CLI can know which frameworks are available for which TFM.
This may also apply to libraries using types of WinForms or WPF (even though XAML might not work, one may want to use the framework reference to write useful shareable types), but at least there are project templates for wpflib, winformslib.