mattleibow
commented
5 years ago I totally second this - and I just cam across this very issue when trying to make use of Xaml islands. I tried to install the Xamarin.Forms package into the WPF project, but I had no way to tell NuGet to install the uap libraries instead of the netstandard. As a result, I did not get what I wanted.
This will become increasingly harder as the frameworks overlap - WPF/WinForms/net4x can pull in net4x AND uap assets (Xaml islands), netcoreapp can pull in netstandard AND net4x assets (WPF on .NET Core).
kzu
akoeplinger
zkat
ghost
huoyaoyuan
dotMorten
adirh3
AraHaan
aortiz-msft
michael-hawker
davidxuang
jzabroski
The Problem
Now that the .NET ecosystem has overlapping feature-sets between .NET Framework, .NET Standard, and .NET Core, it is no longer correct to blindly assume the "nearest" framework target is what the developer requires. It is impossible for NuGet to always make the correct decision. At best, it is difficult and perhaps sometimes impossible for a package author to work around this forced selection to allow package consumers to target desired feature-sets.
Real-World Example
Don't get too hung up on the specifics of the following example. I've run across this problem in other scenarios in the past, but this illustrates the problem very clearly -- and happens to be a real-world example that I (as a package author) am facing today that is causing real problems for some of my 250,000+ package users -- including myself as a package user!
Consider a multi-targeted library that supports two approaches to configuration: the older-style System.Configuration classes (e.g. XML-based app.config or web.config, originally only in .NET Framework, but then added to .NET Core 2.0, yet not part of any .NET Standard definition); as well as the newer .NET Standard Microsoft.Extensions.Configuration packages (aka M.E.C).
Everyone knows the best-practices approach for authoring libraries is to target the lowest possible versions of any dependencies. Because there are only two configuration scenarios, the project behind the package should only require two sets of TFMs and the corresponding code variations. The minimum TMFs supporting System.Configuration would be
net452andnetcoreapp2.0, and the minimum TFM supporting M.E.C would benetstandard2.0.In today's world, there is no ambiguity if you reference that package from a
net452library or app, or anetstandard2.0library. But if you reference it from anetcoreapp2.0app or library, you're locked into the System.Configuration variant, there is no way to use thenetstandard2.0variant. Similarly, if you reference it from anet461or newer library or app, you're locked into the M.E.C variant, there's no way to choose the System.Configuration variant.Inadequate Work-Arounds
In that specific example, the two configuration methods are technically not incompatible. I could hack together some third TFM group for
net461andnetcoreapp2.0that supported both, although the real-world fact is that this is extremely sloppy. System.Configuration works transparently, whereas M.E.C is an external package, so configuration by that approach requires the package consumer to obtain and provide a reference to a configuration object. There are many other package-specific complications not worth getting into here. Suffice to say it's ugly and obviously a hack, at best.I haven't done exhaustive research of the tens of thousands of APIs available, but I assume there are also scenarios where the TFM variations are not compatible, which leaves package authors with no possibility of a work-around, no matter how sloppy or ugly they're willing to make their interfaces.
I don't mean to editorialize, but I did label this section "inadequate work-arounds"... Lately it seems as if the default Microsoft response to many NuGet questions and issues is to just hack up the package locally and effectively abandon the whole reason we use packaging in the first place. I find that suggestion as appalling as it is unrealistic, and in professional / corporate scenarios it's almost guaranteed to break the rules or raise serious red flags, especially if you're subject to a complex integration pipeline, locked-down package sources like MyGet, and so on. It's just bad advice no matter how you look at it.
Feature Request
Fortunately, this seems like an easy problem to fix.
In the VS NuGet GUI, simply adding radio buttons alongside the list of build targets shown under "Dependencies" ought to be sufficient.
Behind the scenes, this would obviously require a change to configuration syntax, and I assume some build support and new CLI switches (I'm old enough to remember when CLIs were hated and a good GUI was preferred, and I still avoid CLIs whenever possible, so I don't have any specific proposals there).
In terms of configuration support, it seems it could be as simple as accepting an optional TFM as part of the
PackageReferencenode. Resolving the example discussed earlier would look like this:I'm also unclear about possible impacts for other dependencies (RIDs? platforms like x86 vs x64?). I don't have much need for those so I'd have to research it -- but I assume the NuGet teammembers would have a good idea of any related impacts. I'd even consider PRing this one myself except that I don't clear picture of the probably-many repos involved in terms of build support, csproj support, and so on. I imagine that's the nature of NuGet changes in general, even though this appears to be very straightforward as a concept.
This ran a bit long, and I appreciate the time anyone invests in giving it consideration.