Здравствуйте, MadHuman, Вы писали:

MH>Если явно в Б цеплять туже версию пакета Л что и в А, то когда в А версию Л изменят, надо изменить и в Б

Совсем не обязательно. Во-первых, в Б цеплять Л зачастую необязательно, так как нужная версия будет подтягиваться автоматически. По-крайней мере так <PackageReference> работает в SDK-style проектах.

Во-вторых, можно в Б цеплять более новые версии Л, а в А исповедовать аскетичный консерватизм — цеплять минимальную и достаточную версию Л. Тогда всё происходит как по маслу без каких-либо лишних телодвижений со стороны того, кто использует А.

Здравствуйте, MadHuman, Вы писали:

MH>присоединяюсь к аргументам предыдущего оратора, референсить так или иначе надо. так как методы А возвращают типы из Л, и их надо использовать в Б.

Это только в старых проектах .NET Framework так. Но если переехать на новые SDK-style проекты которые используются начиная с .NET Core, то там такие неявные зависимости подтягиваются автоматически и ссылаться явно на них не требуется. SDK-style проекты также умеют работать и с .NET Framework. Вот тулза для конвертации форматов проектов.

НС>Непонятен вопрос. Просто не прописываешь в проекте ссылку на L, только ссылку на А.
присоединяюсь к аргументам предыдущего оратора, референсить так или иначе надо. так как методы А возвращают типы из Л, и их надо использовать в Б.

Здравствуйте, Xander Zerge, Вы писали:
XZ>Так мне из А вернут объект, описанный в L. Я как только вызов такого метода пропишу, мне компилятор скажет — включай L.
Хм. А кто-то ещё напрямую с компилятором такие темы обсуждает?
Я думал, что в 2022 все собирают через msbuild или dotnet CLI.
В обоих случаях транзитивные зависимости обслуживаются автоматически.
А требование сослаться на L возникает только тогда, когда не получается автоматически выбрать версию L, которая бы устроила и А и Б.

Здравствуйте, Sinclair, Вы писали:

S>>>Я думал, что в 2022 все собирают через msbuild или dotnet CLI.
MH>>собирают из студии, студия как я понимаю и так msbuild запускает для этого, разве нет?
S>АФАИК, в студии свой сборщик, альтернативный msbuild-ному.
нет, студия пользуется именно msbuild

S>Но это неважно — в обоих случаях никто не вызывает csc.exe напрямую, скармливая ему список референсов.
S>Билд-системе скармливается целиковый файл проекта или солюшна, а уже она занимается резолвингом депендов и, в том числе, рекурсивными референсами при необходимости.
да, студия запускает msbuild для билда солюшена, и если в проекте (старого формата) нет было референса на либу Л (как в стартовом топике), то возникала ошибка компиляции (ну и естественно при билде).
я не вызываю руками csc.exe напрямую, речь шла о штатном процессе сборки солюшена через студию.
как уже тут посоветовали, если обновить формат проект на новый sdk-style то действительно становится не нужным руками подцеплять транзитивный референс Л в проекте Б, оно при сборке само разруливается.

Всех привествую!

Есть проект либа А, в неё подцеплен PackageReference (нугет пакет) на стороннюю либу Л, причем на конкретную версию Л.
Есть ещё наш проект Б, использует проект А, а внутри ему надо референс на либу Л туже что и в А.

Если явно в Б цеплять туже версию пакета Л что и в А, то когда в А версию Л изменят, надо изменить и в Б (на самом деле таких Б в солюшене много) поэтому это не удобно.
Есть ли способ такое организовать лучше чем в варианте выше? Чтоб в Б автоматом использовался референс на туже либу Л что и в А..

Здравствуйте, MadHuman, Вы писали:

MH>Есть ли способ такое организовать лучше чем в варианте выше? Чтоб в Б автоматом использовался референс на туже либу Л что и в А.

https://learn.microsoft.com/en-us/nuget/consume-packages/central-package-management
https://devblogs.microsoft.com/nuget/introducing-central-package-management/
https://blog.jetbrains.com/dotnet/2022/11/07/nuget-central-package-management-comes-to-jetbrains-rider/

Здравствуйте, MadHuman, Вы писали:

MH>Всех привествую!

MH>Есть проект либа А, в неё подцеплен PackageReference (нугет пакет) на стороннюю либу Л, причем на конкретную версию Л.
MH>Есть ещё наш проект Б, использует проект А, а внутри ему надо референс на либу Л туже что и в А.

MH>Если явно в Б цеплять туже версию пакета Л что и в А, то когда в А версию Л изменят, надо изменить и в Б (на самом деле таких Б в солюшене много) поэтому это не удобно.
MH>Есть ли способ такое организовать лучше чем в варианте выше? Чтоб в Б автоматом использовался референс на туже либу Л что и в А..

если корэ, то там можно в корне репозитория создать msbuild-вый таргетс и его уже инклудить во все проекты.
есть даже тулза такая paket, но можно и без нее.
в старом дотнете возможно также попробовать, но там как-то все сложно получается.

Здравствуйте, MadHuman, Вы писали:

MH>Если явно в Б цеплять туже версию пакета Л что и в А, то когда в А версию Л изменят, надо изменить и в Б

Необязательно, по крайней мере если мажорная версия не менялась. Но будет варн при сборке.

MH>Есть ли способ такое организовать лучше чем в варианте выше? Чтоб в Б автоматом использовался референс на туже либу Л что и в А..

Есть. Вообще не референсить Л в Б.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Есть. Вообще не референсить Л в Б.

А как?
Вот есть сторонняя либа Л, скажем какой-нить коннектор к данным, и его DTO внутри.
К ней написали набор расширений А, которым пользуется в том числе Б.
То есть Б потребляет DTO, которые рожаются в Л, но попадают через А.
Как не референсить Л? Разве что дублировать DTO из Л в А?

Здравствуйте, Xander Zerge, Вы писали:

НС>>Есть. Вообще не референсить Л в Б.
XZ>А как?

Непонятен вопрос. Просто не прописываешь в проекте ссылку на L, только ссылку на А.

Здравствуйте, MadHuman, Вы писали:

MH>Если явно в Б цеплять туже версию пакета Л что и в А, то когда в А версию Л изменят, надо изменить и в Б (на самом деле таких Б в солюшене много) поэтому это не удобно.

Framework или .NET? В Framework обычно достаточно разрешить использовать самую новую версию вот так:

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Еще можно подумать над включением сборок в GAC.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Непонятен вопрос. Просто не прописываешь в проекте ссылку на L, только ссылку на А.
Так мне из А вернут объект, описанный в L. Я как только вызов такого метода пропишу, мне компилятор скажет — включай L.

Здравствуйте, Sinclair, Вы писали:

S>В обоих случаях транзитивные зависимости обслуживаются автоматически.
S>А требование сослаться на L возникает только тогда, когда не получается автоматически выбрать версию L, которая бы устроила и А и Б.
Хм. Надо попробовать. Точно помню, что было как-то дело, что билд не собирался, и там дело было не в версиях, а просто не хватало такой зависимости, и автоматически она не разруливалась.

Здравствуйте, Aquilaware, Вы писали:


A>Это только в старых проектах .NET Framework так. Но если переехать на новые SDK-style проекты которые используются начиная с .NET Core, то там такие неявные зависимости подтягиваются автоматически и ссылаться явно на них не требуется. SDK-style проекты также умеют работать и с .NET Framework.
вот это интересно, спасибо. у меня старый проект .NET Framework, но думаю можно сконвертить его к sdk-стайл ничего не мешает, надо попробывать

Здравствуйте, Shmj, Вы писали:

S>Framework или .NET? В Framework обычно достаточно разрешить использовать самую новую версию вот так:

Это инструкция для рантайма. А здесь речь про сборку.

Здравствуйте, Sinclair, Вы писали:

S>Хм. А кто-то ещё напрямую с компилятором такие темы обсуждает?
S>Я думал, что в 2022 все собирают через msbuild или dotnet CLI.
собирают из студии, студия как я понимаю и так msbuild запускает для этого, разве нет?

Здравствуйте, MadHuman, Вы писали:

S>>Я думал, что в 2022 все собирают через msbuild или dotnet CLI.
MH>собирают из студии, студия как я понимаю и так msbuild запускает для этого, разве нет?
АФАИК, в студии свой сборщик, альтернативный msbuild-ному.
Но это неважно — в обоих случаях никто не вызывает csc.exe напрямую, скармливая ему список референсов.
Билд-системе скармливается целиковый файл проекта или солюшна, а уже она занимается резолвингом депендов и, в том числе, рекурсивными референсами при необходимости.

Здравствуйте, MadHuman, Вы писали:
S>>АФАИК, в студии свой сборщик, альтернативный msbuild-ному.
MH>нет, студия пользуется именно msbuild
Ну... У меня есть проект, который существенно по-разному собирается из студии по Ctrl+Shift+B и через msbuild command prompt.
Даже разными компиляторами. Поэтому позволю себе усомниться.

MH>да, студия запускает msbuild для билда солюшена, и если в проекте (старого формата) нет было референса на либу Л (как в стартовом топике), то возникала ошибка компиляции (ну и естественно при билде).
MH>я не вызываю руками csc.exe напрямую, речь шла о штатном процессе сборки солюшена через студию.
MH>как уже тут посоветовали, если обновить формат проект на новый sdk-style то действительно становится не нужным руками подцеплять транзитивный референс Л в проекте Б, оно при сборке само разруливается.
Да, это удобнее, хотя и не факт, что лучше — вдруг кому-то захочется иметь явный контроль за всеми зависимостями, которые тянутся в проект.