6

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.').

Julian
  • 33,915
  • 22
  • 119
  • 174
Márk Bartha
  • 109
  • 3
  • I don't think you can do this. But then again, I can't work out why you want/need to? What advantage do you get? And when/how would there be a case when the project wasn't present without your prior knowledge as the developer? Adding a project reference (manually or via NuGet) isn't really a hard task, and it should also be a fairly infrequent one. I'm trying to imagine a scenario where you'd want to keep swapping between them but I can't – ADyson Jun 22 '19 at 19:06
  • One reason for this is so the project reference is there when he's coding, but when a build pipeline is running it is able to resolve the references and pull the packages – PlantationGator Nov 04 '21 at 13:37

2 Answers2

8

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:

enter image description here

enter image description here

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>
Julian
  • 33,915
  • 22
  • 119
  • 174
  • 1
    While this is best solution, this still requires manual involvement - what OP wants to eliminate. – Fabio Jun 23 '19 at 06:17
1

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://learn.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.

Arash Motamedi
  • 9,284
  • 5
  • 34
  • 43