Я получаю предупреждение (которое в моем проекте рассматривается как ошибка) для пакета Nuget собственной разработки. Я не уверен, что делаю неправильно - согласно документации, 1.0.0.13 >= 1.0.0 должен разрешиться.
Я получаю предупреждение / ошибку:
NU1603 MyPackage.Services 1.0.0.13 depends on MyPackage.Base (>= 1.0.0) but MyPackage.Base 1.0.0 was not found. An approximate best match of MyPackage.Base 1.0.0.13 was resolved.
MyPackage.Services.nuspec:
<?xml version = "1.0" encoding = "utf-8"?>
<package xmlns = "http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
<metadata>
<id>MyPackage.Services</id>
<version>1.0.0</version>
<authors>Me</authors>
<owners>Me</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>My Package Description</description>
<copyright>Me - 2018</copyright>
<dependencies>
<dependency id = "MyPackage.Base" version = "1.0.0" />
<!-- ... -->
</dependencies>
</metadata>
</package>
Спасибо
Он решает, он сообщает вам, что он использовал 1.0.0.13, потому что не удалось найти точную запрошенную версию (1.0.0, которая в данном случае является транзитивной зависимостью). NU1603 по умолчанию является предупреждением, а не ошибкой. Рассматривать это как ошибку - значит умышленно нарушать вашу собственную сборку. Поскольку вы управляете MyPackage.Services, вы можете изменить его зависимость от MyPackage.Base на версию, которая действительно существует (1.0.0.13), и предупреждение должно исчезнуть.
@Stefan, спасибо за мысль. Я пробовал это, но у меня такая же проблема.
@Ziv, это соответствует тому, что я думал. было бы неплохо, если бы он не выдавал предупреждения, когда ведет себя должным образом, но, возможно, мне просто придется подавить предупреждения NU1603. Если вы хотите написать это как ответ, я с радостью его приму.
Во многих случаях вам может потребоваться предупреждение как разработчик, если, например, пакет был удален из NuGet, и ваша сборка внезапно изменилась. Существует также функция файла linup, которая позволяет этому сбой сборки, если ранее разрешенная версия больше не загружается / недоступна в каналах.
Если вы используете PackageReference, вы сможете установить NoWarn = "NU1603" в элементе <PackageReference> или добавить его в свойство <NoWarn> в файле проекта.
@MartinUllrich ~ Я попытался добавить NoWarn как атрибут и как элемент, но, тем не менее, предупреждение не исчезло. Это недавно созданный проект WPF с использованием PackageReference. Любые идеи?





Как говорится в сообщении предупреждение
An approximate best match of MyPackage.Base 1.0.0.13 was resolved.
Так было решено. Однако, приняв решение рассматривать предупреждение как ошибку, вы попросили его прервать вашу сборку.
Поскольку у вас есть MyPackage.Services, вы можете изменить его зависимость от MyPackage.Base на версию, которая действительно существует, чтобы перестать получать это предупреждение. Другие варианты - перестать рассматривать NU1603 как предупреждение или, возможно, полностью подавить его.
Как сказал Мартин Ульрих в комментариях к вопросу, есть сценарии, в которых разработчики действительно заботятся о том, чтобы были восстановлены разные версии, чем они ожидали. Фактически, для некоторых клиентов это было настолько важно, что недавно был добавлен Новая функция для повышения безопасности восстановления пакетов (см. Недавнюю проблему с потоком событий npm). Это делает предупреждение NuGet NU1603 гораздо менее полезным, но оно существует гораздо дольше, чем блокировка пакета.
Просто глупая мысль, а вы пробовали
<dependency id = "MyPackage.Base" version = "1.0.0.0" />?