How to reference private library in debug/release mode

Question

0.00/5 (No votes)

See more:

, +

Hi all,
first time asking a question but I wasn't able to find a solution to my problem yet.

We are starting a new project in .NET and we choose to divide it in differente libraries to maintain it easily. Or so we hope.

To keep it as simple as possible we have different libraries structured this way:

Library A, include a NuGet package (e.g. Serilog)
Library B, references to dll A
Running program C, references to dll B

If we try to reference directly in program C -> library B we get a FileNotFoundException while running the program because libraries don't include all references inside. But we don't want to reference all manually.

The alternative seems to be using NuGet packages but this seems quite over-complicated to our needs.

We should use a local repository where export or create packages and then reference them from there. We haven't found a way to specify the path for package creation and we don't know how to refer debug version of libraries while compiling in debug mode and release version while compiling the release version.

I'm afraid this isn't very clear. Hope someone can understand and help.

What I have tried:

This is what we tried using dlls.

<ItemGroup Condition=" '$(Configuration)' == 'Debug' ">
		<Reference Include="Core">
			<HintPath>..\..\Core\Core\bin\Debug\net5.0\Core.dll</HintPath>
		</Reference>
	</ItemGroup>

	<ItemGroup Condition=" '$(Configuration)' == 'Release' ">
		<Reference Include="Core">
			<HintPath>..\..\Core\Core\bin\Release\net5.0\Core.dll</HintPath>
		</Reference>
			<HintPath>..\..\..\Services\Logging\Logging\bin\Release\net5.0\Logging.dll</HintPath>
		</Reference>
	</ItemGroup>

Posted 25-Jul-21 21:36pm

acalafiore

Updated 28-Jul-21 2:47am

Add a Solution

2 solutions

Solution 1

.NET optimizes out library references where they haven't been used. So if your "LibraryA" references a particular package but chooses not to use it, it may be optimized out of the DLL when compiled in release mode.

I think the correct approach is to have each project have references to the packages they need, and not depend on dependencies providing them for it. If your "LibraryA" includes a package but it is made redundant in the future, it may be removed from that library and inadvertently break your other projects.

If you want to apply NuGet package references across all projects within your solution you can actually add them to the Directory.Build.props file in the root of the solution directory. This file will apply common properties to all projects in the solution, so if you need logging in all of them then add the dependencies here.

Customize your build - MSBuild | Microsoft Docs[^]

Posted 25-Jul-21 23:15pm

Chris Copeland

Comments

acalafiore 27-Jul-21 2:28am

I'll take a look at solution level configuration, but I would like to avoid having a big solution with all projects.

My Library A is just a wrapper for Serilog for easier configuration and hiding namespace. But when Library B tries to log in Program C it launches a FileNotFoundException on Serilog package. This happens when I directly reference LibraryA.dll from LibraryB project.

Chris Copeland 27-Jul-21 4:15am

If you're getting the FileNotFoundException for the Serilog assembly name then you absolutely have to add a NuGet reference to it for your executable file. VS projects aren't always magical in resolving which dependencies are needed for which projects, and especially as you chain more dependencies together (ie. A -> B -> C). You probably don't need to add Serilog to your "B" library, just to the project executing the code.

acalafiore 27-Jul-21 4:23am

I know I can solve it this way but I don't really like it. The idea is you don't have to know what packages are used inside libraries while using them.
But maybe this is impossible.

Chris Copeland 27-Jul-21 5:55am

The reason NuGet exists is to try and resolve some of these referencing hellscapes. With NuGet packages you can clearly and distinctly provide all referenced dependencies, however with Project References you're dependent on the linker to work everything out. The release mode builds are notorious for optimizing out code and dependencies it doesn't think are being used, even if they are (imagine trying to reflectively load an assembly but the build removes it as being unused!)

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

acalafiore · Accepted Answer · 2021-07-28T02:47:00

Solution 2

I have chosen to include in each solution the project needed for references. This way there are no missing libraries while running.

Not really what I wanted but it's the easiest way.

Posted 28-Jul-21 2:47am

acalafiore