I just switched from (an older) Microsoft.Bcl.Immutable
NuGet package to System.Collections.Immutable
and was surprised to find all these new package dependencies in my project:
System.Collections
System.Diagnostics.Debug
System.Globalization
System.Linq
System.Resources.ResourceManager
System.Runtime
System.Runtime.Extensions
System.Threading
They are listed as dependencies of the NuGet package, so they have a right to be there, yet they are obviously also already installed on my PC and my target environment (Azure btw) as they come with the framework.
I already have a large number of packages in my project and would like to avoid the additional overhead caused by these 8 packages, if possible (and without shooting myself in the foot).
Is it safe to remove these dependencies?
Do I now have to use these packages throughout my project because they might differ from their installed versions and some portion of my project might now use the wrong ones? (due to some DLL linking madness?)
Edit: Just for completeness, as there was a comment before: The dependencies are actual packages (not namespaces) and have to be downloaded, I'm targeting and compiling with .NET 4.6, working in VS2015. It's entirely possible though that something is outdated and the packages do not have to be loaded normally?
Immutable
). Even if – would an assembly redirect be necessary? As I target .NET 4.6, all of these DLLs are guaranteed to be there (at least now where the requirement is >= 4.0.0). That aside, I believe NuGet doesn't considerapp.configs
when it resolves dependencies – or does it? – enzi