My WPF application is using the old csproj way (not SDK style) and targets the .NET Framework 4.6.1. But I converted it to PackageReference.
Here are some examples of the referenced Nuget packages:
Microsoft.BclAsyncInterfaces
RestSharp
System.Windows.Interactivity.WPF
etc
When I build my application, the bin folder contains:
the dlls produced by my application
some Microsoft.*.dll
the RestSharp dlls
But also a lots of System.*.dll (more than 100 O_o).
Among them, there is System.Windows.Interactivity.WPF which I believe is required because it is not part of the .NET Framework.
But there also is a lots of dll that are parts of the .NET Framework:
System.Collections.dll
System.Linq.dll
etc
I guess all these dll are here because some of the referenced packages are using them. But are they all really necessary? I mean, I am targeting the .NET Framework, not .NET core, so why all these "native" dll are copied to my output folder?
I am asking this because I am building the setup of my application. I could obviously add all the dlls in the output folder into the setup but I would rather avoid it if possible.
If they are not all required, how can I decide which dll I have to add to the setup and which I can omit?
Based on comments in Stack Overflow question (VisualStudio copies all dlls to output directory ) and information found on GitHub (Targeting .NET Framework 4.7.1 copies extra files to your bin directory). I believe this issue may be related to your target framework version of 4.6.1. Updating your target framework 4.7.2 should remove the system DLLs from your output directory.
Related
.Net 4.8, C#, Npgsql, .NET 7.0
We add an access to PostgreSQL to an existing app .Net 4.8 .
How we did it? Just right click on "References" ->> "Manage NuGet Packages..."
In order to deploy, we have now a high number of dependent DLLs and XMLs (see a picture of a debug directory).
Question: how to minimize a number of artifacts (DLLs, XMLs ) to deploy?
XMLs should not be deployed.
For Npgsql, you need Npgsql.dll and Mono.Security.dll
Others .NET framework DLLs are needed only if your deployment isn't framework dependant, otherwise your app will expect to find them on the computer it runs on.
If a .NET 462 project references a .NET Standard 2.0 dll the dependencies are not copied to the output bin folder.
It works correctly when the .NET Standard 2.0 project is referenced as <ProjectReference /> and <RestoreProjectStyle>PackageReference</RestoreProjectStyle> is added to the .NET 462 project.
My .NET Standard 2.0 project lives in a different solution and therefore cannot be added as project reference.
Is there a solution to this problems, that maybe takes the deps.json in the bin folder of the .NET Standard 2.0 project into account?
Or is the only solution to add the .NET Standard 2.0 project to all solutions, where projects have references to it?
If you cannot add the project as a project reference, consider using NuGet to consume a built package (and the contained dependency graph).
At the time of writing, .net standard projects and their dependencies cannot be referenced from a set of files (like produced by dotnet publish on the .net standard project) since the graph of NuGet packages needs to be resolved for the target executable project's framework (core, .net framework, uwp, ..) and certain build logic that needs to run during build & publish for the resulting executable project is not being run for .net standard projects.
i'm trying to obtain an executable file with only the necessary dlls in the release folder, unfortunately VS is putting in that folder even System dlls, that afaik are not supposed to be redistributed with the executable.
I'd like to know if there's a way to make VS add to the release folder only dlls the executable can not work without, the ones that are supposed to be redistributed.
Thank you.
Release folder:
These assemblies are shims for .Net Standard where the full framework had gaps. Based on the assemblies in that folder, I assume that your exe is targeting .net 4.6.x and you are consuming a .net standard library.
If you upgrade to .net 4.7.2 you will see the number of required System.* assemblies reduced greatly.
See this answer for more details: Why does my .NET Standard NuGet package trigger so many dependencies?
I'm assuming this is a dotnet core project. Use the "dotnet publish" command to create your deployment files (the screenshot looks like a VS build directory?). You might see more dlls than you're used too if you're coming to dotnet core from using the Windows frameworks previously, but it depends on the publish options you use.
https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-publish
I'm certain there's probably a bunch of things going on here that I don't understand well enough, so forgive me if this is a stupid question or if there's obvious details missing.
I have a Visual Studio 2015 solution that I've upgraded from .NET 4.5.1 to .NET 4.7.1. The solution consists of a website (not web app) project, and several libraries. The libraries don't really have any dependencies (except eachother) and while they are targeting .NET 4.7.1, they don't use, need, or reference .NETStandard.Library.
When I compile one of the libraries in particular, it keeps copying a bunch of .NET 4.7.1 facade dlls into the website bin folder. Unfortunately, the website is a Kentico 11 application, and it keeps trying to load the System.IO.Compression.ZipFile facade, and chokes on it because it's a reference assembly, not a real assembly.
If I delete the .dll, everything runs fine... but I don't want to delete it every time or add a post-build event to delete it. That's just silly.
Can anyone help me understand what's going on here, and how to clean it up?
Kentico 11 can only target up to .NET 4.7 so in an attempt to fully support your .NET 4.7.1 libraries I believe it is copying in those additional facade DLLs. This is based on the .NET 4.7.1 release announcement, specifically this section:
BCL – .NET Standard 2.0 Support
.NET Framework 4.7.1 has built-in support for .NET Standard 2.0. .NET Framework 4.7.1 adds about 200 missing APIs that were part of .NET Standard 2.0 but not actually implemented by .NET Framework 4.6.1, 4.6.2 or 4.7. You can refer to details on .NET Standard on .NET Standard Microsoft docs.
Applications that target .NET Framework 4.6.1 through 4.7 must deploy additional .NET Standard 2.0 support files in order to consume .NET Standard 2.0 libraries. This situation occurred because the .NET Standard 2.0 spec was finalized after .NET Framework 4.6.1 was released. .NET Framework 4.7.1 is the first .NET Framework release after .NET Standard 2.0, enabling us to provide comprehensive .NET Standard 2.0 support.
https://blogs.msdn.microsoft.com/dotnet/2017/10/17/announcing-the-net-framework-4-7-1/
Reference that led me to this conclusion:
https://github.com/Particular/NServiceBus/issues/5047#issuecomment-339096350
Update:
I was unable to reproduce your issue in Visual Studio 2017 Version 15.6.2.
I installed a Kentico 11 website project targeting .NET 4.7. I then created a library project that targeted .NET 4.7.1. I added some dummy code to the project to make use of Sysetem.IO.Compression and System.Net.Http namespaces. I added a reference to the project from Kentico and ran a build. No facade DLLs where copied to the bin folder.
This post indicates the issue was fixed in Visual Studio version 15.6 https://github.com/dotnet/sdk/issues/1647#issuecomment-364999962
The additional files that get deployed to your bin folder are needed to support referencing and running .NET Standard 1.x and .NET Standard 2.0 libraries in your .NET Framework application.
We have documented this as a known issues with .NET Framework 4.7.1.
The presence of those additional files is not sufficient however. You also need to have binding redirects generated in order to ensure types correctly unify across libraries.
Visual Studio 15.6.3 (and later) have a change that will automatically generate those binding redirects for your application.
.NET Framework 4.7.2 addresses the issues that require those additional files to be deployed with your application. When targeting or running on .NET Framework 4.7.2 you won't have any additional files copied to your bin folder and no binding redirects will be automatically generated.
You can try .NET Framework 4.7.2 and see what's new by following the instructions here.
References to assemblies have their own properties. You can specify there if you want to copy the assembly to the build output directory. Maybe somewhere it is set to true. To check that go to Solution Explorer in Visual Studio and right click on the referenced assembly. Then click Properties and look for property named "Copy Local".
I have an new SDK-style csproj that targets multiple frameworks:
<TargetFrameworks>net461;netstandard2.0</TargetFrameworks>
The dependencies node in VS lists '.NETFramework 4.6.1' and '.NETStandard 2.0' as expected - and the NETStandard folder has 'NETStandardLibrary' as an SDK dependency.
My understanding of the multiple TFMs was to cross compile the class library for use as a Full Framework dll, or a netstandard dll. However, in the net461 output folder I see 100+ System.xxx.dll, including netstandard.dll.
Why are all these assemblies in the output? Or am I misunderstanding the concept of multiple target frameworks?
The problem is described in detail in several issues in DotNet Standard repo. The short explanation is:
The reason is that net471 is the first .NET Framework to actually contain netstandard20 APIs- the others use shims
It means that every time .NETStandard nuget package is referenced it will pull entire .NETStandard bunch of assemblies if version of .NET Framework is lower than v4.7.1.