Standard: More than 96 assemply of NetStandard 2 are copied to the bin folder of Console (.Net framework) Application

[moh-hassan]

Sorry if this is the wrong repo to put this in. let me know and we'll move it.

in vs 2017.3 preview 3, I created a solution with three projects: Netstandard2 library (.Net Standard v2.0 preview) , Console applicationA (.Net framework) and Console applicationB (.Net core)

Both console applications reference the Netstandard2 library.

When I build the solution I find all assemblies (96 dll file) of the Netstandard2 are copied to the bin folder of Console applicationA , while for Console applicationB (.Net core) are not copied.

Is this a normal?
How to deploy the Console applicationA to a new machine? Do I need to install both .net 4.6.1 + dotnet-win-x86.2.0.0-preview1-002111-00.dll ?

Update:

For dependency test, I deleted all 96 assemblies except netstandard.dll and the Console applicationA (.Net framework) is working fine. So, I think it's not necessary to copy all these binaries to the bin folder.

I copied the console application + the Nestandard library + netstandard.dll` to a machine that has .net 4.6.1 only installed and it's working fine.

[weshaggard]

cc @terrajobst @Petermarcu @ericstj

At this point we don't do any smart trimming of the compat shims that come with the tooling so it ends up copying them all. If you (or your dependencies) don't rely on them it is safe to delete/not-deploy them but doing it blindly may break some of your dependencies.

We https://github.com/dotnet/standard/blob/master/Microsoft.Packaging.Tools.Trimming/docs/trimming.md which is a tool we are working on to trim unnecessary binaries from the output. You could give it a try if you are interested.

[terrajobst]

As Wes pointed out, we currently deploy what's safe. .NET Standard 1.x requires all of these files. If you only consume binaries that target .NET Standard 2.0+, you get a way with fewer files. However, there are still cases where you need some extra files beyond netstandard.dll (off the top of my head: System.Net.Http, System.ValueTuple, System.Runtime.InteropServices.RuntimeInformation, System.Data.Common). Subsetting by hand is possible, but as Wes said: you should test your app.

It's worth mentioning that with .NET Framework 4.7.1 and up you'll not have to deploy any extra files for .NET Standard. Today, that's already the case if you target Xamarin or .NET Core.

[moh-hassan]

Thanks @weshaggard for the suggested solutions.
@weshaggard, I think that copying is done for for .Net framework and not for .Net Core , that's bez .not core has a dependency json find that can use the shared binaries, and .Net framework haven't. Is it right?

[moh-hassan]

Thanks @terrajobst for the suggested solutions.
What is special for .NET Framework 4.7.1?

[weshaggard]

@weshaggard, I think that copying is done for for .Net framework and not for .Net Core , that's bez .not core has a dependency json find that can use the shared binaries, and .Net framework haven't. Is it right?

It is because those dependent assemblies already exist in the .NET Core shared framework so they don't have to be deployed with the application. Whereas with .NET Framework they aren't included with the framework itself and so they have to be carried with the application. The key difference with .NET 4.7.1 is we put them in the framework in that version so you will no longer need to carry them with your application and it will be much like .NET Core at that point.