0

I am using Visual Studio 2017. When I create a new Console Application targeting .NET 4.5, 4.5.1, 4.5.2, 4.6, or 4.7.2 and add the NuGet package System.Buffers versions 4.4.0 or 4.5.0 when I build the output directory has only one DLL in it, the System.Buffers dll. When I target 4.7.1 and rebuild it has 17 System dll's in it. If I target .NET 4.6.1, 4.6.2, or 4.7 then the output directory has 101 System dll's in it, this occurs even when I set "Copy Local" to false for System.Buffers. All the default references have a default of Copy Local = false as well, Microsoft.CSharp, System, System.Core, System.Data, System.Data.DataSetExtension, System.Net.Http, System.Xml, and System.Xml.Linq. When I install System.Buffers 4.3.0 then this problem of 100 system dll's showing up in the output directory does not happen.

I want to target .NET 4.6.2 and would like to use the latest MongoDB driver which requires the latest DNSClient which requires System.Buffers <=4.4.0 and I don't understand why I now need 101 extra System DLLs in my output directory, is there a way around this without changing the .NET target?

An example from the MSBuild output for System.IO.dll:

1>Target "ResolveAssemblyReferences" in file "C:\Program Files (x86)\Microsoft VisualStudio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets" from project "{redacted}\ConsoleApp2\ConsoleApp2\ConsoleApp2.csproj" (target "ResolveReferences" depends on it):

1>Using "ResolveAssemblyReference" task from assembly "Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".

1>Task "ResolveAssemblyReference"

1> Unified primary reference "System.IO, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".

1> Using this version instead of original version "4.0.0.0" in "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\netfx.force.conflicts.dll" because AutoUnify is 'true'.

1> Resolved file path is "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.IO.dll".

1> Reference found at search path location "{HintPathFromItem}".

1> This reference is not "CopyLocal" because at least one source item had "Private" set to "false" and no source items had "Private" set to "true".

1> The ImageRuntimeVersion for this reference is "v4.0.30319".

...

1>Target "_CopyFilesMarkedCopyLocal" in file "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets" from project "{redacted}\ConsoleApp2\ConsoleApp2\ConsoleApp2.csproj" (target "CopyFilesToOutputDirectory" depends on it):

1>Using "Copy" task from assembly "Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".

1>Task "Copy"

1> Copying file from "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.IO.dll" to "bin\Debug\System.IO.dll".

Quantic
  • 1,779
  • 19
  • 30
  • update to at least .net 4.7.2, which is first fully .net standard 2.0 compatible.Better go to 4.8, which is last classic .net 4 release. – magicandre1981 Jul 26 '19 at 13:42
  • 1
    Now I don't know if this is actually duplicate of the other answer though it seems closely related. The differences: 1) This isn't a .Net Standard class library, it's a .NET Framework console application, so I am unable to multi-target as a workaround, and "What you are seeing are side effects of how .NET Standard is built .." doesn't answer this, 2) I do not get 100 triggered NuGet dependencies, there's 0 NuGet dependencies but my bin ends up with 100 dlls. E.g. for my posted example I do NOT see "Retrieving package 'System.IO 4.3.0' from 'nuget.org'" in my package manager output like the OP. – Quantic Jul 26 '19 at 16:25

0 Answers0