CODEWITHSUNDEEP
c#asp.netentity-framework-6
Francesco Iapicca
Francesco Iapicca

Reputation: 2667

Entity Framework: Error "Cannot bind argument to parameter 'Path' " on "database-update"

I'm getting this error when I try to update my database

Update-Database : Cannot bind argument to parameter 'Path' because it

is null. At line:1 char:2

  • Update-Database
  • CategoryInfo : InvalidData: (:) [Update-Database], ParameterBindingValidationException
  • FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Update-Database

can you point me in the right direction to solve the problem? thank you

Upvotes: 2

Views: 788

Answers (1)

madreflection
madreflection

Reputation: 4957

This bug has been reported on GitHub (see issues 1290, 1306, 1348). It was fixed (by the reporter of issue 1290) and is available in nightly builds. It was first scheduled for the 6.4.0 release (scheduled for late November/early December per this comment) but has since been moved to a 6.3.1 release. Neither milestone has a due date as of writing this.

The bug only affects EF Migrations and it only applies to using a Web Application project as the startup project (even if your entities and context are in different projects). If affects multiple commands (Enable-Migrations, Add-Migration, Update-Database, and Get-Migrations) because they call into the code that contains the bug.

If you need to use Migrations, either downgrade to version 6.2.0 or use one of the workarounds that have been identified.

If you downgrade, make sure do it to all projects that use it within the solution. If the 6.3.0 package is referenced by any project, the 6.3.0 PowerShell module will take precedence. You can use the "Manage NuGet Packages for Solution..." command from the solution node to help identify where 6.3.0 might still be installed in any projects. Once that's done, you'll need to close and reopen the project in order to load 6.2.0's PowerShell module.

Workarounds

If you want/need to use version 6.3 and you're encountering this error, there are several workarounds you can try. Here's what I've been able to put together:

  1. Use a Console Application as the startup project.

Because the bug only affects Web application projects, the conditional branch that has causes the error is never executed. If you already have a console application with the right connection string, you can use that. If you don't, you can add a dummy project for this purpose.

Note: If your connection string includes |DataDirectory|, this won't work because it avoids specifying the --data-dir argument in order to avoid the bug.

  1. Use a nightly build.

Although this works, it's probably a non-starter for a lot of projects because pre-release builds are generally disallowed in production. If your production release is still several months away, though, it might be an option if you're willing to proceed with the hope that a working release becomes available in time.

  1. Add a dummy project that references a nightly build.

Similar to using a nightly build, you're referencing it in an unused project in order to load the fixed PowerShell module. You would still reference the released version in the projects used by the application.

  1. Modify the local package in the shared cache location.

Caution: This is not a tenable solution for teams (or CI/CD environments) but it might be okay for an individual who wants to use a quick hack while waiting for the next release and doesn't mind reapplying it if the shared cache gets cleared.

If you're using PackageReference tags in your project files, assemblies are referenced in a shared cache location, usually under %USERPROFILE%\.nuget\packages. You can modify the file there as shown in issue 1290 and it will be used by all projects that use the package via PackageReference tags. If you're using packages.config you have to modify it in the packages folder and that's more likely to be lost.

I have tested all of these workarounds with successful outcomes.

Upvotes: 2

Related Questions