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
Related
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.
My computer only has VS2019 installed with .net versions up to 4.8. I'm attempting to use the Microsoft.Build.Construction assemblies in a program i'm working on. When i go to add the reference->Assemblies, the only versions i have are 4.0.0.0. Based on my research, VS stopped adding assemblies to the GAC, so i'm forced to manually add the DLL from C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin in order to utilize the Version 15.1.0.0 that at least supports the SolutionFile calls.
So my question is this: should i push those versions to the GAC in order to be able to use them, or is there a better way to access non-GAC assemblies than how i did.
For MSBuild assemblies, you must follow the guidance of Microsoft strictly to avoid all side efforts. In general, the NuGet packages are recommended.
Change MSBuild references
To make sure that MSBuild loads from a central location, you must not distribute its assemblies with your application.
The mechanism for changing your project to avoid loading MSBuild from a central location depends on how you reference MSBuild.
Use NuGet packages (preferred)
For detailed information, please check out the long reference
Forget the GAC, just take the DLL in the Bin folder, copy it to your project folder in /References, and reference it from there. This way if you use version control, the specific version of the DLL follows the source code.
EDIT: As mentioned by Lex below, this is not a suitable solution for MSBuild assemblies, you should use the Nuget package instead.
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.
Last year, I asked the question how to solve a DllNotFoundException for sharpdx_direct3d11_effects_x64.dll with SharpDX.Direct3D11.Effects.dll version 3
Now I'm trying the same thing with version 4.
I was expecting the two DLLs sharpdx_direct3d11_effects_x64.dll and sharpdx_direct3d11_effects_x32.dll to be added to the Visual Studio project but they are not.
Has the deployment mechanism for these two DLLs changed?
Has the deployment mechanism for these two DLLs changed?
Yes, the author of this package xoofx has changed deployment mechanism for these two DLLs from the version 4.0.0-ci120. You can check the the 4.0.0 release notes about Updated D3D11.Effects to the new project system..
Besides, you can download two version of this packages, check the different with NuGet Package Explorer:
According to the official document: Supporting multiple .NET framework versions:
If you have architecture-specific assemblies, that is, separate assemblies that target ARM, x86, and x64, you must place them in a folder named runtimes within sub-folders named {platform}-{architecture}\lib{framework} or {platform}-{architecture}\native.
So the change in the deployment mechanism is correct.
OK I got this to work thanks to #Leo-MSFT's answer above.
I had to download the NuGet package from here.
Rename to *.zip and unzip
Copy the folders runtime/win-x64/sharpdx_direct3d11_1_effects.dll and runtime/win-x86/sharpdx_direct3d11_1_effects.dll to my project and set to Copy Always
This didnt' work so I now copied win-x64/sharpdx_direct3d11_1_effects.dll to the project root and renamed as win-x64/sharpdx_direct3d11_1_effects_x64.dll and set to Copy Always and it worked.
I'm sure this isn't intentional so I've reported a bug to SharpDX on Github.
Project1: A C++ EXE project with code
generation option "runtime library" set to
"Multithreaded Debug Dll".
Project2: A C# EXE project developed
with .Net Version, say, 3.5
Suppose I want to write an installer project for these projects. I naturally include their primary outputs (the exe's) in the installation package. But the exe's are not sufficient to ensure that they will be runnable on the target machine. In case of project1 we will need msvcrt.dll and possibly others(not sure), and, in case of project2 we will need the .NET framework of the corresponding version. The question is, is it possible to make the installation package automatically include those? If it is not, how is it best done manually? TIA.
It is already automatic afaik. Every time I tinkered with a Setup project, it already figured out the prerequisites from the projects I added. From your Setup project, use Project + Properties and click Prerequisites. Verify that the right Visual C++ Runtime Libraries and .NET Framework are ticked.