Microsoft недавно выпустила рекомендации по созданию .NET-библиотек:
https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/

Например:
✔️ DO include a netstandard2.0 target if you require a netstandard1.x target.
✔️ CONSIDER adding a target for net461 when you're offering a netstandard2.0 target.
✔️ CONSIDER adding the strong naming key to your source control system.
✔️ CONSIDER incrementing the assembly version on only major version changes to help users reduce binding redirects, and how often they're updated.
✔️ CONSIDER embedding symbol files in the main NuGet package.
✔️ DO reference shared source packages with PrivateAssets="All".
✔️ CONSIDER testing packages in your development environment using a local feed or MyGet. Check the package works then publish it to NuGet.org.
✔️ CONSIDER only including a major version in the AssemblyVersion.
❌ AVOID setting the assembly informational version yourself.
✔️ CONSIDER using abstract base classes instead of interfaces.

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

Q>Microsoft недавно выпустила рекомендации по созданию .NET-библиотек:
Q>https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/

❌AVOID NuGet package references that demand an exact version.

Вот у меня есть вспомогательная библиотека, версии которых могут быть несовместимы друг с другом.

Поэтому в другом NUGET-пакете, который использует это либу, указываю точную версию:

    <dependencies>
      <dependency id="MY.lib" version="[$D_MY_LIB_VERSION$]" />
    </dependencies>

Во избежание.

Или это про другое?

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>❌AVOID NuGet package references that demand an exact version.
КД>Или это про другое? :???:

Это скорее про то, что вместо точных версий лучше указывать диапазоны. Скажем, твоей библиотеке подходит версия 1.3.2, а 2.0.0 уже не подходит. Тогда вместо указания точной версии [1.3.2] лучше указать открытый справа диапазон: [1.3.2, 2.0.0). Тогда у тебя по-прежнему не будет проблемы с версией 2.0.0 (она не входит в диапазон), но старую версию при необходимости всё ещё можно обновить до совместимой 1.3.3 (точная версия не прибита).

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

Q>Microsoft недавно выпустила рекомендации по созданию .NET-библиотек:
Q>https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/

✔️ CONSIDER adding a target for net461 when you're offering a netstandard2.0 target.

Using .NET Standard 2.0 from .NET Framework has some issues that were addressed in .NET Framework 4.7.2. You can improve the experience for developers that are still on .NET Framework 4.6.1 — 4.7.1 by offering them a binary that is built for .NET Framework 4.6.1.

Я правильно понял — если предлагаете сборки для Std 2.0, то желательно предлагать и сборки для FW4.6.1?

А как эти две вещи связаны друг с другом?

Я где-то видел, что Std 2.0 является(?), грубо говоря, подмножеством FW4.6.1. Но раз оно им является, то зачем добавлять еще и поддержку FW4.6.1?

У меня уже какая-та путаница в голове возникла

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>

КД>Using .NET Standard 2.0 from .NET Framework has some issues that were addressed in .NET Framework 4.7.2. You can improve the experience for developers that are still on .NET Framework 4.6.1 — 4.7.1 by offering them a binary that is built for .NET Framework 4.6.1.

КД>Я правильно понял — если предлагаете сборки для Std 2.0, то желательно предлагать и сборки для FW4.6.1?

Я тоже так понял. Что за «some issues» — непонятно.

КД>Я где-то видел, что Std 2.0 является(?), грубо говоря, подмножеством FW4.6.1.

Я читал когда-то про какие-то мелкие несоответствия, типа трёх с половиной методов из многих тысяч, что входят в netstandard, но не реализованы в .NET 4.6. Но деталей не помню.

КД>Но раз оно им является, то зачем добавлять еще и поддержку FW4.6.1?.. У меня уже какая-та путаница в голове возникла :)

Вот потому что эта рекомендация какая-то неочевидная, я её и отобрал в «например» :) Равно как и то, что если достаточно netstandard1.*, то всё равно желательно включить также и netstandard2.0.

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>У меня уже какая-та путаница в голове возникла :)

Я в свою очередь не могу понять насчёт symbol packages и Source Link. В разных местах указана противоречивая информация:
https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/nuget#symbol-packages
https://docs.microsoft.com/en-us/nuget/create-packages/symbol-packages

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

Q>Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>>У меня уже какая-та путаница в голове возникла

Q>Я в свою очередь не могу понять насчёт symbol packages и Source Link. В разных местах указана противоречивая информация:
Q>https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/nuget#symbol-packages
Q>https://docs.microsoft.com/en-us/nuget/create-packages/symbol-packages

Я не знал, что они уже и исходники предлагают в пакеты засовывать

А, ну да, это же рекоммендации для OpenSource.

Здравствуйте, Коваленко Дмитрий, Вы писали:

Я в свою очередь не понял:

✔️ CONSIDER strong naming your library's assemblies.

✔️ CONSIDER adding the strong naming key to your source control system.

Это все перемеживается, как круто, что у нас есть GAC...

✔️ CONSIDER incrementing the assembly version on only major version changes to help users reduce binding redirects, and how often they're updated.

А потом, если ваша библиотека достаточно популярная, и внезапно вы столкнетесь, с тем, что у пользователя в GAC установлена непойми кем непойми какая 1.0.0.0 версия, и валится оно непойми чего, есть дельные советы по решению:

❌ DO NOT add, remove, or change the strong naming key.

Или собирать себе со своим ключем:

❌ DO NOT publish strong-named and non-strong-named versions of your library. For example, Contoso.Api and Contoso.Api.StrongNamed.

Илм просто выставлять в AssemblyVersion таки версию...

Здравствуйте, Коваленко Дмитрий, Вы писали:

Q>>Я в свою очередь не могу понять насчёт symbol packages и Source Link.

КД>Я не знал, что они уже и исходники предлагают в пакеты засовывать :)

Я всё понял. Можно привязать пакет к исходникам (и к конкретному коммиту) в GitHub (или BitBucket, или ещё пара источников).

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

MA>✔️ CONSIDER incrementing the assembly version on only major version changes to help users reduce binding redirects, and how often they're updated.

MA>А потом, если ваша библиотека достаточно популярная, и внезапно вы столкнетесь, с тем, что у пользователя в GAC установлена непойми кем непойми какая 1.0.0.0 версия, и валится оно непойми чего, есть дельные советы по решению:

Навеяло, у меня тут один товарищ недавно всплыл — решил обновить бинарник (плюсы) 2001 года. Сильно переживал, что "новая" версия не сможет работать как старая.

Смогла

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


Q>✔️ CONSIDER using abstract base classes instead of interfaces.

А это почему?

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

Q>>✔️ CONSIDER using abstract base classes instead of interfaces.
SO_>А это почему?

Расширение интерфейса — ломающее изменение, потому что добавленные методы отсутствуют в существующих пользовательских реализациях интерфейса. А добавление виртуальной функции с дефолтной реализацией — нет.
«Adding anything to an interface will cause existing types that implement it to fail. An abstract base class allows you to add a default virtual implementation.»

В C# 8 это собираются исправить: https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md
«Default interface methods enable an API author to add methods to an interface in future versions without breaking source or binary compatibility with existing implementations of that interface.»

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


Q>Расширение интерфейса — ломающее изменение, потому что добавленные методы отсутствуют в существующих пользовательских реализациях интерфейса. А добавление виртуальной функции с дефолтной реализацией — нет.
Q>«Adding anything to an interface will cause existing types that implement it to fail. An abstract base class allows you to add a default virtual implementation.»

Забавно, всегда считал это преимуществом интерфейсов.

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

SO_>Забавно, всегда считал это преимуществом интерфейсов.

Интерфейсы никто не отменяет, они по-прежнему нужны. Хотя бы потому что допускают множественное «наследование» и могут служить констрейнтами дженериков. Поэтому в рекомендации стоит модальность CONSIDER, а не DO — просто чтобы читатели рассмотрели этот неочевидный вариант.

Другое преимущество абстрактных базовых классов — они позволяют изолировать интерфейс вызова (публичный интерфейс для клиентов) от интерфейса настройки (непубличный интерфейс для имплементаторов). В C++ это называют паттерном NVI.