Как написать пакет NuGet, который обновляет перенаправления привязки при обновлении ссылки на пакет?

Question

Мы используем VS 2017 и используем пакеты NuGet по-старому. Мы не используем пока PackageReference.

При обновлении ссылки на пакет NuGet через диспетчер NuGet в VS соответствующее перенаправление привязки сборки не обновляется автоматически - мы должны сделать это вручную.

Итак, я полагаю, что пакет должен позаботиться об этом через скрипт tools \ install.ps1. Теперь я думаю, что знаю, как это реализовать, но я не хочу изобретать колесо. Конечно, код уже существует где-то, но где?

Разъяснение

Наше приложение строго подписано и нацелено на .NET 4.5.2 в настоящее время (скоро будет обновлено до 4.7.2). Мы используем packages.config.

Мне нужно объяснить, что происходит. На поле три игрока:

1. Инструмент - DbUpgrade
2. Плагин инструмента Api - DbUpgradeApi
3. Реализация плагина Api - LogDbUpgradeProgress

Давайте проверим пакет DbUpgradeApi. 3 его версии актуальны для нас:

1. Версия, по которой компилируется LogDbUpgradeProgress - A
2. Версия, для которой скомпилирован DbUpgrade - B
3. Последняя версия DbUpgradeApi - C

Инструмент DbUpgrade загружает плагин LogDbUpgradeProgress во время выполнения. Переадресация обязательна, потому что A - это не то же самое, что B (и поскольку код подписан, здесь ничего не нужно делать)

Если C выше, чем B , то мы должны обновить ссылку на DbUpgradeApi в DbUpgrade. Но это должно сопровождаться обновлением перенаправления привязки. И в этом суть этого вопроса.

Answer 1

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

Но сначала, вы уверены, что вам нужны привязки перенаправлений?.NET Core не нуждается в этом.Если вы используете .NET Framework, но с проектом, использующим PackageReference, то он разрешается во время сборки, ваш app.config не нуждается в перенаправлении привязки в версии, проверенной вашим кодом, но при сборке и проверкефайл [ваше exe-имя] .config содержит перенаправления привязки.Кроме того, привязка перенаправляет значение только тогда, когда ваша сборка имеет строгие имена.Если вы не подписывали свою сборку, то перенаправление привязки не требуется.

Вот шаги, которые я предпринял, чтобы создать репродукцию получения перенаправлений привязки в консольном приложении с использованием packages.config.

1. Создать пустую папку для начала.Я использовал dotnet new sln, dotnet net nugetconfig для создания нового файла sln и nuget.config.Я отредактировал файл nuget.config, добавив папку localFeed в качестве источника, и установил globalPackagesFolder на gpf, чтобы не загрязнять свою папку реальных глобальных пакетов тестовыми пакетами.Также создан ключ строгого имени с sn -k snk.snk.
2. Создать первую тестовую библиотеку классов.dotnet new classlib -n someLib.Я отредактировал Class1.cs, чтобы изменить имя класса на SomeClass, и добавил свойство, которое возвращает значение «Версия 1».Использовал Visual Studio для установки snk.snk в качестве ключа подписи.dotnet pack для генерации V1 пакета.Затем я отредактировал SomeClass, чтобы изменить сообщение на «Версия 2», а затем запустил dotnet pack /p:version=2.0.0.Наконец, использовали nuget.exe add -source localFeed someLib\bin\Debug\someLib.1.0.0.nupkg и снова для v2 nupkg.
3. Создайте вторую тестовую библиотеку классов, dotnet new classlib -n anotherLib и установите ключ подписи на snk.snk.Изменил Class1.cs на AnotherClass и добавил свойство public string Message => new someLib.SomeClass().Message;.Добавил ссылку на someLib версии 1 в csproj, затем собрал, упаковал и использовал nuget.exe для добавления nupkg в localFeed.
4. Открыл Visual Studio и создал консольное приложение .NET Framework,Добавлена ​​ссылка на anotherLib, которая автоматически принесла v1 из someLib.Обновил ссылку someLib до v2 и подтвердил, что packages.config теперь имеет перенаправление привязки для someLib.
5. . Создал другое консольное приложение .NET Framework и сделал то же самое, что и шаг 3, но на этот разиспользуя PackageReference вместо packages.config.Проект app.config не имеет перенаправлений привязки, но файл .config в папке bin после сборки делает.

edit: возможно, важной частью для понимания поведения перенаправления привязки NuGet / MSBuild являетсяследующее: на обоих шагах 3 и 4, если я добавлю ссылку только на anotherLib, перенаправление привязки не будет создано, поскольку все сборки, ссылающиеся на someLib, ссылаются на одну и ту же версию.Только если в моем консольном приложении будет использоваться ссылка на версию someLib, отличную от anotherLib, перенаправление привязки будет создано.

В приложении с плагинами сборка приложения не будет иметь привязкиredirect, потому что это единственная сборка в командной строке компиляции, использующая dll контракта плагина, поэтому нет необходимости в перенаправлении привязки.Когда сборка плагина построена, только плагин зависит от dll контракта плагина, поэтому опять нет конфликта, поэтому нет перенаправления привязки.Если вы скопируете все библиотеки в одну папку, то может возникнуть конфликт в требуемой версии, но это проблема времени развертывания, а не проблема времени сборки / компиляции, поэтому инструменты сборки могут не помочь.Один из способов решения этой проблемы - добавить ссылку на проект плагина из сборки приложения.Таким образом, во время компиляции инструменты сборки могут видеть, что используются две разные версии dll контракта плагина, поэтому можно создать перенаправление привязки.Это работает только при сборке приложения.Если приложение представляет собой только двоичный файл, который вы дали, то изменение перенаправлений привязки становится обязанностью времени развертывания, поэтому инструменты разработки / сборки могут не помочь.