1

We have a project that creates a set of libraries that are later included in some external projects. Due to some conflicts (that happened when these external projects were used together) we were made to create a separate set of libraries dedicated specifically to a given project.

We end up with multiple conditions in our project file, e.g.:

  <PropertyGroup Condition=" '$(DestinationName)' == 'Name1' ">
    [...]
    <AssemblyName>Name1-OurProject</AssemblyName>
    <Version>1</Version>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(DestinationName)' == 'Name2' ">
    [...]
    <AssemblyName>Name2-OurProject</AssemblyName>
    <Version>2</Version>
  </PropertyGroup>

And then we have to build separately for each external project:

dotnet build -property:DestinationName="Name1"
dotnet build -property:DestinationName="Name2"

Which means we build the exact same code multiple times.

Is there any way to avoid this? To somehow notify dotnet build that I need multiple library sets?

Piotrek
  • 169
  • 3
  • 17
  • 3
    Wait what?? The dog wags its tail, not the other way round. If you start tailoring your lib to different clients, then it is no longer _one_ library. That will result in maintainance hell. You may want to explore how to create and use NuGets of your libs. Then you can "fix" versions more easily, if different clients cannot keep up with just the "current" version. – Fildor May 26 '23 at 14:32
  • If you need something like different adapters to subsystems (for example client1 uses MSSqlServer, while client2 uses Postgres) you may want to consider to factor those differences out in satellite-libs, that can be combined as needed. That's a common pattern seen in nuget packages. You'd have a "core" package and then different adapters to support different DBs, different DI systems, different logging systems ... you name it. – Fildor May 26 '23 at 14:56
  • Is there no way to consolidate into one class library that can be built once and referenced all over, which handles differences through something like dependency injection, method overloads, etc? This sounds like maintenance hell already – Narish May 26 '23 at 14:56
  • I'm curious to what the conflict is but completely agree you should package it and maintain a single code base. Different clients can reference the same version because a package is an exclusive copy to the project referencing it. – hector-j-rivas May 26 '23 at 18:14

0 Answers0