24

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?

enzi
  • 4,057
  • 3
  • 35
  • 53
  • @Jodrell .NET v4.6, just migrated everything from v4.5.2 and noticed the outdated Bcl.Immutable package in the process. – enzi Aug 24 '15 at 16:31
  • I'd guess that you can omit the dependencies since 4.6 ships all those packages at version 4.0.0 or later. I haven't tried so don't feel qualified to submit an answer. – Jodrell Aug 24 '15 at 16:36
  • If they are already referenced, check that your references are newer than the NuGet ones, then you can remove the additional references and put in an assembly redirect into web.config so that the system loads the newer version described here: https://msdn.microsoft.com/en-us/library/7wd6ex19%28v=vs.110%29.aspx#BKMK_Specifyingassemblybindinginconfigurationfiles – Lukos Aug 24 '15 at 16:37
  • @Lukos I actually don't reference any of the listed DLLs (in the projects that use `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 consider `app.configs` when it resolves dependencies – or does it? – enzi Aug 24 '15 at 16:49
  • NuGet doesn't but if the Immutable classes are looking for a specific older version, the redirects will work. What I was saying is that it is OK to allow NuGet to pull them all in and then delete the older references you don't need using the redirect to make sure it doesn't fall over. – Lukos Aug 25 '15 at 11:33

1 Answers1

25

You are just seeing a side-effect of the Nuget package having to keep a lot of people happy. The package supports an enormous number of targets, it is proliferating rapidly as of late. I see support for Xamarin for OSX and iOS, Windows Phone 8.0 and 8.1, Windows Store, CoreCLR (the open source project), .NET 4.5, MonoTouch for iOS and Android and .NETCore (Silverlight).

These dependent packages just contain reference assemblies, the kind that are normally installed in your c:\program files x86\reference assemblies directory. The Nuget package doesn't take the chance that such a reference assembly might be missing and includes the whole kit and kaboodle.

After it is all downloaded, the package installer runs and adds the references you actually need in your project. Easy to see what happened, just open the References node of your project. If your targeted the desktop version of .NET 4.5 and up, the grand total of added references is one, just System.Collections.Immutable. Yes, you can remove them.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Indeed, no references other than `Immutable` were added. However my primary concern was the packages themselves – those are now in my `packages.config` and will get downloaded whenever I clean the packages directory (granted that doesn't happen too often, but still – if I don't need it, I'd like to remove it). So, could you please clarify Hans: when you say "you can remove them", are you referring to the references, or the packages in `packages.config`? – enzi Aug 24 '15 at 20:16
  • The entries in packages.config and the subdirectories. – Hans Passant Aug 24 '15 at 20:20
  • Things get better with project.json ... dependencies of dependencies no longer go into the file. – gregjhogan Feb 23 '16 at 20:25
  • Perhaps worth adding is that [it's supposed to be fixed in the next version of the package](https://github.com/dotnet/corefx/issues/2984): "chcosta commented on 30 Nov 2015: A fix for this has been submitted and will be present in the next package push." –  Mar 09 '16 at 19:00