Каковы преимущества использования реализаций c реализаций? - PullRequest
0 голосов
/ 07 апреля 2020

При запуске dotnet restore --runtime linux-musl-x64 из альпийского контейнера я заметил, что загружаются некоторые пакеты runtime.unix.System*, которые не загружаются, если не указан флаг --runtime. Я предполагаю, что это потому, что, когда runtime отсутствует, для tnet restore по умолчанию используется any восстановление реализаций платформы c, предоставляемых пакетом. Это правильное предположение?

Хотелось бы узнать, документировано ли где-либо преимущества использования реализаций c реализаций. Net пакетов CORE? Например, System.Net.Sockets и runtime.unix.System.Net.Sockets. Я бы предположил, потому что они не являются общими c реализациями, они более эффективны с точки зрения использования памяти и ЦП, но есть ли какие-либо официальные рекомендации или тесты?

Ответы [ 2 ]

0 голосов
/ 07 апреля 2020

Пакеты типа System.Net.Sockets содержат управляемые биты, от которых зависят ваши приложения. Поэтому независимо от того, какой подход к развертыванию вы используете (зависящий от фреймворка или самодостаточный), они требуются, поэтому восстанавливаются процессом сборки.

Пакеты, подобные runtime.unix.System.Net.Sockets, обычно содержат только собственные биты (прокладки для переноса в ОС). API). Они требуются только для автономного развертывания.

То есть, просто говоря, System.Net.Sockets зависит от runtime.unix.System.Net.Sockets (если он работает на UNIX). Они не эквивалентны друг другу, как вы и предполагали.

Вам не нужно вызывать dotnet restore --runtime linux-musl-x64, так как эти пакеты времени выполнения бесполезны во время компиляции. Восстановление таких пакетов времени выполнения может быть отложено до dotnet publish, если вы указали конкретную c среду выполнения.

0 голосов
/ 07 апреля 2020

Это не проблема преимуществ / недостатков. Когда вы указываете платформу времени выполнения, вы нацеливаетесь именно на эту платформу, тогда как в противном случае вы нацеливаетесь на любую возможную платформу. В первом случае вводятся только необходимые компоненты времени выполнения, в то время как во втором есть просто слабая ссылка на то, какое время выполнения может быть установлено на цели. Эти пакеты будут использованы в любом случае. Есть пакеты времени выполнения для Windows, Linux, Ma c, et c. Какие из них используются, очевидно, зависит от того, где приложение в конечном итоге развернуто, или, конечно, от спецификации флага времени выполнения.

...