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

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!

[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.

[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.