NuGet packages should make a distinction between app platform and framework

[twsouthwick]

Currently, there is a NuGet package that contains everything in one package. This is great for simplicity in adding the package; however, it breaks when a target framework moniker (TFM) supports multiple app models.

For example, right now the WPF support is set for .NET Framework 4.5. However, WPF is supported in .NET Core 3.0. Blazor also runs on .NET Core 3.0. Having both of these in the same package is impossible, unless you want the blazor dependencies in a WPF app or vice versa. This is not ideal.

I propose splitting up the package so that they make a distinction of the app model being targeted. ie having the following packages:

• Comet: Contains the .NET Standard library that every other package depends on
• Comet.WPF: Contains a .NET Framework and .NET Core build of the WPF support
• Comet.iOS: Contains the Xamarin iOS support
• Comet.Android: Contains the Xamarin android support
• Comet.UWP: Contains the UWP support
• Comet.Mac: Contains the Mac support
• Comet.Blazor: Contains support for the Blazor framework

This could also be packaged as the following (I'm not super familiar with Xamarin conventions so this may not be a good idea):

• Comet: Contains the .NET Standard library that every other package depends on
• Comet.Windows: Contains the WPF support for .NET Framework and .NET Core 3.0 and UWP for uap
• Comet.Xamarin: Contains the xamarin support for Android/iOS/Mac
• Comet.Blazor: Contains support for the Blazor framework for .NET Core 3.0

These are some suggestions; the big issue is separating out the app platforms from the frameworks they support since NuGet packages can only be targeted by TFM and some TFMs support multiple platforms.

[saint4eva]

@twsouthwick the first proposal looks better and smarter.