efcore: Can't run ef commands using Directory.Build.props with seperate project and startup project

Upgrading to ASP.Net Core 2.1 added a new recommendation for using Docker as a development environment, which is to add a Directory.Build.props file that will specify where to put the BaseIntermediateOutputPath and BaseOutputPath depending on the executing environment.

With the Directory.Build.props in place everything works as expected except dotnet ef commands. I’m running dotnet ef migrations list -s ./Y/ -p ./X/ The error generated is,

X/X.csproj : error MSB4057: The target "GetEFProjectMetadata" does not exist in the project.
Unable to retrieve project metadata. Ensure it's an MSBuild-based .NET Core project. If you're using custom BaseIntermediateOutputPath or MSBuildProjectExtensionsPath values, Use the --msbuildprojectextensionspath option.

By following the error’s recommendation and adding the --msbuildprojectextensionspath option with the value obj/local, i.e. dotnet ef migrations list -s ./Y/ -p ./X/ --msbuildprojectextensionspath ./X/obj/local, the error reoccurs though now it’s requesting that the other project in question’s --msbuildprojectextensionspath be given. Error meesage

Y/Y.csproj : error MSB4057: The target "GetEFProjectMetadata" does not exist in the project.
Unable to retrieve project metadata. Ensure it's an MSBuild-based .NET Core project. If you're using custom BaseIntermediateOutputPath or MSBuildProjectExtensionsPath values, Use the --msbuildprojectextensionspath option.

Running this now with dotnet ef migrations list -s ./Y/ -p ./X/ --msbuildprojectextensionspath ./Y/obj/local everything works as expected.

Directory.Build.props contents are,

<Project>

  <PropertyGroup>
    <DefaultItemExcludes>$(DefaultItemExcludes);$(MSBuildProjectDirectory)/obj/**/*</DefaultItemExcludes>
    <DefaultItemExcludes>$(DefaultItemExcludes);$(MSBuildProjectDirectory)/bin/**/*</DefaultItemExcludes>
  </PropertyGroup>

  <PropertyGroup Condition="'$(DOTNET_RUNNING_IN_CONTAINER)' == 'true'">
    <BaseIntermediateOutputPath>$(MSBuildProjectDirectory)/obj/container/</BaseIntermediateOutputPath>
    <BaseOutputPath>$(MSBuildProjectDirectory)/bin/container/</BaseOutputPath>
  </PropertyGroup>

  <PropertyGroup Condition="'$(DOTNET_RUNNING_IN_CONTAINER)' != 'true'">
    <BaseIntermediateOutputPath>$(MSBuildProjectDirectory)/obj/local/</BaseIntermediateOutputPath>
    <BaseOutputPath>$(MSBuildProjectDirectory)/bin/local/</BaseOutputPath>
  </PropertyGroup>

</Project>

The directory structure of the project is,

/
  Directory.Build.props
  src/
     X/
        X.csproj
     Y/
        Y.csproj

I’m running this in the local environment and all commands were run form the src directory.

This looks similar to #8816, though I’m not sure how to get this work with Directory.Build.props. Can you please assist in providing a solution to this issue?

Further technical details

EF Core version: 2.1.0 Database Provider: Microsoft.EntityFrameworkCore.SqlServer Operating system: mac OS 10.13 IDE: Visual Studio Code

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 6
  • Comments: 26 (12 by maintainers)

Commits related to this issue

Most upvoted comments

Same problem here. Workaround: dotnet ef migrations list --msbuildprojectextensionspath obj/local

I meant to say building and debugging works without any issues with my Directory.Build.props file. I am getting below error whether or not I specify the --msbuildprojectextensionspath switch (I tried with both absolute and relative paths to my obj folder):

C:\Users\User1\Source\Repos\Server\DataAccess\DataAccess.csproj : error MSB4057: The target "GetEFProjectMetadata" does not exist in the project.
Unable to retrieve project metadata. Ensure it's an MSBuild-based .NET Core project. If you're using custom BaseIntermediateOutputPath or MSBuildProjectExtensionsPath values, Use the --msbuildprojectextensionspath option.

$(MSBuildProjectExtensionsPath) is pointing to correct obj folder that I configured $(BaseIntermediateOutputPath) to.

That’s correct @raix. That accurately describes the motivation for the pattern. The workflow works very poorly without this pattern.