Develop Reference

Are all System.*.dll required in the output folder?

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.

How to package .NET Core 3 in Visual Studio Installer Project

So, I want to create an installer for my .NET Core 3 based C# project. I installed the Installer Projects extension for Visual Studio 2019 and created a new Installer project within my solution. After some trying around with different settings, I ended up with adding PublishItemsOutputGroup for my two executables to the Application Folder.
This (throwing various warnings for duplicate dlls) creates a nice installer package with "supposedly" all required dlls (there are quite a lot of .net libs). However, upon executing one of the installed exe files on a target computer, I am getting:
It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '3.0.0' was not found.
- Check application dependencies and target a framework version installed at:
C:\Program Files\dotnet
- Installing .NET Core prerequisites might help resolve this problem:
https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
- The .NET Core framework and SDK can be installed from:
https://aka.ms/dotnet-download
- The following versions are installed:
2.2.7 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
I know, I could create a gigantic self-contained .exe when publishing the .exe files, however, that seems kind of wasteful to me - creating two gigantic .exe files that contain mostly the same .dlls anyways.
Is there no way to include a .NET Core 3 setup in the installer project as well? I can't find anything on that topic on the internet...

I found this as had same problem, but eventually worked out if you set the publishProfilePath setting in the Installer Project it will include all the files and works fine.

For me replacing PrimaryOutput with PublishItemsOutputGroup works fine, when it comes to gathering the dependencies.
Unfortunately it does not allow referencing those outputs inside the installer. E.g. if you want to run custom actions or create Shortcuts during the installation, it does not work. The outputs are not available.

Visual Studio 2017 - Potentially unneeded dlls in release folder

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

Microsoft .NET Framework missing during making exe setup file form project

During making setup file i am getting these errors i think all problem is due to missing of .net Framework in dependencies folder

The problem is not with your .net framework. Its with your version of log4net. The version you have included is exclusive to x64 systems while you are trying to make a installer that works with x86 systems.
Either switch your project architecture to x64 (you can do this in the build properties of your project file). Or find a version of log4net that allows for x86 execution.

Dotnet 4.0 upgrade from 2.0

i am working on a dotnet C# web application which was initially created with VS 2003. My goal is to upgrade this application to Dotnet 4.0 without changing any functionaltiy. The solution has 9 projects (1 web + 8 Library projects). The Web project refers the 8 libraries in DLLs. To start off, I created a New project in VS2010 and added the all the Project files from the existing source code. Every time i add a project file to my solution, i was prompted with the Converison wizard and i completed the conversion wizard succesfully and now the solution works fine. After the conversion, i noticed that Except the "Web" project, other projects are converted to Dotnet 2.0 but not 4.0. My application runs without error if i run it locally using VS2010. My questions are
Why the Class libaray project did not upgrade to 4.0? Currently the
Web project is shows up as Dotnet 4.0 and Libaray projects shows up
as Dotnet 2.0.
Can i deploy the application to IIS 7.0 with the
Dotnet runtime of 4.0? Will the Dlls created in version 2.0 work if my application
uses Dotnet 4.0 runtime version?
Please help...

If your'e migrating now, why not move directly to Visual Studio 2012, instead of 2010?
Anyway, what you can do is open the project properties in each of your projects, and change the target framework to the .NET framework 4.0.
Then if you get any compilation error you can probably easily solve it individually. This should be relatively easy if your projects are not too big.
As for your specific questions:
The automatic conversion would only change the format of the solution/projects to be compatible with the new version Visual Studio. It shouldn't change the target framework but you can change that yourself.
Yes, assemblies targeting .NET 2.0 can be loaded and used from assemblies targeting .NET 4.0.

1) Upgrading the solution/projects file only upgrades it's format so you can open it in VS 2010. It will usually leave the targeted .NET setting at the previous value. These are two seperate things. The wonderful thing about VS 2010 is it let's you target whatever version of .NET you desire, so no longer do you need multiple version of VS installed to support differnt .NET versions. It didn't change the targetted .NET version because it leaves it up to you. You can change it under the project settings and recompile your library projects to regenerate the DLLs
2) You will need an application pool for .NET 4. .NET is backwards compatible in that a .NET 2.0 app can run on a machine with .net 4 installed. However, the application pool for 2.0 applications must be separate from 4.0 apps. So it's just a matter of putting the app under the right app pool.