Nito.AsyncEx V5 dependencies for .NET Framework are wrong
Closed this issue · 10 comments
Updating from 4.0.1 to 5.0.0-pre-02 results in new smaller Nito dependencies (which is OK), but also results in various .NET core System.* packages dependencies, which is not appropriate when targetting .NET Framework. This is caused by .NET core dependencies being propagated to both .NET core and .NET Framework.
You will need to do something similar to this by properly specifying .NET core dependencies only for .NET core variant.
Thank you in advance.
I believe the .NET tooling will (eventually) resolve this. But I'll keep this issue open, just in case.
Hi,
Just wanted to add to this - your Nito.AsyncEx.Interop.WaitHandles project has an explicit dependency on NETStandard.Library (>= 1.6.1). Is this required? I have a project targeting NETStandard 1.6 and the NuGet package is being brought in, however after reading here, I'm lead to believe explicit references to this library shouldn't be made?
Thanks btw for a great library.
That one hasn't been updated to the latest (VS2017) tooling yet. I'm hoping to get to that soon.
Does v5.0.0-pre-03 work for you?
Nope, there are still .NET Core dependencies being installed when targetting .NET Framework.
You can easily reproduce it yourself. Just open new clean .NET Framework project and try to install your package via nuget - if it tries to pull net standard/system packages then it's wrong, because those already exist in .NET Framework itself. When targetting .NET Core app/library, this is proper, but not when targetting .NET framework. Nuget should try to install only Nito packages on framework.
This wouldn't be a problem itself if nuget was automatically resolving those packages to given platform, but it's NOT doing that, which means that .NET Framework build output directory is filled with hundreds of .NET Core libraries, those that already exist in the framework, and can't be easily mapped when running e.g. under Mono.
(Not like it's an issue anymore to me, since I moved everything I had left to .NET Core, but this issue is still relevant for those that are trying to use your package in .NET Framework projects)
For example this should be properly ifed to be pulled only when targetting .NET standard, see commit I linked in first comment for future reference.
OK, I'm going to change the approach to multitarget netstandard1.3 and netstandard2.0. This is annoying, because the only need for multitargeting is because the tooling doesn't work properly. But oh, well.
However, this is a netstandard library as of v5. I have no plans to also multitarget net. So NETStandard.Library and Microsoft.NETCore.Platforms will always be referenced. That's just the way it is in the new world. System.Threading.ThreadPool will only be included for netstandard1.3 and not netstandard2.0.
Well if you don't want to keep compatibility with .NET Framework 4.6.1, which is the closest API to netstandard2.0 then there is no reason to keep this issue open.
It's perfectly compatible with net461 already. Is there a problem you saw other than the messy dependency situation (which is now as fixed as it can be)?
BTW, 5.0.0-pre-04 is out now, which fixes the System.Threading.ThreadPool dependency.
I was going to try v5 after updating to v4 last week from a custom v3 which had a fix for issue #57
However with v4 I think I've run into issue #57 again in production. So trying v5 results in the massive set of dependencies. From what I understand here it's a NuGet issue which will get resolved at some stage (I'm using latest non-prerelease version of VS 2017).
I think I'll roll back to my custom v3.x build for the moment and see if that solves my deadlock issue. I didn't need anything from v4 - it was just a matter of being well behind and not wanting to fall too far behind when v5 was eventually released.