Why are there System.*.* dlls in my bin release directory?

Question

When building my application which consists of 10 lines of code and has dependency to Zeroconf & Newtonsoft.json, it produces around 104 dlls in my bin release directoy and a lot of them are System. . dlls.

Why? How can I reduce it to 3 dlls? one for my lib, one for zeroconf and one for Newtonsoft.Json.

nuget After installing .Net 4.7.1

Answer 1

This is a .net standard 2.0/net 4.6/4.7.1 issue which was improved in 4.7.2:

"In .NET Framework 4.7.2 we have addresses the known runtime issues with .NET Standard 2.0. We made changes to the runtime to ensure that you don't need additional files deployed along with your .NET Standard library "

So, run Visual Studio 2017 Installer and install .Net Framework 4.7.2 and the Target Pack and target your app as .net 4.7.2.

Answer 2

The C# IDE has an option for that, "Specific Version = False". Not available in the C++/CLI IDE. Frankly, this is not a real problem. You are probably using the [AssemblyVersion] attribute incorrectly. That version is associated with the publicly visible classes in the assembly. If you make any changes in the public members of those classes then you've got a potentially breaking change that can make code that has a dependency on those classes fail.

At that point should you change the [AssemblyVersion]. And any project that uses the assembly must get their reference assembly updated and must be recompiled.

An otherwise non-breaking change, like a bug fix or a tweak in the non-visible classes produces a new file that is otherwise completely compatible with any project that uses it. You should update the [AssemblyFileVersion] number. Which in a C++/CLI project requires updating the unmanaged Version resource. Changing the corresponding .rc file could be automated, or you could use a #define.

Note how the .NET base assemblies in version 2.0 behaved the same way. Their [AssemblyVersion] stayed at 2.0.0.0 throughout the 3.0, 3.5 and 3.5 SP1 releases. Their file version started at 2.0.50727.42. And got incremented many times over the past 5 years, up to 2.0.50727.4927, give or take.

For the record, that VS2010 bug you linked to is not a bug. It just never worked before, failure was silent. It is a flaw in the C++ build system, mt.exe embeds the manifest after the assembly is strong named. And breaks the strong name in the process because that changes the file hash. VS2010 is actually an improvement, it warns about it rather than silently letting a broken strong name go through. You don't have to delay-sign, only resign with -Ra in a post build event.