Начну с того, что это звучит не очень хорошая идея. Вы не объяснили сценарий того, почему вы хотите это сделать, поэтому у нас нет способа предложить лучшие подходы. Если это веб-приложение, для которого вы не хотите иметь время простоя, лучшим подходом может быть использование балансировщика нагрузки, а при выпуске новой версии веб-приложения - настроить балансировщик нагрузки для отправки всех новых запросов на новое содержит / версия, в то время как существующие соединения в старой версии стекают.
Если ваше приложение является слушателем очереди, вам вообще не нужна горячая загрузка. Просто создайте приложение, которое создает запрос на извлечение исходного кода, чтобы обновить номера версий пакетов nuget, когда они станут доступны, чтобы CI автоматически создавал изменения, и если тесты пройдены, вы можете автоматизировать утверждение / объединение PR, тогда ваш CD может автоматически развернуться и списать предыдущую версию. Это было бы менее рискованно, чем автоматическая загрузка новых версий, поскольку вы рискуете, что в новой версии будут ошибки или она не будет двоично-совместимой, и теперь ваше приложение будет аварийно завершать работу.
В любом случае, если у вас действительно есть веская причина для горячей перезагрузки сборок, в .NET Core вам нужно будет использовать AssemblyLoadContext. Тем не менее, это настолько необычный случай, чтобы нуждаться в этом, что я не могу найти никаких реальных примеров того, как его использовать. Все «примеры», которые я видел, используют AssemblyLoadContext.Default, который, как я полагаю, эквивалентен использованию одного контекста и поэтому не позволит вам загружать разные версии одной и той же сборки. Так что, если вы хотите пойти по этому пути, вам, вероятно, придется самому разобраться. Много проб и ошибок, отладка и, возможно, чтение исходного кода coreclr. Как упоминалось в некоторых комментариях к вашему вопросу, вам также нужно будет обработать случай, когда сборка была скомпилирована для одной версии зависимости, но теперь вы собираетесь загрузить другую версию. В .NET Framework используется то, что называется перенаправлением сборки. Большинство людей используют это с файлом app.config или web.config, но это не сработает для вас, так как он изменится во время выполнения. Я уверен, что есть API для программной работы с ним, что вам также необходимо выяснить. Я не уверен, как / если перенаправления привязки отличаются в .NET Core по сравнению с .NET Framework, так что это еще одна вещь, которую вам нужно выяснить, но я уверен, что пара хороших поисков в Google даст ты ответ на это.
После того, как вы получите горячую перезагрузку сборки, вы можете либо прочитать API сервера NuGet и реализовать свой собственный клиент, либо использовать SDK клиента NuGet . Но основной задачей команды клиента NuGet являются инструменты (интеграция с Visual Studio, dotnet cli, nuget.exe), они просто публикуют пакеты для удобства (а также для обмена библиотеками с dotnet cli и mono), поэтому документы по использованию SDK. Также обратите внимание, что хотя команда клиента NuGet старается не нарушать бинарный API пакетов, это вторичная проблема, когда необходимо реализовать функции и исправления ошибок для инструментов. SDK клиента NuGet отслеживает номер версии Visual Studio, он не использует семантическое управление версиями, поэтому при попытке обновления до более новых клиентских пакетов NuGet может возникнуть необходимость изменить код, если вы не ожидаете этого. Это довольно редко, но я обычно рекомендую шаблон «порты и адаптеры», и это отличный пример того, когда он особенно полезен. По крайней мере, с клиентскими пакетами NuGet есть сообщения в блоге от людей, которые выяснили это и поделились тем, как они делали все, что им было нужно. В противном случае, поскольку сам NuGet является открытым исходным кодом, вы можете просмотреть код NuGet, чтобы увидеть, как он использует пакеты внутри, и использовать его в качестве руководства, чтобы помочь вам понять, что вы хотите сделать. Если вы пойдете по этому пути, вам нужно будет сделать большую часть того, что делают инструменты nuget:
- Запросите ленту NuGet, чтобы узнать, какие версии пакета доступны, затем выберите, какую версию вы хотите использовать, и проверьте, уже загружена ли эта версия.
- Загрузите и распакуйте пакет.
- Выбор актива.В частности, когда в пакете есть библиотеки для нескольких TFM, вам нужно знать, какой из них использовать, основываясь на TFM вашего проекта
- . На этом этапе клиент NuGet записывает файл
project.assets.json, используемый SDK .NET.или отредактируйте файлы packages.config и csproj в зависимости от того, использует ли проект PackageReference или packages.config.В вашем случае это место, где вы интегрируетесь с горячей перезагрузкой сборки.
Обратите внимание, что в общем случае процесс, описанный выше, или в зависимости от того, как вы реализуете его за один шаг, может быть рекурсивным, посколькуПакет может иметь зависимости.Таким образом, зависимости также должны быть извлечены, но пакет может иметь разные зависимости в зависимости от того, какой TFM выбран, поэтому вам необходимо выяснить, хотите ли вы загрузить все зависимости, даже те, которые никогда не будут использоваться после выбора ресурса, илиВы хотите сделать выбор активов в первую очередь, чтобы минимизировать пакеты, которые вы загружаете.Также, когда несколько пакетов зависят от разных версий одного пакета, вам необходимо принять решение о том, какую версию пакета вы хотите использовать.
Итак, это высокоуровневый алгоритм, который вам понадобитсявоплощать в жизнь.Как я уже упоминал, большинство из них не имеют документов API с примерами того, как именно это реализовать, и очень мало примеров, если таковые имеются, в Интернете.Как я уже писал в первом абзаце, я не думаю, что это хорошая идея.Вероятно, проще автоматизировать конвейеры CI / CD и, если необходимо, автоматизировать изменения в конфигурации балансировщика нагрузки, чем создавать такое сложное приложение.Иногда организовать кучу простых приложений проще, чем создать сложное приложение.