Is it possible to reference a project that exists in the solution and use NuGet package reference as fall-back if not in .NET Core?

Question

I have an .NET Standard project where I implemented a module for an ASP.NET Core CMS framework. Currently, it uses the CMS framework libraries coming from NuGet packages. If I grab the source code of the CMS framework from GitHub and add my module to its solution and replace the package references to the actual project references it will work fine.

My goal is to make it work without updating the references in the csproj file so if the project is added to the full source code solution then use the project references, otherwise use the NuGet package references.

So let's say the .NET Standard project is called 'ModuleA'. It has a package reference to 'ModuleB':

<ItemGroup>
  <PackageReference Include="ModuleB" Version="1.0.0" />
</ItemGroup>

When I want to use ModuleA in a solution where ModuleB is accessible then I use project reference to it:

<ItemGroup>
  <ProjectReference Include="..\..\ModuleB\ModuleB.csproj" />
</ItemGroup>

I'd like to include both of them in the .csproj file somehow and make it to use the proper references on build (e.g. based on some conditions like project exists?).

If both are added to the csproj then the build will fail (e.g. 'Unable to find project ...ModuleB.csproj. Check that the project reference is valid and that project file exists.').

Answer 1

You could do that probably dynamically, but I think it's not really transparant how that would work.

I would recommend to add a configuration, e.g. in my example "Local-Debug" and use conditions in your csproj.

Example

Creating the configuration:

And in your csproj you could do this:

<ItemGroup>
  <ProjectReference Condition="'$(Configuration)' == 'Local-Debug'" Include="otherProject.csproj" />
  <PackageReference Condition="'$(Configuration)' != 'Local-Debug'" Include="otherProjectPackage" Version="2.4.1" />
</ItemGroup>

Answer 2

Your dependencies must be statically known and resolve-able at build-time. See @Julian's answer for a good config-driven build-time solution.

As a run-time solution: You can dynamically load your references at run-time. This way, you can search for the DLL you need in the working directory of your app and if you don't find it there, then download it (from Nuget or elsewhere), either as a binary that you can directly load, or as a source that you can build; and then load that library dynamically.

Here's how you can load an assembly dynamically (at run-time): https://docs.microsoft.com/en-us/dotnet/api/system.reflection.assembly.loadfrom?view=netframework-4.8

And this question: Loading library dynamically

Coding against a dynamically loaded assembly has its own quirks; you will need clear interface definitions for the referenced library, or else, you'll find yourself dealing with a lot of reflection and dynamics.