У меня хорошие и плохие новости. Хорошая новость заключается в том, что проблема связана с вашим пакетом, и все работает так, как вы считаете, что оно должно работать. Плохая новость в том, что я не знаю, как ваш пакет был неправильно создан.
Шаги для проверки: Загрузите Panner.Order версию 1.1.0 с nuget.org (вы опубликовали 1.1.1 с тех пор, как задали эти вопросы). , которая имеет ту же, но другую, проблему). Если у вас установлен NuGet Package Explorer , откройте с ним nupkg, разверните папку lib/ и дважды щелкните каждый из файлов .dll. В качестве альтернативы вы можете извлечь nupkg в виде zip-файла, а затем использовать ILSpy или ILDasm или все, что вы хотите для проверки сборок. Обратите внимание, что обе сборки netstanard2.0 и netcoreapp3.0 имеют одинаковые ссылки на сборки. В частности, ссылка на Microsoft.EntityFrameworkCore.dll относится к версии 2.2.6.0, хотя мы ожидаем, что версия netcoreapp3.0 будет использовать версию 3.0.0.0. Поэтому я пришел к выводу, что ваша сборка netstandard2.0 была неправильно скопирована в папку netcoreapp3.0 вашего пакета. Ваш пакет 1.1.1 имеет противоположную проблему. Папки netstandard2.0 и netcoreapp3.0 содержат сборку netcoreapp3.0, поэтому ваш пакет не работает с проектами, которые пытаются использовать сборку netstandard2.0.
Однако я понятия не имею, почему этослучается. Когда я клонирую ваш репозиторий и запускаю dotnet pack и проверяю сгенерированный nupkg, я вижу, что сборки netstandard2.0 и netcoreapp3.0 имеют разные ссылки, поэтому я уверен, что сгенерированный локально пакет должен работать. Вам нужно выяснить, почему публикуемые вами пакеты не генерируются правильно.
Чтобы быстро ответить на ваши вопросы:
Есть ли способ обойти это, чтобы он воспринимался как ошибка/ предупреждение / что-то, по крайней мере, во время сборки?
Будет, так как проблема была не с проектом, а с пакетом. Если вы нацелены на несколько проектов и вызовете API, который не существует хотя бы в одном из TFM, вы получите ошибку компиляции.
Является ли решение этой проблемы использованием директив препроцессора вокругвызов .FindProperty (...) и на основе этой структуры сделать правильный вызов метода? Разве нет способа сделать это на основе версии efcore вместо зависимости?
Когда вы вызываете API, которые отличаются в разных TFM, да, вы можете использовать #if для измененияваш код для проекта TFM, как описано в документах ASP.NET Core при переходе на 3.0 .
Я собираюсь игнорировать «на основе версии efcore», потому что ячеловек, ориентированный на детали, и я не хочу писать тысячу слов для чего-то, что в конечном итоге не имеет значения. Ключ в том, что в этом сценарии вам не нужно. Вы использовали условия в ссылках вашего пакета, чтобы ввести разные версии efcore для проекта TFM, поэтому каждый раз, когда ваш проект компилируется, он использует другую версию efcore, но только одну версию для каждой цели компиляции. Поэтому вам не нужно выбирать во время выполнения различные версии efcore.
Есть ли способ провести модульное тестирование этого правильно с различными пакетами? В настоящий момент я ожидал, что модульные тесты не пройдут в одной из версий, так как метод не существует.
Вы многоцелевой ваш тестовый проект, но я вижу, что вы сделали этоуже. Поскольку вы используете ссылку на проект, тест не обнаружит проблем с созданием пакета, например, что происходит.
Если вы действительно хотите протестировать пакет, а не свой код, вы можете использовать файл nuget.config для добавления локальной папки в качестве источника пакета, тогда ваш тестовый проект с множественным таргетингом ссылается на пакет, а не на проект. Возможно, вы также захотите использовать файл nuget.config для установки globalPackagesFolder на то, что находится в .gitignore, потому что NuGet считает пакеты неизменными, и если отладочная версия вашего пакета попадает в папку глобальных пакетов вашего профиля пользователя,каждый проект, который вы используете на этом компьютере (который использует папку глобальных пакетов вашего профиля пользователя), будет использовать эту отладочную версию, что затруднит вам обновление. Для клиентов, которые хотят тестировать пакеты, а не проекты, я настоятельно рекомендую использовать предварительные метки SemVer2 и создавать уникальную версию пакета для каждой отдельной сборки, чтобы снизить риск тестирования версии, отличной от вашей.
Использование ссылки на пакет, а не проекта, является болью, потому что это уже не так просто, как написание кода и запуск теста. Вам нужно будет изменить код, скомпилировать проект, сгенерированный в пакет, скопировать пакет в исходную папку пакета, если вы этого не автоматизировали, обновить версию пакета в тестовом проекте, а затем скомпилировать и запустить тестовый проект,Я думаю, что вам лучше сохранить ссылку на проект. Исправьте проблему с созданием пакета, а затем доверяйте инструментам.