Click here to Skip to main content
15,030,240 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
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
Updated 28-Jul-21 2:47am

.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[^]
   
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!)
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.
   

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




CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900