Консоль диспетчера пакетов visual studio команды
Обновлено: 04.07.2024
Я пытаюсь обновить базу данных из консоли диспетчера пакетов.Если мой класс домена изменится, я должен удалить и создать базу данных, вместо того, чтобы удалять базу данных, как я могу обновить базу данных.
Я уже пробовал, читая некоторые блоги в google.
команды
С помощью этой команды я устанавливаю Entity Framework успешно.
С помощью этой команды он создал файл миграции в моем проекте.
укажите флаг "- Verbose " для просмотра инструкций SQL, применяемых к целевой базе данных. Система.Данные.В sqlclient.SqlException (0x80131904): связанные с сетью или при установлении соединения с SQL Server произошла ошибка конкретного экземпляра. Сервер не найден или недоступен. Убедитесь в правильности имени экземпляра и в том, что SQL Server настроен на разрешение удаленных подключений.
иногда он может обновляться, если только одно поле изменяется в поко класса. Например, я обновил больше количества класса домена ,как я могу обновить базу данных из пакета консоль диспетчера. Есть Идеи ?
вы можете указать строку подключения через :
во-вторых, не имеет значения, сколько полей вы меняете, они будут свернуты в одну миграцию на основе изменения после последней миграции.
Enable-Migrations -EnableAutomaticMigrations -Force
и это перенесло мои изменения (дополнительные столбцы) при сохранении моих тестовых данных. Я думаю, что это самый ленивый вариант при прототипировании.
вам нужно обновить SSDT перейдите в меню Сервис> расширение и обновления > обновления > SQL server data tools
куда поместить строку подключения?
вам не нужно указывать его с каждой команды в консоли диспетчера пакетов. Вы можете положить его в appsettings.в JSON в проекте, где находится ваш класс DbContext (чтение "из производного класса DbContext").
Он будет использоваться для миграции.
важно: если у вас несколько проектов в вашем решении, вы должны выберите проект в раскрывающемся списке "проект по умолчанию" (в консоли диспетчера пакетов) и вы должны установите проект в качестве проекта запуска (в обозревателе решений).
неспособность сделать это может привести к неправильным appsettings.json для использования с неправильной / другой connectionstring.
Это был мой опыт работы с EF Core 2.1 и, вероятно, относится к другим версиям EF.
Установка инструментов
установите средства консоли диспетчер пакетов, выполнив следующую команду в консоли диспетчер пакетов.
обновите средства, выполнив следующую команду в консоли диспетчер пакетов.
Проверка установки
Убедитесь, что средства установлены, выполнив следующую команду:
Выходные данные выглядят следующим образом (он не указывает, какую версию инструментов вы используете):
Использование средств
Перед использованием средств:
Целевой и запускаемый проекты
Команды ссылаются на проект и запускаемый проект.
Проект также называется целевым проектом , так как он служит для добавления или удаления файлов. по умолчанию проект по умолчанию , выбранный в консоли диспетчер пакетов , является целевым. Можно указать другой проект в качестве целевого проекта с помощью параметра.
Запускаемый проект — это тот, который выполняет сборка и запуск средств. Средства должны выполнять код приложения во время разработки для получения сведений о проекте, таких как строка подключения к базе данных и Конфигурация модели. по умолчанию Project запуска в обозреватель решений является запускаемым проектом. Можно указать другой проект в качестве запускаемого проекта с помощью параметра.
Запускаемый проект и целевой проект часто являются одним и тем же проектом. Типичный сценарий, в котором они являются отдельными проектами, состоит в следующих случаях:
Другие целевые платформы
Начиная с EF Core 5,0, дополнительные аргументы также могут передаваться в Program. Креатехостбуилдер, что позволяет указать среду в командной строке:
Общие параметры
В следующей таблице приведены параметры, которые являются общими для всех EF Coreных команд.
| Параметр | Описание |
|---|---|
| Класс DbContext для использования. Только имя класса или полный квалификатор с пространствами имен. Если этот параметр опущен, EF Core находит класс контекста. Если имеется несколько классов контекста, этот параметр является обязательным. | |
| Целевой проект. если этот параметр не указан, в качестве целевого проекта используется проект по умолчанию для диспетчер пакетов консоли . | |
| Автоматически запускаемый проект. Если этот параметр не указан, в качестве целевого проекта используется запускаемый проект в свойствах решения . | |
| Аргументы, передаваемые в приложение. Добавлено в EF Core 5,0. | |
| -Verbose | Отображение подробных выходных данных. |
Чтобы отобразить справочные сведения о команде, используйте команду PowerShell Get-Help .
Context Параметры, Project и StartupProject поддерживают расширение клавишей TAB.
Add-Migration
Добавляет новый перенос.
| Параметр | Описание |
|---|---|
| Имя миграции. Этот параметр является позиционированным и является обязательным. | |
| Каталог используется для вывода файлов. Пути задаются относительно целевого каталога проекта. По умолчанию используется значение "миграции". | |
| Пространство имен, используемое для создаваемых классов. По умолчанию создается из выходного каталога. Добавлено в EF Core 5,0. |
Drop-Database
Удаляет базу данных.
| Параметр | Описание |
|---|---|
| Показывает, какую базу данных следует удалить, но не удалять. |
Get-DbContext
Перечисляет и получает сведения о доступных DbContext типах.
Get-Migration
Список доступных миграций. Добавлено в EF Core 5,0.
| Параметр | Описание |
|---|---|
| Строка подключения к базе данных. По умолчанию используется значение, указанное в AddDbContext или onconfiguring. | |
| Не подключайтесь к базе данных. |
Remove-Migration
Удаляет последнюю миграцию (выполняет откат изменений кода, выполненных для миграции).
| Параметр | Описание |
|---|---|
| Отмените миграцию (выполните откат изменений, примененных к базе данных). |
Scaffold-DbContext
Создает код для DbContext типов сущностей и для базы данных. Scaffold-DbContext Чтобы создать тип сущности, таблица базы данных должна иметь первичный ключ.
Пример: формирование шаблонов только для выбранных таблиц и создание контекста в отдельной папке с указанным именем и пространством имен.
В следующем примере считывается строка подключения из конфигурации проекта, которая может быть задана с помощью средства диспетчера секретов.
Optimize-DbContext
Создает скомпилированную версию модели, используемую DbContext . Добавлено в EF Core 6.
Дополнительные сведения см. в разделе скомпилированные модели .
| Параметр | Описание |
|---|---|
| Каталог для размещения файлов. Пути задаются относительно каталога проекта. | |
| Пространство имен, используемое для всех создаваемых классов. По умолчанию создается из корневого пространства имен и выходного каталога плюс CompiledModels . |
Пример, в котором используются значения по умолчанию и работает, если в проекте имеется только один элемент DbContext :
Пример, который оптимизирует модель для контекста с заданным именем AMD помещает его в отдельную папку и пространство имен:
Script-DbContext
создает скрипт SQL из DbContext. Обход всех миграций. Добавлено в EF Core 3,0.
| Параметр | Описание |
|---|---|
| Файл, в который записывается результат. |
Script-Migration
создает скрипт SQL, который применяет все изменения из одной выбранной миграции к другой выбранной миграции.
| Параметр | Описание |
|---|---|
| Начало миграции. Миграция может быть идентифицирована по имени или по ИДЕНТИФИКАТОРу. Число 0 — это особый случай, который означает перед первой миграцией. Значение по умолчанию — 0. | |
| Завершение миграции. По умолчанию используется последняя миграция. | |
| Создание скрипта, который может использоваться в базе данных при любой миграции. | |
| не создавайте инструкции SQL transaction. Добавлено в EF Core 5,0. | |
| Файл, в который записывается результат. Если этот параметр не указан, файл создается с именем, созданным в той же папке, что и файлы среды выполнения приложения, например: /obj/Debug/netcoreapp2.1/ghbkztfz.SQL/. |
To Параметры, From и Output поддерживают расширение клавишей TAB.
В следующем примере создается скрипт для миграции InitialCreate (из базы данных без каких-либо миграций) с использованием имени миграции.
В следующем примере создается скрипт для всех миграций после миграции InitialCreate с использованием идентификатора миграции.
Update-Database
Обновляет базу данных до последней миграции или до указанной миграции.
| Параметр | Описание |
|---|---|
| Целевая миграция. Миграция может быть идентифицирована по имени или по ИДЕНТИФИКАТОРу. Число 0 — это особый случай, который означает перед первой миграцией и приводит к отмене всех миграций. Если миграция не указана, команда по умолчанию принимает значение последней миграции. | |
| Строка подключения к базе данных. По умолчанию используется значение, заданное в AddDbContext или OnConfiguring . Добавлено в EF Core 5,0. |
Migration Параметр поддерживает расширение клавиш TAB.
В следующем примере возвращаются все миграции.
В следующих примерах база данных обновляется до указанной миграции. В первом случае используется имя миграции, а во втором используется идентификатор миграции и указанное соединение:
Использование миграции - это стандартный способ создания и обновления базы данных с помощью Entity Framework Core. Процесс миграции состоит из двух этапов: создание миграции и применение миграции. Как мы уже говорили, схема нашей базы данных должна быть согласована с моделью базы данных, и каждое изменение в модели базы данных необходимо переносить в саму базу данных.
Эти изменения могут быть, например, следующими:
- Изменения в свойствах класса модели
- Изменения конфигурации
- Добавление или удаление свойств DbSet<T> из класса контекста
Чтобы создать миграцию, мы можем использовать окно консоли диспетчера пакетов Visual Studio или командное окно (командная строка Windows) :
Добавление миграции Add-Migration MigrationName [options]
Или через интерфейс командной строки dotnet:
dotnet ef migrations добавить MigrationName [options]
В нашем приложении мы собираемся использовать Консоль диспетчера пакетов (PMC), поэтому давайте сделаем это, набрав:
PM> Add-Migration InitialMigration
После того, как мы нажмем клавишу Enter, наша миграция будет завершена.
Действия, которые происходят за кулисами
Файл ApplicationContextModelSnapshot.cs содержит модель базы данных и обновляется каждый раз при добавлении новой миграции. Два других файла: InitialMigration и InitialMigration.Designer - это файлы, содержащие и описывающие вновь созданную миграцию.
Итак, если вы выполнили все шаги из предыдущих статей, содержимое файла InitialMigration должно выглядеть следующим образом:
В этом файле есть два метода с удобными названиями Up и Down . Метод Up состоит из команд, которые будут выполнены, когда мы применим эту миграцию. В качестве противоположного действия метод Down будет выполнять команды, когда мы откатываем эту миграцию (в этом случае он просто удалит созданную таблицу).
Применение созданной миграции
После того, как мы успешно создали нашу миграцию, мы должны применить ее, чтобы изменения вступили в силу в базе данных. Существует несколько способов применения миграции (с использованием сценариев SQL, с использованием метода Database.Migrate или с использованием методов командной строки), и, как мы делали с созданием, мы собираемся использовать подход методов командной строки.
Для консоли диспетчера пакетов команда:
Update-Database [options]
Для окна командной строки команда:
dotnet ef database update [options]
Поскольку мы уже определились с PMC, давайте откроем окно PMC и выполним команду:
После нажатия клавиши Enter мы увидим все различные действия, которые EF Core выполняет для нас, чтобы применить созданную миграцию. В результате у нас будет таблица Student , созданная со всей предоставленной конфигурацией из предыдущих статей:
Есть еще несколько важных фактов, которые нам нужно знать о миграции EF Core. Если мы проверим нашу базу данных, мы найдем еще одну созданную таблицу: _EFMigrationsHistory . EF Core использует эту таблицу для отслеживания всех примененных миграций. Таким образом, это означает, что если мы создадим еще одну миграцию в нашем коде и применим ее, EF Core применит только недавно созданную миграцию.
Но как EF Core узнает, какую миграцию нужно применить?
Ну, он сохраняет уникальный идентификатор в _EFMigrationsHistory , который представляет собой уникальное имя файла миграции, созданного при миграции, и никогда больше не выполняет файлы с тем же именем:
Каждая миграция применяется внутри транзакции SQL, что означает, что вся миграция либо завершается успешно, либо не выполняется. Если нам нужно применить несколько миграций, они будут применяться в точном порядке их создания.
Добавление собственного кода в файл миграции
Мы уже объяснили назначение методов Up и Down в нашем файле InitialMigration . Но весь код в этих методах генерируется EF Core. При необходимости мы также можем добавить наш собственный код. Мы можем использовать параметр MigrationBuilder для доступа к широкому спектру методов, которые могут помочь нам в этом процессе. Одним из таких методов является метод Sql , который мы можем использовать для добавления желаемого пользовательского кода.
Итак, давайте откроем класс InitialMigration и изменим его, добавив наш собственный код:
Мы должны убедиться, что метод Sql в методе Down выполняет противоположные действия, если мы решим удалить нашу миграцию.
Теперь мы можем удалить нашу базу данных (просто для имитации начального состояния на сервере SQL) и снова применить нашу миграцию (нам не нужно ее создавать, она уже создана).
Создание миграции, если объекты и файлы Dbcontext находятся в отдельном проекте
Сейчас наша модель и классы контекста находятся в основном проекте вместе с файлами миграции. Но во многих реальных проектах модели и классы контекста находятся в отдельном проекте. Для таких проектов выполнение миграции было бы невозможно с настройкой, как в нашем проекте.
Попробуем продемонстрировать, что мы имеем в виду.
PM> Install-Package Microsoft.EntityFrameworkCore -Version 3.1.0
PM> Install-Package Microsoft.EntityFrameworkCore.Relational -Version 3.1.0
Затем нам нужно добавить ссылку на проект Entities в нашем основном проекте.
Как только мы это сделаем, нам нужно изменить пространство имен в классах ApplicationContext и Student с EFCoreApp.Entities на просто Сущности . Кроме того, мы должны сделать то же самое для директив using в классе Startup и в всех трех файлах миграции.
После всего этого наш проект должен успешно собраться.
Добавление новой миграции
Теперь мы можем попробовать добавить еще одну миграцию, набрав:
PM> Add-Migration TestMigrationFromSeparateProject
Все, что нам нужно сделать, это изменить нашу сборку миграции, поэтому давайте сделаем именно это в классе Startup :
Теперь мы можем снова запустить ту же команду, но на этот раз она будет выполнена успешно. Мы успешно создали нашу новую миграцию вместе с файлами миграции в папке Migrations :
Мы видим, что в файле TestMigration нет кода в методах Up и Down , и это нормально, потому что мы не изменить что-либо, но мы выполнили требуемую задачу.
Удаление миграции
Мы узнали, как создавать миграции из отдельного проекта. Но в результате мы создали пустую миграцию, которая ничего не делает в нашей базе данных. Когда мы создаем миграцию, которая нас не устраивает, мы можем легко удалить ее, набрав команду Remove-Migration [options] в окне PMC. Итак, давайте сделаем это:
Через несколько секунд наша предыдущая миграция будет удалена:
Отлично, теперь мы можем двигаться дальше.
Исходные данные в Entity Framework Core
В большинстве наших проектов мы хотим иметь некоторые исходные данные в созданной базе данных. Итак, как только мы выполним наши файлы миграции для создания и настройки базы данных, мы захотим заполнить ее некоторыми исходными данными. Это действие называется заполнением данных.
Мы можем создать код для действия заполнения в методе OnModelCreating с помощью ModelBuilder , как мы это сделали для конфигурации Fluent API. Итак, давайте добавим несколько строк в таблицу Student :
Итак, мы используем метод HasData , чтобы информировать EF Core о данных, которые он должен заполнить. Остальная часть кода не требует пояснений, потому что мы просто добавляем необходимые данные. Мы не используем свойство IsRegularStudent , потому что мы создали конфигурацию для этого свойства, чтобы иметь значение по умолчанию.
Теперь мы можем создать новую миграцию:
PM> Add-Migration SeedInitialData
И примените его:
Мы можем проверить нашу таблицу, чтобы проверить результат:
Лучший способ применения конфигурации и начального числа данных
Мы можем поместить весь код конфигурации в метод OnModelCreating , и он будет работать так, как должен. Как мы видим, наш метод OnModelCreating удобен для чтения и прост в обслуживании. Но что, если бы у нас был более крупный проект с большим количеством классов и данных для заполнения? Наш метод станет трудно читать и поддерживать.
EF Core предоставляет лучший способ создания конфигурации Fluent API с помощью интерфейса IEntityTypeConfiguration<T> . Используя его, мы можем разделить конфигурацию для каждой сущности на отдельный класс конфигурации.
Итак, давайте посмотрим, как это сделать.
В проекте Entities мы собираемся создать новую папку Configuration и внутри нового класса StudentConfiguration :
Конечно, мы не хотим генерировать исключение (это код по умолчанию после того, как VS реализует интерфейс), поэтому давайте изменим этот метод:
Этот код немного отличается от старого кода OnModelCreating , поскольку нам больше не нужно использовать часть .Entity<Student> . Это потому, что наш объект построителя уже имеет тип EntityTypeBuilder<Student> . Мы добавили дополнительный объект для вставки, просто чтобы было что создать миграцию.
Все, что нам нужно сделать, это изменить метод OnModelCreating :
Теперь мы можем добавить новую миграцию и применить ее:
PM> Add-Migration AdditionalRowInserted
Настройте начальную миграцию сразу после запуска приложений
Для каждой созданной миграции нам приходилось вносить изменения вручную. И это нормально. Но когда мы развертываем наше приложение, было бы неплохо иметь исходные данные в этот момент в базе данных.
Что было бы еще лучше, так это то, что нам не нужно было делать это вручную, а нужно было запускать все необходимые миграции и заполнять все необходимые данные сразу после запуска приложения.
Конечно, помимо того, что он полезен при развертывании, он помогает при совместном использовании или разработке нашего приложения с другими людьми. Мы бы хотели, чтобы они запустили приложение и выполнили все миграции до того, как приложение настроится.
Что ж, мы покажем вам, как именно это сделать.
Создание метода расширения
Давайте создадим новый класс MigrationManager в проекте Entities . Это будет статический класс, потому что мы собираемся создать метод расширения для запуска всех миграций при запуске приложения:
Теперь нам нужно установить библиотеку Microsoft.ASPNetCore.Hosting.Abstractions (она нужна нам для типа IHost, который мы собираемся использовать в нашем методе расширения) и добавить MigrateDatabase метод расширения для этого класса:
Мы используем тип IHost , потому что это позволяет нам связать этот метод в файле Program.cs и, конечно же, как вы можете видеть, он нам нужен для основной логики. .
Итак, мы создаем область службы и используем ее с ServiceProvider для получения экземпляра класса ApplicationContext . В первой статье мы обсудили свойства, содержащиеся в классе DbContext , и теперь мы используем один из них (базу данных) для вызова метода Migrate для выполнения миграции.
Применение метода MigrateDatabase
Следующим шагом является вызов этого метода в классе Program.cs :
Наконец, давайте удалим таблицы Student и _EFMigrationsHistory из базы данных и удалим хранимую процедуру в папке Programmability, чтобы имитировать пустую базу данных (или просто отбросим вашу базу данных: D). Затем мы можем запустить наше приложение. Мы увидим журналы в окне консоли, которые сообщают нам, что миграции выполняются. После того, как миграции завершили свою работу, мы можем проверить базу данных, чтобы убедиться, что все таблицы и процедуры были созданы снова.
Откат и создание сценариев миграции
В одном из предыдущих разделов мы узнали, как откатить миграцию, если мы ее не применили. Но в случае, если у нас есть, мы не можем удалить его просто так, нам нужно вернуть его к конкретной миграции.
Итак, чтобы показать, как работает возврат миграции, мы собираемся добавить еще одну строку в класс StudentConfiguration , создать, применить миграцию и затем вернуть ее к предыдущим значениям.
Сначала добавим в начальное число еще одну строку:
Тогда давайте создадим:
PM> Add-Migration RevertTestMigration
и примените миграцию:
В базе данных мы видим, что добавлена новая строка. Но так как мы не удовлетворены этим переносом (гипотетически), давайте вернем его:
PM> Update-Database AdditionalRowInserted
Миграция AdditionalRowInserted была предыдущей, и если мы проверим нашу базу данных сейчас, мы увидим, что она была возвращена к определенным значениям миграции.
Наконец, если мы хотим создать сценарий SQL для всех наших миграций, мы можем сделать это, набрав:
Эта команда создаст для нас файл сценария.
Заключение
Итак, мы узнали много различной информации о миграции данных и о том, как ее использовать в различных ситуациях в EF Core.
Консоль диспетчера пакетов NuGet позволяет использовать команды PowerShell NuGet для поиска, установки, удаления и обновления пакетов NuGet. Это удобно, когда пользовательский интерфейс диспетчера пакетов не позволяет выполнять операции. См. подробнее об использовании CLI nuget.exe в консоли.
Консоль встроена в Visual Studio для Windows. Она не включена в Visual Studio для Mac и Visual Studio Code.
Перечисленные здесь команды относятся только к консоли диспетчера пакетов в Visual Studio и отличаются от команд модуля "Управление пакетами", доступных в общей среде PowerShell. В частности, в каждой среде есть команды, недоступные в другой среде, а в командах с тем же именем могут отличаться некоторые аргументы. При использовании консоли "Управление пакетами" в Visual Studio применяются команды и аргументы, описанные в этой статье.
Поиск и установка пакета
Для поиска и установки пакета необходимо выполнить три простых шага:
Откройте проект или решение в Visual Studio, а затем откройте консоль, щелкнув Средства > Диспетчер пакетов NuGet > Консоль диспетчера пакетов.
Найдите пакет, который требуется установить. Если вы уже знакомы с этим процессом, перейдите к шагу 3.
Выполните команду установки:
Все операции, доступные в консоли, также можно выполнить с помощью CLI NuGet. Но команды консоли работают в контексте Visual Studio и сохраненного проекта или решения, и область их применения часто шире, чем у их эквивалентов в CLI. Например, при установке пакета с помощью консоли добавляется ссылка на проект, а при использовании команды CLI этого не происходит. По этой причине разработчики, работающие в Visual Studio, обычно предпочитают использовать консоль вместо CLI.
Открытие консоли и элементов управления консоли
Откройте консоль в Visual Studio, щелкнув Средства > Диспетчер пакетов NuGet > Консоль диспетчера пакетов. Консоль — это окно Visual Studio, которое может быть упорядочено и размещено по вашему усмотрению (см. руководство по настройке макетов окон в Visual Studio).
По умолчанию команды консоли работают с конкретным источником пакета и проектом, как указано в элементе управления в верхней части окна.
Выбор другого источника пакета или проекта изменяет эти значения по умолчанию для последующих команд. Чтобы переопределить эти настройки, не меняя значения по умолчанию, большинство команд поддерживают параметры -Source и -ProjectName .
Чтобы управлять источниками пакетов, щелкните значок шестеренки. Это ярлык для диалогового окна Средства > Параметры > Диспетчер пакетов NuGet > Источники пакетов, как описано на странице, посвященной пользовательскому интерфейсу диспетчера пакетов. Кроме того, элемент управления справа от средства выбора проектов очищает содержимое консоли.
Установка пакета
При установке пакета в консоли выполняются те же действия, которые описаны в руководстве по установке пакета NuGet, со следующими дополнениями:
- Консоль отображает применимые условия лицензии в окне с соответствующим соглашением. Если вы не согласны с условиями, следует сразу же удалить пакет.
- Кроме того, ссылка на пакет добавляется в файл проекта и отображается в обозревателе решений в узле Ссылки. Сохраните проект, чтобы просмотреть изменения непосредственно в файле проекта.
Удаление пакета
См. подробнее об Uninstall-Package. Если необходимо найти идентификатор, чтобы просмотреть все пакеты, установленные в проекте по умолчанию, используйте команду Get-Package.
При удалении пакета выполняются следующие действия:
- Удаляются ссылки на пакет из проекта (и любого используемого формата управления). Ссылки больше не отображаются в обозревателе решений (возможно, потребуется перестроить проект, чтобы он был удален из папки Bin).
- Отменяются все изменения, внесенные в app.config или web.config при установке пакета.
- Удаляются ранее установленные зависимости, если остальные пакеты не используют эти зависимости.
Обновление пакета
Поиск пакета
См. подробнее о Find-Package. В Visual Studio 2013 и более ранних версиях используйте команду Get-Package.
Доступность консоли
Консоль диспетчера пакетов сейчас недоступна в Visual Studio для Mac. Но аналогичные команды доступны через CLI NuGet. В Visual Studio для Mac есть пользовательский интерфейс для управления пакетами NuGet. См. подробнее о включении пакета NuGet в проект.
Консоль диспетчера пакетов не входит в Visual Studio Code.
Расширение консоли диспетчера пакетов
Настройка профиля PowerShell NuGet
Профиль PowerShell позволяет сделать часто используемые команды доступными при использовании PowerShell. NuGet поддерживает профиль NuGet, который обычно находится в следующем расположении:
Миграции Entity Framework обрабатываются из консоли диспетчера пакетов в Visual Studio. Использование показано в различных руководствах, но я не нашел полного списка доступных команд и их использования, поэтому я создал свою собственную. Есть четыре доступные команды.
-
: Включает первые миграции кода в проекте. : Scaffolds скрипт миграции для любых ожидающих изменений модели. : применяет любые отложенные миграции к базе данных. : отображает миграции, которые были применены к целевой базе данных.
Информация здесь представляет собой вывод команды get-help command-name -detailed для каждой из команд в консоли диспетчера пакетов (работает EF 4.3.1). Я также добавил несколько собственных комментариев, где, по-моему, отсутствует информация. Мои собственные комментарии размещены под заголовком Дополнительная информация .
Обратите внимание, что все команды должны вводиться в одной строке. Я добавил разрывы строк, чтобы избежать вертикальных полос прокрутки.
Включает кодовую первую миграцию в проекте.
Синтаксис
Описание
Включает Миграции, добавляя в проект класс конфигурации миграции. Если целевая база данных была создана инициализатором, будет создана начальная миграция (если автоматические миграции не включены с помощью параметра EnableAutomaticMigrations).
параметры
-EnableAutomaticMigrations
Определяет, будут ли включены автоматические миграции в конфигурации миграции лесов. Если пропущено, автоматические миграции будут отключены.
-ProjectName <String>
Задает проект, в который будет добавлен класс конфигурации миграции леса. Если опущен, используется проект по умолчанию, выбранный в консоли диспетчера пакетов.
-Force
Указывает, что конфигурация миграции будет перезаписана при запуске более одного раза для данного проекта.
<CommonParameters>
Этот командлет поддерживает общие параметры: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction, WarningVariable, OutBuffer и OutVariable. Для получения дополнительной информации введите: get-help about_commonparameters.
замечания
Чтобы увидеть примеры, введите: get-help Enable-Migrations -examples.
Для получения дополнительной информации введите: get-help Enable-Migrations -detailed.
Для получения технической информации введите: get-help Enable-Migrations -full.
Дополнительная информация
Флаг включения автоматических миграций сохраняется в файле Migrations \ Configuration.cs в конструкторе. Чтобы позже изменить опцию, просто измените назначение в файле.
Помещает скрипт миграции для любых ожидающих изменений модели.
Синтаксис
Описание
Scaffolds новый скрипт миграции и добавляет его в проект.
параметры
Имя <String>
Определяет имя пользовательского скрипта.
-Force
Указывает, что код пользователя миграции будет перезаписан при повторной установке существующей миграции.
-ProjectName <String>
Определяет проект, который содержит тип конфигурации миграции, который будет использоваться. Если не указан, используется проект по умолчанию, выбранный в консоли диспетчера пакетов.
-StartUpProjectName <String>
Указывает файл конфигурации для использования для именованных строк подключения. Если опущен, используется файл конфигурации указанного проекта.
-ConfigurationTypeName <String>
Определяет конфигурацию миграции для использования. Если опущено, миграции будут пытаться найти один тип конфигурации миграции в целевом проекте.
-ConnectionStringName <String>
Определяет имя строки подключения для использования из файла конфигурации приложения.
-ConnectionString <String>
Определяет строку подключения для использования. Если опущено, будет использовано контекстное соединение по умолчанию.
Читайте также: