Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLI Tools: Error when MSBuildProjectExtensionsPath doesn't exist #8816

Closed
karabaja4 opened this issue Jun 11, 2017 · 6 comments
Closed

CLI Tools: Error when MSBuildProjectExtensionsPath doesn't exist #8816

karabaja4 opened this issue Jun 11, 2017 · 6 comments
Assignees
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. good first issue This issue should be relatively straightforward to fix. help wanted This issue involves technologies where we are not experts. Expert help would be appreciated. type-bug
Milestone

Comments

@karabaja4
Copy link

karabaja4 commented Jun 11, 2017

Hello, I have trouble scaffolding an existing Sqlite database model when a separate netstandard1.6 class library is used as a DataLayer project and BaseIntermediateOutputPath is set to a different obj/ folder with --msbuildprojectextensionspath, as per example below:


Directory structure:

out/
  project.DataLayer/
    bin/
    obj/
  project.WebApp/
    bin/
    obj/
src/
  project.DataLayer/
    project.DataLayer.csproj
  project.WebApp/
    project.WebApp.csproj

projects.DataLayer.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>

    <TargetFramework>netstandard1.6</TargetFramework>

    <BaseOutputPath>../../out/$(AssemblyName)/bin</BaseOutputPath>
    <BaseIntermediateOutputPath>../../out/$(AssemblyName)/obj</BaseIntermediateOutputPath>

  </PropertyGroup>

  <ItemGroup>

    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="1.1.2" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="1.1.2" />
    
    <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="1.1.1" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite.Design" Version="1.1.2" />
    <DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.1" />
    
  </ItemGroup>

</Project>

project.WebApp.csproj

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
  
    <TargetFramework>netcoreapp1.1</TargetFramework>

    <BaseOutputPath>../../out/$(AssemblyName)/bin</BaseOutputPath>
    <BaseIntermediateOutputPath>../../out/$(AssemblyName)/obj</BaseIntermediateOutputPath>

  </PropertyGroup>

  <ItemGroup>
        *snip, irrelevant packages*
       <ProjectReference Include="..\project.Business\project.Business.csproj" /> // has reference to project.DataLayer
  </ItemGroup>

</Project>

For the below commands I am positioned in project.DataLayer folder and I ran dotnet restore and dotnet build on all projects.

When I try to scaffold the database from /src/project.DataLayer with --msbuildprojectextensionspath pointing to /out/project.DataLayer/obj/:

dotnet ef dbcontext scaffold "Datasource=database.db" Microsoft.EntityFrameworkCore.Sqlite --context "AppDbContext" --data-annotations --force --msbuildprojectextensionspath "C:\projects\out\project.DataLayer\obj" --project "C:\projects\src\project.DataLayer\project.DataLayer.csproj" --output-dir "C:\projects\src\project.DataLayer\Models\" --startup-project "C:\projects\src\project.WebApp\project.WebApp.csproj"

C:\projects\src\project.DataLayer\project.DataLayer.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.

I get this error, but, if I remove BaseOutputPath and BaseIntermediateOutputPath from both csprojs (then the bin/ and obj/ folders are created in the /src/project.DataLayer folder after dotnet restore and dotnet build) and execute the following command from that folder:

dotnet ef dbcontext scaffold "Datasource=database.db" Microsoft.EntityFrameworkCore.Sqlite --context "AppDbContext" --data-annotations --force --output-dir  "C:\projects\src\project.DataLayer\Models" --startup-project "C:\projects\src\project.WebApp\project.WebApp.csproj"

Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:12.48

then the command is executed successfully and the model is created.

Please note that Scaffold-DbContext works in VS2017 Package Manager Console when I pick project.DataLayer and execute scaffolding with the same configuration (/bin and /obj in separate directory).

EF Core version: 1.1.2
Database Provider: Microsoft.EntityFrameworkCore.Sqlite
Operating system: Windows 10
IDE: Visual Studio Code / CLI Tools

@bricelam
Copy link
Contributor

bricelam commented Jun 19, 2017

Hmm, there's definitely an issue here. To get it to work as it was intended, you'd have to author your *.csproj like this:

<Project>
  <PropertyGroup>
    <BaseIntermediateOutputPath>../../obj/$(MSBuildProjectName)/</BaseIntermediateOutputPath>
  </PropertyGroup>
  <Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" />

  <!-- Typical content goes here. -->

  <Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" />
</Project>

For your scenario, not specifying --msbuildprojectextensionspath seems to work. Although you may have to manually create the obj\ folder so you don't get a could not find a part of the path error.

@bricelam
Copy link
Contributor

Triage, I think we have two options here:

  1. Keep everything as is, but create the directory if it doesn't exist.
  2. Flow MSBuildProjectExtensionsPath into MSBuild so it can be set before it's defaulted to the value of BaseIntermediateOutputPath.

@bricelam bricelam removed this from the 2.0.0 milestone Jun 19, 2017
@karabaja4
Copy link
Author

karabaja4 commented Jun 19, 2017

Yeah, I succeeded to scaffold it by manually creating obj/ folder in projects roots and not specifying --msbuildprojectextensionpath. Unfortunately this defeats the purpose of having a separate obj/ folder if another one now exists in the project root.

I tried to modify the csprojs as you suggested. However I was still unsuccessful in using --msbuildprojectextensionpath. First, I ran the restore and build on modified csprojs. This caused a bunch of warnings:

C:\projects\src\project.DataLayer.csproj(10,3): warning MSB4011: "C:\Program Files\dotnet\sdk\1.0.4\Sdks\Microsoft.NET.Sdk\Sdk\Sdk.props" cannot be imported again. It was already imported at "C:\projects\src\project.DataLayer\project.DataLayer.csproj". This is most likely a build authoring error. This subsequent import will be ignored.

This also created the folder as specified in the csproj: ../../obj/project.DataLayer.

I pointed --msbuildprojectextensionpath to ../../obj/. I still got:

C:\projects\src\project.DataLayer\project.DataLayer.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.

Did I misconfigure something? Thanks.

@bricelam
Copy link
Contributor

It sounds like you left the Sdk attribute on the root Project element.

@karabaja4
Copy link
Author

Yeah, sorry. Tinkering with csprojs at 3AM wasn't a good idea. The error remains however, except no warnings this time.

Since I spent way too much time playing with this I'll just leave bin/ and obj/ inside root for now. Thanks for your help.

@ajcvickers ajcvickers added this to the 2.0.0 milestone Jun 21, 2017
@bricelam
Copy link
Contributor

bricelam commented Jun 23, 2017

We decided to go with option 1: Keep everything as is, but create the directory if it doesn't exist.

That fact that dotnet/sdk (or maybe it's Microsoft/msbuild) makes it difficult to override the value of BaseIntermediateOutputPath before it is used as the default value of MSBuildProjectExtensionsPath shouldn't be addressed by a feature in EF. I believe dotnet restore would also continue putting things under obj/ with the project as it was.

@bricelam bricelam changed the title --msbuildprojectextensionspath does not work as expected CLI Tools: MSBuildProjectxtensionspath does not work as expected Jun 28, 2017
@bricelam bricelam changed the title CLI Tools: MSBuildProjectxtensionspath does not work as expected CLI Tools: Error when MSBuildProjectExtensionsPath doesn't exist Jun 28, 2017
@bricelam bricelam added the help wanted This issue involves technologies where we are not experts. Expert help would be appreciated. label Jun 30, 2017
@bricelam bricelam added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Jul 7, 2017
@bricelam bricelam added good first issue This issue should be relatively straightforward to fix. and removed good first issue This issue should be relatively straightforward to fix. labels May 31, 2019
jaredpar added a commit to jaredpar/runfo that referenced this issue Apr 16, 2020
This causes issues with Entity Framework Core's ability to create
migration projects. It is fairly hard coded to look into the obj
directory. Trying to make it work with the global Binaries directory was
just swimming upstream. Decided to simplify a bit since I'm already
paying the learner tax on EF. No reason to add more by fighting the
system.

Further reading
- dotnet/efcore#8816
jaredpar added a commit to jaredpar/runfo that referenced this issue Apr 19, 2020
This causes issues with Entity Framework Core's ability to create
migration projects. It is fairly hard coded to look into the obj
directory. Trying to make it work with the global Binaries directory was
just swimming upstream. Decided to simplify a bit since I'm already
paying the learner tax on EF. No reason to add more by fighting the
system.

Further reading
- dotnet/efcore#8816
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. good first issue This issue should be relatively straightforward to fix. help wanted This issue involves technologies where we are not experts. Expert help would be appreciated. type-bug
Projects
None yet
Development

No branches or pull requests

3 participants