Reputation: 15475
I have a simple WPF program that calculates the sum of 2 numbers.
When I build the application it produces a bunch of DLLs in the bin folder.
I did a test where I just took the .exe file and the one .dll file and copied to another location and tried running and it worked fine.
Even the console app has a bunch of the DLLs in bin output. I was just expecting the one ClassLibrary1 dll and the .exe file.
Why all the DLLs?
Upvotes: 2
Views: 1880
Reputation: 155418
Your ClassLibrary1
project targets .NET Standard, which means it has those extra DLLs in case it needs to run on other .NET Standard-compatible platforms besides .NET Framework for Windows that don't have those libraries/packages included by default. You'll notice that those extra DLLs will generally correspond to other NuGet packages that are implicitly or explicitly referenced by your ClassLibrary1
project.
By default, when a project X references another project Y, then building X will pull-in all of Y's dependencies, even if they aren't needed on X's targeted .NET platform. There are ways to prevent this happening but that's another question.
BTW, while .NET Framework 4.6.1 is ostensibly compatible with .NET Standard 2.0, there are many problems you'll run-into with other NuGet packages and assembly/module-binding or loading - so generally speaking it's best to always target the latest .NET Framework version (4.8 or at least 4.7.2) when using .NET Standard 2.0.
I don't feel there's any reason to target .NET 4.6.1 today: it's already 4 years old, and any computer capable of running .NET 4.6.1 (i.e. Windows 7 SP1 or later) is also capable of running .NET Framework 4.8 (excepting Windows versions not currently supported by Microsoft, such as Windows Vista and Windows 8.0, but Windows 8.1 is fine).
Upvotes: 4