Dotnet nuget push linux

dotnet nuget push

Эта статья относится к следующему: ✔️ пакет SDK для .NET Core 2.x и более поздних версий

dotnet nuget push — отправляет пакет на сервер и публикует его.

Краткий обзор

Описание

Команда dotnet nuget push отправляет пакет на сервер и публикует его. Команда push использует сервер и учетные данные, указанные в системном файле конфигурации NuGet или цепочке файлов конфигурации. См. дополнительные сведения о файлах конфигурации в статье о настройке поведения NuGet. Конфигурацию NuGet по умолчанию можно получить, загрузив файл %AppData%\NuGet\NuGet.config (Windows) или $HOME/.nuget/NuGet/NuGet.Config (Linux и macOS). Затем нужно загрузить все файлы nuget.config или .nuget\nuget.config, начиная с корневого каталога диска и заканчивая текущим каталогом.

Команда отправляет существующий пакет. При этом пакет не создается. Для создания пакета используйте dotnet pack .

Аргументы

ROOT

Указывает путь к файлу пакета для отправки.

Параметры

-d|—disable-buffering

Отключает буферизацию при передаче данных на сервер HTTP(S), чтобы снизить использование памяти.

—force-english-output

Принудительно запускает приложение с использованием инвариантного английского языка и региональных параметров.

-?|-h|—help

Выводит описание использования команды.

—interactive

Позволяет команде остановиться и дождаться, пока пользователь выполнит действие или введет данные. Например, чтобы завершить проверку подлинности. Доступно, начиная с пакета SDK для .NET Core 3.0.

Ключ API для сервера.

-n|—no-symbols

Не передает символы (даже если они присутствуют).

—no-service-endpoint

Не добавляет «api/v2/package» в исходный URL-адрес. Параметр доступен, начиная с пакета SDK для .NET Core 2.1.

-s|—source

Определяет URL-адрес сервера. NuGet определяет источник в формате UNC или локальную папку и просто копирует файл вместо отправки через HTTP.

Начиная с NuGet 3.4.2, этот параметр является обязательным, если в файле конфигурации NuGet не указано значение DefaultPushSource . Дополнительные сведения см. в статье Configuring NuGet behavior (Настройка поведения NuGet).

—skip-duplicate

При принудительной отправке нескольких пакетов на сервер HTTP(S) обрабатывает любой ответ с кодом состояния 409 Conflict (конфликт) в виде предупреждения, чтобы можно было продолжить принудительную отправку. Доступно, начиная с пакета SDK для .NET Core 3.1.

Ключ API для сервера символов.

-ss|—symbol-source

Указывает URL-адрес сервера символов.

-t|—timeout

Указывает время ожидания для передачи на сервер в секундах. Значение по умолчанию — 300 секунд (5 минут). При указании 0 применяется значение по умолчанию.

Примеры

Отправляет foo.nupkg в источник push-уведомлений по умолчанию, указанный в файле конфигурации NuGet, используя ключ API:

Отправляет foo.nupkg на официальный сервер NuGet, предоставляя ключ API:

• Отправляет foo.nupkg в пользовательский источник push-уведомлений https://customsource , предоставляя ключ API:

Отправляет foo.nupkg в источник push-уведомлений по умолчанию, указанный в файле конфигурации NuGet:

Отправляет foo.symbols.nupkg в источник символов по умолчанию:

Отправляет foo.nupkg в источник push-уведомлений по умолчанию, указанный в файле конфигурации NuGet, с временем ожидания 360 с:

Отправляет все файлы NUPKG из текущего каталога в источник push-уведомлений по умолчанию, указанный в файле конфигурации NuGet:

Если эта команда не работает, возможно, это связано с ошибкой, которая существовала в более старых версиях пакета SDK (пакет SDK для .NET Core 2.1 и более ранних версий). Чтобы устранить эту проблему, обновите версию пакета SDK или выполните следующую команду: dotnet nuget push «**/*.nupkg»

Закрывающие кавычки необходимы для оболочек, таких как bash, выполняющих файл глобализации. Дополнительные сведения см. на странице NuGet/Home#4393.

Отправляет все файлы NUPKG в источник push-уведомлений по умолчанию, указанный в файле конфигурации NuGet, даже если сервер HTTP (S) возвращает в ответе конфликт 409:

Отправляет все файлы NUPKG из текущего каталога в каталог локального веб-канала:

Эта команда не сохраняет пакеты в иерархическую структуру папок, что рекомендуется для оптимизации производительности. Дополнительные сведения см. в разделе Локальные веб-каналы.

Источник

команда push (интерфейс командной строки NuGet)

Область применения: • Поддерживаемые версии публикации пакетов: ALL; 4.1.0 + требуется для NuGet.org

Чтобы отправить пакеты в nuget.org, необходимо использовать nuget.exe v 4.1.0 +, который реализует необходимые протоколы NuGet.

Отправляет пакет в источник пакета и публикует его.

Конфигурация NuGet по умолчанию получается путем загрузки %AppData%\NuGet\NuGet.Config (Windows) или

/.nuget/NuGet/NuGet.Config (Mac/Linux), а затем загрузки любых Nuget.Config файлов или, .nuget\Nuget.Config начиная с корневого диска и заканчивая текущим каталогом (см. раздел Общие конфигурации NuGet).

Использование

идентифицирует пакет для отправки на сервер.

Варианты

-ApiKey

Ключ API для целевого репозитория. Если он отсутствует, используется указанный в файле конфигурации.

-ConfigFile

Файл конфигурации NuGet, который необходимо применить. Если не указано, %AppData%\NuGet\NuGet.Config используется (Windows) или

-DisableBuffering

Отключает буферизацию при принудительной отправке на сервер HTTP (s) для уменьшения использования памяти. Внимание! при использовании этого параметра встроенная проверка подлинности Windows может не работать.

-ForceEnglishOutput

(3.5 +) Принудительное выполнение nuget.exe с использованием инвариантного языка и региональных параметров, основанных на английском языке.

-?|-help

Отображает справочные сведения для команды.

-NonInteractive

Подавляет запросы на ввод или подтверждение пользователя.

-NoServiceEndpoint

Не добавляет api/v2/packages к исходному URL-адресу.

-NoSymbols

(3.5 +) Если пакет символов существует, он не будет отправлен на сервер символов.

-src|-Source

Определяет URL-адрес сервера. NuGet определяет источник в формате UNC или локальную папку и просто копирует файл вместо отправки через HTTP. Кроме того, начиная с NuGet 3.4.2 этот параметр является обязательным, если только в NuGet.Config файле не указано значение дефаултпушсаурце (см. раздел Настройка поведения NuGet).

-SkipDuplicate

(5.1 и более поздние версии) Если пакет и версия уже существуют, пропустите их и продолжайте работу со следующим пакетом в push-уведомлений, если таковые имеются.

-SymbolSource

(3.5 +) Указывает URL-адрес сервера символов; nuget.smbsrc.net используется при принудительной отправке в nuget.org

-SymbolApiKey

(3.5 +) Указывает ключ API для URL-адреса, указанного в -SymbolSource .

-Timeout

Указывает время ожидания в секундах для отправки на сервер. Значение по умолчанию — 300 секунд (5 минут).

-Verbosity [normal|quiet|detailed]

Задает объем сведений, отображаемых в выходных данных: normal (по умолчанию), quiet или detailed .

Источник

Quickstart: Create and publish a package (dotnet CLI)

It’s a simple process to create a NuGet package from a .NET Class Library and publish it to nuget.org using the dotnet command-line interface (CLI).

Prerequisites

Install the .NET Core SDK, which includes the dotnet CLI. Starting in Visual Studio 2017, the dotnet CLI is automatically installed with any .NET Core related workloads.

Register for a free account on nuget.org if you don’t have one already. Creating a new account sends a confirmation email. You must confirm the account before you can upload a package.

Create a class library project

You can use an existing .NET Class Library project for the code you want to package, or create a simple one as follows:

Create a folder called AppLogger .

Open a command prompt and switch to the AppLogger folder.

Type dotnet new classlib , which uses the name of the current folder for the project.

This creates the new project.

Add package metadata to the project file

Every NuGet package needs a manifest that describes the package’s contents and dependencies. In a final package, the manifest is a .nuspec file that is generated from the NuGet metadata properties that you include in the project file.

Open your project file ( .csproj ) and add the following minimal properties inside the existing

tag, changing the values as appropriate:

Give the package an identifier that’s unique across nuget.org or whatever host you’re using. For this walkthrough we recommend including «Sample» or «Test» in the name as the later publishing step does make the package publicly visible (though it’s unlikely anyone will actually use it).

Add any optional properties described on NuGet metadata properties.

For packages built for public consumption, pay special attention to the PackageTags property, as tags help others find your package and understand what it does.

Run the pack command

To build a NuGet package (a .nupkg file) from the project, run the dotnet pack command, which also builds the project automatically:

The output shows the path to the .nupkg file:

Automatically generate package on build

To automatically run dotnet pack when you run dotnet build , add the following line to your project file within

Publish the package

Once you have a .nupkg file, you publish it to nuget.org using the dotnet nuget push command along with an API key acquired from nuget.org.

Virus scanning: All packages uploaded to nuget.org are scanned for viruses and rejected if any viruses are found. All packages listed on nuget.org are also scanned periodically.

Packages published to nuget.org are also publicly visible to other developers unless you unlist them. To host packages privately, see Hosting packages.

Acquire your API key

Sign into your nuget.org account or create an account if you don’t have one already.

For more information on creating your account, see Individual accounts.

Select your user name (on the upper right), then select API Keys.

Select Create, provide a name for your key, select Select Scopes > Push. Enter * for Glob pattern, then select Create. (See below for more about scopes.)

Once the key is created, select Copy to retrieve the access key you need in the CLI:

Important: Save your key in a secure location because you cannot copy the key again later on. If you return to the API key page, you need to regenerate the key to copy it. You can also remove the API key if you no longer want to push packages via the CLI.

Scoping allows you to create separate API keys for different purposes. Each key has its expiration timeframe and can be scoped to specific packages (or glob patterns). Each key is also scoped to specific operations: push of new packages and updates, push of updates only, or delisting. Through scoping, you can create API keys for different people who manage packages for your organization such that they have only the permissions they need. For more information, see scoped API keys.

Publish with dotnet nuget push

Change to the folder containing the .nupkg file.

Run the following command, specifying your package name (unique package ID) and replacing the key value with your API key:

dotnet displays the results of the publishing process:

Publish errors

Errors from the push command typically indicate the problem. For example, you may have forgotten to update the version number in your project and are therefore trying to publish a package that already exists.

You also see errors when trying to publish a package using an identifier that already exists on the host. The name «AppLogger», for example, already exists. In such a case, the push command gives the following error:

If you’re using a valid API key that you just created, then this message indicates a naming conflict, which isn’t entirely clear from the «permission» part of the error. Change the package identifier, rebuild the project, recreate the .nupkg file, and retry the push command.

Manage the published package

From your profile on nuget.org, select Manage Packages to see the one you just published. You also receive a confirmation email. Note that it might take a while for your package to be indexed and appear in search results where others can find it. During that time your package page shows the message below:

And that’s it! You’ve just published your first NuGet package to nuget.org that other developers can use in their own projects.

If in this walkthrough you created a package that isn’t actually useful (such as a package created with an empty class library), you should unlist the package to hide it from search results:

On nuget.org, select your user name (upper right of the page), then select Manage Packages.

Locate the package you want to unlist under Published and select the trash can icon on the right:

On the subsequent page, clear the box labeled List (package-name) in search results and select Save:

Related video

Find more NuGet videos on Channel 9 and YouTube.

Next steps

Congratulations on creating your first NuGet package!

To explore more that NuGet has to offer, select the links below.

Источник