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

0
votes

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

1
c#asp.netentity-framework-6
EF 6.3? See this and this (it's fixed, pending a new release). Try the work around here or stay with 6.2 until 6.3.1 is released. - madreflection
downgrade to 6.2 , but thew issue is still there, the workaround is meant for asp.net core :/ thanks anyway - Francesco Iapicca
No, nothing in the posts I linked is about Core. Make sure you remove all references to 6.3 in the solution and close and reopen the solution because it'll supersede 6.2 wherever it is and it won't load 6.2 tooling if 6.3 had already been loaded. - madreflection
my bad downgrade worked! thanks, if you post it as answer i'll accept it - Francesco Iapicca
just for you to get the reputation for helping me out :) - Francesco Iapicca

1 Answers

1
votes

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.