Я получаю эту ошибку, когда пытаюсь обновить свою базу данных
Update-Database: невозможно связать аргумент с параметром «Путь», потому что он
нулевой. В строке:1 символ:2
- Обновление базы данных
- CategoryInfo: InvalidData: (:) [Update-Database], ParameterBindingValidationException
- FullyQualifiedErrorId: ParameterArgumentValidationErrorNullNotAllowed, Update-Database
Можете ли вы указать мне в правильном направлении, чтобы решить проблему? благодарю вас
Об этой ошибке сообщалось на GitHub (см. вопросы 1290, 1306, 1348). Она была исправлена (репортером выпуска 1290) и доступна в ночных сборках. Впервые он был запланирован для выпуска 6.4.0 (запланирован на конец ноября/начало декабря). на этот комментарий), но с тех пор был перемещен в выпуск 6.3.1. Ни одна из вех не имеет срока выполнения на момент написания этой статьи.
Ошибка затрагивает только миграцию EF и применима только к использованию проекта веб-приложения в качестве стартового проекта (даже если ваши сущности и контекст находятся в разных проектах). Если влияет на несколько команд (Enable-Migrations, Add-Migration, Update-Database и Get-Migrations), поскольку они вызывают код, содержащий ошибку.
Если вам нужно использовать миграцию, либо перейдите на версию 6.2.0, либо используйте один из найденных обходных путей.
Если вы понизите версию, обязательно сделайте это для всех проектов, которые используют ее в решении. Если на пакет 6.3.0 ссылается любой проект, модуль PowerShell 6.3.0 будет иметь приоритет. Вы можете использовать команду "Управление пакетами NuGet для решения..." из узла решения, чтобы определить, где в каких-либо проектах все еще может быть установлена версия 6.3.0. Как только это будет сделано, вам нужно будет закрыть и снова открыть проект, чтобы загрузить модуль PowerShell версии 6.2.0.
Временные решения
Если вы хотите/нужно использовать версию 6.3 и столкнулись с этой ошибкой, вы можете попробовать несколько обходных путей. Вот что мне удалось собрать:
Поскольку ошибка затрагивает только проекты веб-приложений, условная ветвь, вызвавшая ошибку, никогда не выполняется. Если у вас уже есть консольное приложение с правильной строкой подключения, вы можете использовать его. Если вы этого не сделаете, вы можете добавить фиктивный проект для этой цели.
Примечание. Если ваша строка подключения включает |DataDirectory|, это не сработает, поскольку во избежание ошибки не указывается аргумент --data-dir.
Хотя это работает, вероятно, это не старт для многих проектов, потому что предварительные сборки, как правило, запрещены в производстве. Однако, если до выхода вашего рабочего релиза еще несколько месяцев, это может быть вариантом, если вы готовы продолжить работу в надежде, что рабочий релиз станет доступным вовремя.
Как и при использовании ночной сборки, вы ссылаетесь на нее в неиспользуемом проекте, чтобы загрузить фиксированный модуль PowerShell. Вы по-прежнему будете ссылаться на выпущенную версию в проектах, используемых приложением.
Предостережение: Это ненадежное решение для групп (или сред CI/CD), но оно может подойти для человека, который хочет использовать быстрый хак в ожидании следующего выпуска и не возражает повторно применить его, если общий кеш очищается.
Если вы используете теги PackageReference в файлах проекта, ссылки на сборки указываются в расположении общего кэша, обычно под %USERPROFILE%\.nuget\packages. Вы можете изменить там файл, как показано в задаче 1290, и он будет использоваться всеми проекты, которые используют пакет через теги PackageReference. Если вы используете packages.config, вам нужно изменить его в папке packages, и это более вероятно, будет потеряно.
Я протестировал все эти обходные пути с успешными результатами.
