3

In the "old days" of C++, you had two options for creating a (class or otherwise) library - DLL or static linkable.

I have some projects in my solution that are "shared" libraries to be used by two or more other projects in the same solution. Right now, they are being exported as DLLs which are then faithfully copied to the 'bin' folder of every single one of the actual executables that are using them.

I'm tired of seeing all of these DLLs running around (for both my libraries and Nuget-provided third-party libraries) and I would actually prefer to "link them in" to the executables, if there is a .NET way of doing so (short of just putting the code in separate folders and including them in all of the projects, which is kind of ugly with respect to making it obvious what is going on in by inspection of the Solution Explorer).

So - is "linking" libraries dead and gone with .NET? If so, is there at least a way of registering assemblies (the way we used to register COM DLLs in the past) so there is only a single copy of the DLL in cases where more than one of the executables in the solution is installed instead of having the same DLLs replicated in multiple places?

Blorgbeard
  • 101,031
  • 48
  • 228
  • 272
JackLThornton
  • 375
  • 3
  • 14
  • 2
    Look at ILMerge. – SLaks Dec 20 '17 at 21:55
  • 1
    How is statically linking much different from having a separate copy of the DLL for each executable? The size increases either way. If you want a central place for your DLL-s, put them in the GAC. A separate DLL can, at least, be updated as needed (assuming compatibility is maintained). – xxbbcc Dec 20 '17 at 21:59
  • Sharing a single DLL in multiple programs is well supported in .NET. Works the exact same way it does in C++, although unmanaged SxS is very rarely used in practice. You install it in the GAC. The equivalent of static linking, repeating the same code over and over again for every executable that uses the library, as wasteful as that seems, is supported by the ILMerge utility. You get to choose your DLL Hell preference. The default .NET way is to assume that disk storage is not a problem anymore today. It is not. – Hans Passant Dec 20 '17 at 22:55

2 Answers2

5

AFAIK .NET (and the CLR) don't have the notion of statically linked libraries.

As SLaKs points out, there are tools to fool with the IL, but you'd need to weigh the cost of this added complexity to the benefit of simply reducing the number of DLL files floating around; is it really that important?

Instead, you can use a "Shared Project", at least since Visual Studio 2015.

Shared Project

It simply acts as a reference-able container for common code/resources, which is pretty close to the result you're looking to achieve.

See "What is the difference between a Shared Project and a Class Library in Visual Studio 2015?".

As per SLaKs, also see "Static Linking of libraries created on C# .NET".

Dan Lugg
  • 20,192
  • 19
  • 110
  • 174
0

Actually, I discovered a "work-around" that gives me much the effect I want. The Costura.Fody Nuget package collects everything necessary (including all the DLLs that are normally copied into the bin/[configuration] folder) into resources in your final executable at compile-time.

I'm going to mark another answer, as it is spot on point for my original question; however, if anyone else comes looking, they may want to consider the Costura.Fody package if it meets what they want to accomplish.

JackLThornton
  • 375
  • 3
  • 14