EF 6.3.0 PMC commands throw ParameterBindingValidationException when Startup Project is a Web App

[Psypher9]

This issue is meant to provide more light on #492 and offer a solution. I made a more detailed explanation and proposed mitigation there, but I will copy my comment here:

I realize that this issue is closed but I too have started seeing this issue and thought this might be helpful still.

Here's my solution set up:

• .NET Framework 4.7.2 Web App (here called Project)
• I have placed my Models, Migrations, and DbContext in a separate project Project.Data

My repro steps are:

1. Start by using EF 6.2.0
2. Update-Package EntityFramework to use 6.3.0
3. Run Add-Migration ANewMigration
4. Receive:

Add-Migration : Cannot bind argument to parameter 'Path' because it is null.
At line:1 char:1
+ Add-Migration -StartUpProjectName Pegasus -ProjectName Pegasus.Data - ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Add-Migration], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Add-Migration

I debugged the NuGet package locally and found that this was consistently happening on each of the PMC commands.

Furthermore, I found that this ParameterBindingValidationException is happening here:

    if (IsWeb $startupProject)
    {
        $params += '--data-dir', (Join-Path $startupProjectDir 'App_Data')
    }

on line 918 of src/NuGet/EntityFramework/tools/EntityFramework6.psm1

I noticed that $startupProjectDir is the path for Join-Path but it is not defined at any place in the PMC for that version.

Locally, I was able to resolve this by updating these lines like this:

    if (IsWeb $startupProject)
    {                
        $startupProjectDir = GetProperty $startupProject.Properties 'FullPath'        
        $params += '--data-dir', (Join-Path $startupProjectDir 'App_Data')
    }

This allowed me to use the PMC from an external project. I hope this helps!

P.S. I started a new .NET Framework 4.7.2 web app, with Models and DbContext in the same project and installed EF 6.3.0 right off and still received the same error.

I'd be happy to submit a PR for this if you guys are up for it. Just let me know!

[fetters5]

Can confirm that I have the same issue with the same scenario

[bricelam]

@Psypher9 Please feel free to submit a PR
(But don't worry, we'll still fix it if you don't 😉)

[Psypher9]

@bricelam, on it! 😃

[bricelam]

FYI, this fix is included in our daily builds (see link for setup instructions). Feel free to start using it today via the version 6.4.0-preview1-* prerelease packages.

[ckotzbauer]

@bricelam Is there a due date when this fix is released in a stable version. (6.4.0 or 6.3.1) I cannot bring a daily build to production 😄

[bricelam]

As Scott Hunter said during dotNETConf: "Late November, early December"

[ErikEJ]

You only need this for designtime, not runtime??

[bricelam]

True.

Workaround

You could install the daily build into a dummy project just so the Update-Database command works

[bennbenson]

@bricelam Not to put too fine a point on it, but I'm disappointed by the lack of urgency. It's a blocking issue for what I'm sure is a very common use case and it's already been fixed. The real flood of developers encountering this issue is imminent; not everyone will do the due diligence of testing migrations before committing themselves to this version, leaving them stuck when they encounter the error. That I bothered to test it before committing to it was due to paranoia. But is it really paranoia if it doesn't actually work?

This has been a long-awaited release for my team. We inherited an application that uses the hierarchyid type and so it's had to use the EntityFrameworkWithHierarchyId package, the latest of which is still based on EntityFramework 6.1.3. Upgrading to 6.3 was going to allow us to:

1. Get the application using an official release package, as it ought to be,
2. Take advantage of the latest EF features and, more importantly, performance improvements,
3. Keep the hierarchyid type support that (sadly) it needs,
4. Be confident that it would work the same because it's the exact same commit (from zgabi) that provides that support in both packages, and
5. Not have to build two versions of class libraries that have to reference EF.

I'll admit that I'm not making the connection on how the dummy project would do the job. Maybe some more details on that would help. How would that work? Would it involve a project that has to be added to the repo? I don't understand how having the corrected script in a preview version of the package would affect the 6.3 package.

Meanwhile, we're still on packages.config and don't have the latitude to change to PackageReference at this time, so the package--in its flawed form--will be downloaded to the packages folder on each developer's machine, and to each temporary location on the build server when it does a build (we don't run migrations as a build step but someone out there surely does). If I could use PackageReference, I could apply the workaround in the shared cache location and it would apply across all projects. Again, I'm not there yet.

Please forgive my impatience but this is such a small and easy-to-fix fixed thing to have thwarted an entire point release. After waiting over a year since zgabi's PR was accepted (2018-08-10), I'm still unable to use it even though it's finally been released.

[bricelam]

I'm disappointed by the lack of urgency.

The issue is fixed in the daily builds. Our team is not in control of the ship dates. These are determined at a much higher level and are usually tied to Visual Studio releases.

I'll admit that I'm not making the connection on how the dummy project would do the job.

The Package Manager Commands are loaded into the Visual Studio process. Only the highest version is loaded. If you added a new dummy console app to the solution and installed the daily build of the EntityFramework into it, that version of the commands which includes the fix would be used. The commands would work just fine with projects referencing EF 6.3.

[oliverjanik]

Can you guys ship this as 6.3.1? just this one bug fix as a hot patch??

[ajcvickers]

@oliverjanik This will be in a patch, but unfortunately there is a lengthy process for patches which means it usually takes a long time from when the fix is made until when it can be shipped. You can get the fix sooner by using the daily builds of 6.4.

[oliverjanik]

Sorry, I am not risking deploying unstable version to production. But then again every version since 6.1.3 seems unstable.

It seems to me your release process is broken.

[bricelam]

deploying unstable version to production

As the workaround above suggest, install it into a dummy project. This avoids actually deploying it.

[danm-de]

@ajcvickers do you know when 6.3.1 will be available? I would rate this bug as show stopper because without the suggested work-a-round:

• The user cannot create migrations, do database updates etc. using VS integrated Package Manager Console.
• It breaks automated builds using the powershell module.
• Costs a lot of $$$ developer time asking Google about this new strange error message they got after NuGet-Update.

[ajcvickers]

@danm-de It will be in 6.4, released on December 3. The current 6.4 preview is the same code as will be shipped on December 3 as GA/RTM.

[danm-de]

@ajcvickers Thanks. 👍