Имя nuget не распознано как имя командлета

Управление пакетами с помощью консоли диспетчер пакетов Visual Studio (PowerShell)

Консоль диспетчер пакетов в Visual Studio использует команды PowerShell для взаимодействия с пакетами NuGet. Консоль можно использовать, если нет способа выполнить операцию с помощью пользовательского интерфейса диспетчер пакетов. Вы также можете использовать команды dotnet CLI или NuGet CLI в консоли.

В этой статье описывается, как найти, установить, обновить и удалить пакеты NuGet с помощью команд PowerShell в консоли диспетчер пакетов. Полный справочник по команде PowerShell консоли диспетчер пакетов см. в справочнике по PowerShell.

Команды и аргументы PowerShell в этой статье относятся к консоли диспетчер пакетов Visual Studio. Эти команды отличаются от команд модуля PackageManagement, которые можно использовать в общей среде PowerShell. Каждая среда имеет команды, недоступные в другой среде, и команды с одинаковым именем могут отличаться в своих конкретных аргументах.

Доступность консоли

Начиная с Visual Studio 2017, NuGet и NuGet диспетчер пакетов автоматически устанавливаться при создании любого. Рабочие нагрузки, связанные с NET, в Visual Studio. Вы также можете установить диспетчер пакетов, выбрав диспетчер пакетов NuGet отдельных >>компонентов в установщике Visual Studio.

Вы также можете найти расширение NuGet диспетчер пакетов в меню «Расширения инструментов>» и Обновления или расширения. Если вы не можете использовать установщик расширений в Visual Studio, скачайте расширение отсюда: https://dist.nuget.org/index.html.

Консоль диспетчер пакетов встроена в диспетчер пакетов для Visual Studio в Windows. Visual Studio Code и Visual Studio для Mac не включают консоль. Visual Studio для Mac имеет пользовательский интерфейс для управления пакетами NuGet, а эквивалентные команды консоли доступны через Интерфейс командной строки NuGet. Дополнительные сведения см. в статье об установке пакетов NuGet и управлении ими в Visual Studio для Mac.

Быстрое поиск и установка пакета

Чтобы быстро найти и установить пакет с помощью консоли диспетчер пакетов, выполните следующие действия.

1. Откройте проект или решение в Visual Studio и выберите Сервис>NuGet диспетчер пакетов>диспетчер пакетов консоль, чтобы открыть окно консоли диспетчер пакетов.
2. В консоли введите Find-Package ключевое слово, чтобы найти пакет, который требуется установить. Например, чтобы найти пакеты, содержащие ключевое слово elmah , выполните следующую команду. Если вы уже знаете имя пакета, пропустите этот шаг.

Find-Package elmah 

Install-Package Elmah.MVC 

Дополнительные сведения об этих командах см. в разделе «Поиск пакета » и «Установка пакета «.

Многие операции консоли зависят от наличия решения с именем известного пути, открытого в Visual Studio. Если у вас есть несохраненные решения или нет решения, вы увидите, что решение об ошибке не открыто или не сохранено. Убедитесь, что у вас есть открытое и сохраненное решение. Чтобы исправить ошибку, создайте и сохраните решение или сохраните несохраненные решения.

Элементы управления консолью

Чтобы открыть консоль диспетчер пакетов в Visual Studio, выберите «Сервис>NuGet диспетчер пакетов> диспетчер пакетов консоль» в верхнем меню. Консоль — это окно Visual Studio, которое можно упорядочить и разместить по мере того, как вы хотите. Дополнительные сведения см. в статье Настройка макетов окон в Visual Studio.

По умолчанию команды консоли работают с определенным источником пакета и проектом, показанным в элементах управления в верхней части окна:

Выбор другого источника пакета или проекта изменяет значения по умолчанию для последующих команд. Чтобы переопределить эти параметры для отдельных команд без изменения значений по умолчанию, большинство команд консоли поддерживают -Source и -ProjectName параметры.

Чтобы управлять источниками пакетов, выберите значок шестеренки, в котором откроется диалоговое окно «Параметры>инструментов>» NuGet диспетчер пакетов> Package Sources. Элемент управления рядом с селектором проекта очищает содержимое консоли.

Кнопка в правом верхнем углу прерывает долго выполняющуюся команду. Например, при выполнении Get-Package -ListAvailable -PageSize 500 перечислены первые 500 доступных пакетов в источнике по умолчанию, например nuget.org, что может занять несколько минут.

Поиск пакета

Чтобы найти пакет в источнике по умолчанию, используйте find-Package.

Чтобы найти и перечислить пакеты, содержащие определенные ключевое слово:

Find-Package Find-Package

Find-Package -StartWith 

Find-Package -First 100 

Find-Package -AllVersions -ExactMatch 

Установка пакета

Чтобы установить пакет в проект по умолчанию, используйте Install-Package . Команда консоли install-Package выполняет следующие действия:

• Выполняет действия, описанные в разделе «Что происходит при установке пакета NuGet».
• Отображает применимые условия лицензии в окне консоли с подразумеваемым соглашением. Если вы не согласны с условиями, удалите пакет.
• Добавляет ссылку на пакет в файле проекта и в Обозреватель решений в узле «Ссылки«. Перед просмотром изменений в файле проекта необходимо сохранить проект.

По умолчанию добавляет пакет в проект по умолчанию Install-Package , указывающее окно консоли. Чтобы добавить пакет в проект, который не является стандартным, используйте -ProjectName этот параметр. Например, чтобы добавить пакет в проект, отличный Elmah.MVC от по умолчанию UtilitiesLib , выполните следующую команду:

Install-Package Elmah.MVC -ProjectName UtilitiesLib 

Удаление пакета

Чтобы удалить пакет из проекта по умолчанию, используйте Uninstall-Package . Если вам нужно найти имя пакета, используйте get-Package , чтобы просмотреть все пакеты, установленные в проекте по умолчанию.

Удаление пакета выполняет следующие действия:

• Удаляет ссылки на пакет из проекта и любые форматы управления. Ссылки больше не отображаются в обозревателе решений Возможно, потребуется перестроить проект, чтобы удалить ссылку в папке bin .
• Отменяет любые изменения, устанавливающие пакет в app.config или web.config.
• Удаляются ранее установленные зависимости, если остальные пакеты не используют эти зависимости.

Чтобы удалить пакет и все неиспользуемые зависимости, выполните следующую команду:

Uninstall-Package -RemoveDependencies 

Чтобы удалить пакет, даже если другие пакеты зависят от него, выполните следующую команду:

Uninstall-Package -Force 

Обновление пакета

Чтобы обновить пакет, используйте get-Package и Update-Package. Вы можете выполнить следующие команды:

Чтобы проверка, если для всех установленных пакетов доступны новые версии:

Get-Package -updates 

Update-Package

Update-Package -ProjectName

Update-Package 

Использование интерфейса командной строки NuGet в консоли

Вы также можете выполнять большинство операций консоли с помощью интерфейса командной строки NuGet. Однако команды консоли PowerShell работают в контексте сохраненного проекта и решения Visual Studio и часто выполняют больше, чем их эквивалентные команды Интерфейса командной строки NuGet. Например, при установке пакета с помощью Install-Package добавляется ссылка на файл проекта, но команда NuGet CLI не выполняется. По этой причине разработчики, работающие в Visual Studio, обычно предпочитают использовать команды консоли, а не интерфейс командной строки NuGet.

Чтобы использовать команды Интерфейса командной строки NuGet в консоли диспетчер пакетов, установите пакет NuGet.CommandLine.

Install-Package NuGet.CommandLine 

Предыдущая команда устанавливает последнюю версию интерфейса командной строки NuGet. Чтобы установить определенную версию, используйте -Version этот параметр. Например, чтобы установить версию 4.4.1, введите:

Install-Package NuGet.CommandLine -Version 4.4.1 

После установки NuGet.CommandLine пакета можно выполнить все команды интерфейса командной строки NuGet через консоль диспетчер пакетов.

Расширение консоли диспетчера пакетов

Некоторые пакеты устанавливают новые команды для консоли. Например, создает такие команды, MvcScaffolding как Scaffold создание контроллеров и представлений MVC ASP.NET:

Настройка профиля PowerShell NuGet

Вы можете создать профиль PowerShell, чтобы сделать часто используемые команды доступными во всех контекстах PowerShell, поэтому параметры PowerShell между сеансами не теряются. NuGet поддерживает профиль NuGet, как правило, в %UserProfile%\Documents\WindowsPowerShell\NuGet_profile.ps1.

Чтобы найти расположение профиля пользователя, введите $profile в консоли:

$profile C:\Users\\Documents\WindowsPowerShell\NuGet_profile.ps1 

Чтобы определить, существует ли профиль в этом расположении, введите test-path $profile . Если команда возвращается False , необходимо создать профиль с указанным именем в этом расположении. Дополнительные сведения см. в разделе «Профили Windows PowerShell».

Следующие шаги

• Установка пакетов NuGet и управление ими с помощью dotnet CLI
• Управление пакетами с помощью интерфейса командной строки nuget.exe
• Установка пакетов и управление ими в Visual Studio с помощью диспетчер пакетов NuGet

Ответственное управление пакетами в Visual Studio

Почти девять лет назад миру был представлен новый опенсорсный проект под названием NuGet (www.NuGet.org). Спустя два года после своего дебюта NuGet начал поставляться в Microsoft Visual Studio, что актуально и по сей день. NuGet — это один из нескольких пакетных менеджеров (диспетчеров пакетов), таких как Node Package Manager (NPM) для JavaScript и Maven для Java. Пакетные менеджеры упрощают и автоматизируют использование библиотек. Например, если вам нужна библиотека для реализации JavaScript Object Notation (JSON) в вашем .NET-приложении, потребуется всего несколько кликов мышью, и ваше приложение получит мощные возможности, которые вам не нужно реализовывать самим, совершенно бесплатно.

Когда-то разработчики создавали и поддерживали свои собственные библиотеки. Если вам нужна была какая-либо библиотека, скорее всего, вы вежливо спрашивали о ней коллег-разработчиков в онлайн-сообществах где-нибудь на CompuServe, что было принято в подобных сообществах, и были все шансы, что вы могли получить библиотеку, отвечающую вашим потребностям или, по крайней мере, рекомендации, как самому ее создать.

Сегодня программное обеспечение с открытым исходным кодом (Open Source Software — OSS) создало беспрецедентную доступность для систем управления кодом и пакетами, которые делают внедрение этого кода в ваши приложения невероятно легким процессом. Однако, этот прогресс принес не только многочисленные преимущества, но и новые риски и проблемы. Одним из недавних примеров является инцидент с event-stream в ноябре 2018 года, связанный с NPM. Эта статья посвящена тому, как ответственно использовать NuGet в Visual Studio, чтобы снизить подобные риски.

Если вы работаете в публичной компании, регулируемой SOX, или подпадаете под действие HIPAA или PCI, и ваши приложения напрямую зависят от какого-либо публичного NuGet-источника, то есть все шансы, что ваша компания может нарушать вышеупомянутые стандарты, несмотря на отсутствие каких-либо неблагоприятных инцидентов.

Ни одно приложение, работающее в продакшене, или процесс сборки никогда не должны напрямую зависеть от каких-либо пакетов из публичных источников.

Если вы не очень хорошо знакомы с NuGet

В случае, если вы не знакомы с NuGet, не знаете что это такое и как он работает в целом, то я рекомендую вам почитать официальную документацию, где вы можете найти всю интересующую вас информацию. А если вы являетесь подписчиком Pluralsight, вы можете посмотреть мой курс “Введение в NuGet”.

Представленные здесь концепции не требуют глубокого понимания NuGet. Целевая аудитория включает в себя как опытных разработчиков, так и директоров с менеджерами, отвечающих за реализацию политик компании в области безопасности и снижения рисков.

Пакетные менеджеры и источники пакетов

Прежде чем углубляться в базовые концепции пакетных менеджеров в .NET/Visual Studio с NuGet, давайте скажем пару слов о пакетных менеджерах и пакетах в целом. Ниже приведены основные понятия, которые вам нужно знать:

• Пакет: Архивный файл (например, zip или tar), который содержит артефакты кода и дополнительные метаданные для пакетного менеджера, которые, в свою очередь, используются средой разработки для добавления содержимого пакета в проект.
• Пакетный менеджер: Инструмент, который среда разработки приложений (например, Visual Studio, Eclipse и т. д.) использует для получения доступа к пакетам, содержащимся в источнике пакетов. Распространенными пакетными менеджерами являются NuGet, Maven и Node Package Manager (NPM). Пакетный менеджер берет на себя не только управление доступом к конкретному пакету, он также заботится о доступе к другим пакетам, от которых зависит загруженный пакет (т. е. занимается управлением зависимостями).
• Источник пакетов: набор пакетов, где для каждого пакета содержатся метаданные о нем. Эти метаданные включают номер текущей версии, историю релизов, ссылки на репозиторий с исходным кодом (например, на GitHub), документацию, информацию о лицензии. Среди самых популярных источников пакетов можно выделить NuGet.org, MyGet и npmjs.com.

Компаниям следует самим создавать собственные пакеты и заниматься управлением ими и их зависимостями, а также стремиться к созданию и использованию своих собственных внутренних источников пакетов.

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

Каковы риски?

Из трех элементов, приведенных в списке выше, риск возникает из-за двух: пакетов и источников пакетов. Источники пакетов, такие как npmjs.com и NuGet.org, являются открытыми до такой степени, что любой желающий может создать учетную запись и загрузить туда пакет, который впоследствии будет загружаться другими. Из-за одной только этой причины такие открытые источники пакетов ненадежны по своей сути. Означает ли это, что вам следует избегать открытых источников? Конечно нет. Это означает, что при получении пакетов из таких источников вы должны проявлять должную осмотрительность, проверяя содержимое этих пакетов. Если вы не можете с уверенностью определить происхождение пакета и его содержимое, вы подвергаете свою фирму риску, которого в противном случае можно было бы избежать. Реальным примером такого риска и его последствий стал инцидент с event-stream, обнаруженный в ноябре 2018 года. Этот инцидент был связан с вредоносным кодом в пакете, который собирал данные об учетных записях со счетов, имеющих баланс биткоинов выше определенного уровня. The Register сообщил, что код являлся частью популярной NPM-библиотеки, которая в среднем загружалась до двух миллионов раз в неделю.

Если вы не можете с уверенностью определить происхождение пакета и его содержимое, вы подвергаете свою фирму риску, которого в противном случае можно было бы избежать.

С одной стороны, открытые источники пакетов делают код легко доступным. С другой стороны, эти открытые источники пакетов НЕ ОСУЩЕСТВЛЯЮТ и, возможно, НЕ МОГУТ В ПРИНЦИПЕ контролировать наличие вредоносного кода в пакетах. Так кто должен следить за этим? Ответ очень прост: ВЫ! Если вы привносите пакет в свою организацию, вы обязаны проверить не только содержимое пакета, но и содержимое всех остальных пакетов, от которых зависит загруженный пакет.

Управление зависимостями — еще одна приятная функция, осуществляемая пакетным менеджером. Если вам показалось, что внедрение вредоносного пакета в вашу организацию похоже на распространение заразного вируса, вы все правильно поняли.

Дело в том, что ни одно приложение, работающее в продакшене, или процесс сборки никогда не должны напрямую зависеть от каких-либо пакетов из публичных источников. Помимо злоумышленников, есть много других менее опасных причин не доверять публичным источникам пакетов:

• Вы оставляете за владельцем пакета все, что касается управления зависимостями и версиями. Что, если владелец пакета введет зависимость, которая необходима для работы пакета, но полностью несовместима с вашим приложением?

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

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

Разве подписывание пакетов не снижает риск?

Одним словом, да, но это “да” с оговорками. Подписывание снижает некоторые риски, но не все. Подписывание не предотвратило бы инцидент с event-stream. Единственное, что делает подписывание пакета, — это удостоверяет автора/контрибьютора пакета. Безусловно, в большинстве сред вы можете ограничить пакеты, которые вы можете использовать, по определенным авторам. Если у вас есть публичный ключ, то брать можно только те пакеты, которые подписаны авторским сертификатом. Однако это не означает, что вы можете расслабиться и не глядя брать любой пакет от этого автора. Что, если авторский сертификат был скомпрометирован? Что, если автор допустил невинную ошибку, в результате которой ваша компания может понести ущерб?

Теперь, когда у вас есть какое-никакое представление о пакетах, пакетных менеджерах и источниках пакетов, а также о связанных с ними рисках, давайте применим эти знания к NuGet.

Краткий обзор NuGet: создание собственного источника NuGet

Как я уже говорил ранее, эта статья не является подробным практическим руководством по NuGet. Если вас интересует таковое, то вам следует обратиться к материалам, представленным в начале этой статьи. В предыдущем разделе я описывал как взаимосвязаны пакеты, пакетные менеджеры и источники пакетов — NuGet использует тот же подход. Для Visual Studio NuGet является стандартным встроенным пакетным менеджером, и найти его можно как показано на рисунке 1.

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

Также на рисунке 1 показан источник пакета. Скорее всего, вашим активным источником пакетов является NuGet.org. В моем случае это нечто с именем Local Package Source. Рисунок 2 иллюстрирует, что это такое:

Как видите, локальный источник NuGet — это просто каталог на моем рабочем компьютере. Это может слегка шокировать, но создать источник NuGet так же просто, как создать каталог! На рисунке 3 показаны пакеты NuGet в этом каталоге:

Анатомия пакета NuGet

Пакет NuGet — это просто ZIP-архив с другим расширением (.nupkg). На рисунке 4 показано, как открыть его содержимое.

На рисунке 5 показано содержимое пакета. Давайте посмотрим, что находится внутри одного из самых популярных и широко используемых пакетов NuGet: NewtonSoft.Json.

Глядя на рисунок 5, представляющие особый интерес элементы — это папка lib и файлы подписи, лицензии и nuspec:

• Папка lib: эта папка содержит одну или несколько вложенных папок, названных в соответствии с соглашением об именовании для каждой поддерживаемой версии .NET. Вы можете узнать больше о поддержке сразу нескольких версий .NET здесь.
• Файл .signature.p7s: как следует из названия, это файл подписи, подписанный авторским сертификатом. Дополнительную информацию о том, как подписывать пакеты NuGet, можно найти здесь. Вы также можете узнать, как требовать, чтобы были доступны только подписанные пакеты, и ограничить пакеты определенными авторами здесь.
• License.md: это разметочный файл, содержащий условия лицензии для вашего пакета. Как правило, это лицензия с открытым исходным кодом, такая как MIT, GNU или Apache 2.0.
• Nuspec: Nuspec является файлом-манифестом. Это XML-файл, который используется для создания пакета NuGet. Про этот файл мы поговорим в следующем разделе.

Создание собственного пакета NuGet

Теперь вы понимаете, что такое пакеты, пакетные менеджеры и источники пакетов, и имеете общее представление о том, как NuGet вписывается в это пространство. Вы также понимаете, как создавать и ссылаться на свой собственный источник пакетов, используя не что иное, как простейшую паку с файлам. Осталось только научиться создавать собственный пакет NuGet. Чтобы проиллюстрировать это, я собираюсь использовать свою библиотеку неизменяемых классов, о которой я уже писал в прошлом.

Существует несколько подходов, которые можно использовать для создания пакетов NuGet. Я собираюсь показать вам метод, который я считаю самым понятным и простым в использовании. Есть также много других вариантов, которые вы можете применить, но я не буду здесь их описывать. Для полного охвата всего, что вы можете делать в рамках создания пакетов, обратитесь к документации на NuGet.org.

Шаг 1: Создайте структуру каталогов пакета (Package Directory Structure) и добавьте свои бинарники

Рисунок 6 иллюстрирует структуру каталогов.

Я добавил icon.png, который будет отображаться в пакетном менеджере, как показано на рисунке 1. Текстовый файл License содержит лицензию MIT. И, наконец, nuspec, показанный на рисунке 7:

Шаг 2: Создайте файл Nuspec

Файл nuspec, показанный на рисунке 7, очень прост.

Полную справку по nuspec можно найти здесь. Идентификатор (ID), который вы выбираете для своего пакета, должен быть уникальным в контексте источника, в котором он размещен. Соответственно, если вы решите сделать свой пакет NuGet доступным на NuGet.org, то идентификатор должен быть уникальным для этого источника. На рисунке 8 показано, как пакет отображается в пакетном менеджере NuGet:

Шаг 3: Создайте пакет NuGet

Чтобы создать пакет NuGet из командной строки, вам потребуются инструменты командной строки NuGet. На рисунке 9 показано, где можно скачать NuGet.exe.

На рисунке 10 показано, как создать пакет NuGet:

Шаг 4: Опубликуйте свой пакет

В зависимости от типа используемого источника пакетов ваши действия могут немного отличаться. Для источника-каталога процесс заключается в копировании файла в каталог. Если вы хостите свой собственный сервер NuGet, вам придется использовать один из методов, описанных здесь.

Другие варианты хостинга

Вместо самостоятельного хостинга или использования публичного NuGet.org вы можете выбрать стороннюю службу. Для NuGet существуют платные сервисы, такие как myget (myget.org) и Chocolatey (chocolatey.org). Если свой собственный источник так просто создать, то зачем вам может понадобиться платный сервис? Эти платные сервисы имеют собственную инфраструктуру аварийного восстановления (Disaster Recovery). Если вы хостите свой собственный источник, вам необходимо думать о том, как будет выполняться резервное копирование и репликация вашего сервера, а также как вы будете восстанавливаться в случае какого-либо катастрофического события.

Заключение

Опенсорс упростил добавление фич в ваши приложения. Частью этой простоты является скорость. Скорость и простота означают меньше “трения” (friction). Давным-давно, до опенсорса, каким мы его знаем сегодня, до интернета и до управления пакетами, в системе существовало неявное трение, которое давало нам время для оценки и анализа. Разработчики прошлого поколения, на мой взгляд, лучше разбирались в управлении изменениями. Они осознавали дисциплину и строгость, необходимые для снижения риска. При всех преимуществах современных технологий, а также скорости и простоте, которые мы получаем с ними, как никогда важно использовать методы снижения рисков, такие как те, что мы обсуждали в этой статье, потому что, если нам легче делать хорошие вещи, то также и злоумышленникам легче проворачивать их грязные делишки. Надежная защита и снижение рисков не бесплатны. Один из самых коварных негативных побочных эффектов бесплатного опенсорса — это ожидание того, что вещи, которые до сих пор имели цену, больше не имеют никакой цены. Учитывайте это в следующий раз, когда будете вводить пакет в вашу среду. Если ваша организация регулируется SOX, HIPAA, FINRA, PCI и т. д., и вы соответствуете этим требованиям, то вы не допустите такой ситуации.

Сегодня вечером в OTUS состоится открытый урок «Магические слова async / await», на котором разберем механизм, скрытый под ключевыми словами async/await. Также рассмотрим правильное использование этих ключевых слов и некоторые другие аспекты асинхронного программирования на C#. Регистрация по ссылке.

Where is nuget.exe?

Visual Studio seems to come with nuget, but what is the location of nuget.exe? Or Package Manager Console doesn’t use nuget.exe?

13.5k 6 6 gold badges 62 62 silver badges 91 91 bronze badges
asked Sep 21, 2017 at 17:08

2 Answers 2

Visual Studio 2015 uses various NuGet assemblies but it does not itself include NuGet.exe.

NuGet.exe can be downloaded from the NuGet web site:

answered Sep 22, 2017 at 10:53
47.4k 5 5 gold badges 95 95 silver badges 95 95 bronze badges
Feb 13, 2019 at 18:10

After downloading the command line tool from nuget.org/downloads you should find nuget.exe in %SystemRoot%\system32 — most likely C:\Windows\System32

Jul 12, 2019 at 9:27

As far as I know, If You have Visual studio you can find a copy of nuget.exe in C:\Windows\System32\.nuget\

Apr 21, 2021 at 15:44

Another great option nowadays is to use winget (if you have Windows 10 v1709 or greater). In the Command Prompt, enter:

winget install Microsoft.NuGet

(below follows some extra information for the curious mind) This will:

1. Install the official nuget.exe in your PC.
2. Create a Symbolic Link here: %localappdata%\microsoft\winget\links
3. Make the nuget.exe globally available for your user to call it from anywhere, since the aforementioned directory should be present in your user’s PATH variable.

answered Aug 9, 2022 at 20:31
Christiano Kiss Christiano Kiss
429 4 4 silver badges 9 9 bronze badges

Run winget as administrator, to prevent: «This command requires administrator privileges to execute.» And after installation, reboot if you want a newly opened command shell to pick up the new path.

Sep 19, 2022 at 19:08
how to Create a Symbolic Link here: %localappdata%\microsoft\winget\links ??
May 3, 2023 at 22:02

@Urasquirrel, if you’re using the winget install command above, you don’t have to create the Symbolic Link yourself. The winget will do it for you. The 3 steps above are just out of curiosity.

Saved searches

Use saved searches to filter your results more quickly

Cancel Create saved search

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

NuGet / Home Public

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run Add-Migration from NuGet package manager console, you get : The term ‘Add-Migration’ is not recognized #4308

rrelyea opened this issue Jan 17, 2017 · 10 comments

Run Add-Migration from NuGet package manager console, you get : The term ‘Add-Migration’ is not recognized #4308

rrelyea opened this issue Jan 17, 2017 · 10 comments

Comments

Contributor
rrelyea commented Jan 17, 2017 •

from internal bug: 368394 & 372378 & 378413

1. Create a 1.0 Core Web Application
2. F5
3. Register yourself as a user (click Register in upper right, fill in name and password, Register)
4. Add Movie.cs to the Models folder

public class Movie
public int ID < get; set; >
public string Title < get; set; >
public DateTime ReleaseDate < get; set; >
public string Genre < get; set; >
public decimal Price < get; set; >
>
5. Add Controller — scaffold controller with EF / views
6. Ctrl-F5, navigate to http://localhost:54365/Movies
7. Run EF migrations
Add-Migration AddMovies
Update-Database

ACTUAL
EF fails for me in an unexpected way:

PM> add-migration
add-migration : The term ‘add-migration’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is
correct and try again.
At line:1 char:1

add-migration

+ CategoryInfo : ObjectNotFound: (add-migration:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException

PM> update-database
update-database : The term ‘update-database’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path
is correct and try again.
At line:1 char:1

update-database

+ CategoryInfo : ObjectNotFound: (update-database:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException

The text was updated successfully, but these errors were encountered: