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 throws: Unable to retrieve project metadata. #9127

Closed
julielerman opened this issue Jul 8, 2017 · 10 comments
Closed

CLI throws: Unable to retrieve project metadata. #9127

julielerman opened this issue Jul 8, 2017 · 10 comments
Assignees
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-bug
Milestone

Comments

@julielerman
Copy link

This just popped up when I migrated a project on preview2-final to rtm-26180.
dotnet --info

Version:            2.0.0-preview3-006694
OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /usr/local/share/dotnet/sdk/2.0.0-preview3-006694/
Microsoft .NET Core Shared Framework Host
  Version  : 2.0.0-preview3-25507-02
  Build    : cb31faee171130d052245748e11e96b27fd8d00c

dotnet ef runs, but dotnet ef migrations/dbcontext/database all throw this error:

/Users/julialerman/Dropbox/ConferenceStuff/DevTeach/2017/Share/EFCore2Previe
wWebApi/App.WebApi/obj/App.WebApi.csproj.EntityFrameworkCore.targets(20,5):
error MSB3491: Could not write lines to file "/var/folders/8w/97pyy4fd71l1gs
9hl6k4qgmc0000gn/T/ydymgqln.wey". The process cannot access the file '/var/f
olders/8w/97pyy4fd71l1gs9hl6k4qgmc0000gn/T/ydymgqln.wey' because it is being
 used by another process. [/Users/julialerman/Dropbox/ConferenceStuff/DevTea
ch/2017/Share/EFCore2PreviewWebApi/App.WebApi/App.WebApi.csproj]
Unable to retrieve project metadata. Ensure it's an MSBuild-based .NET Core
project. If you're using custom BaseIntermediateOutputPath or MSBuildProject
ExtensionsPath values, Use the --msbuildprojectextensionspath option.

I do not have any custom msbuild values that I know of.
I removed bin & obj folders, restored & rebuilt but still get this error.

I am also able to reproduce it on this solution: https://github.com/julielerman/OwnedEntityStoreToDbProblem

@julielerman
Copy link
Author

julielerman commented Jul 8, 2017

More data for you:
while staying on the same version of the SDK, I reverted EF Core to preview3-* and had the same problem. Then to preview2-* and the CLI tools worked as expected.
Here is the csproj file (after I downgraded to preview2):

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <UserSecretsId>aspnet-App.WebApi-7913C0F3-3B1F-4506-9C1E-9F5ECE9BABFD</UserSecretsId>
  </PropertyGroup>
  <ItemGroup>
    <Folder Include="wwwroot\" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore" Version="2.0.0-preview2-*" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.0.0-preview2-*" />
     <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.0.0-preview2-*" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="2.0.0-preview2-*" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.0-preview2-*" />
  </ItemGroup>
  
</Project>

@julielerman
Copy link
Author

julielerman commented Jul 10, 2017

Couldn't help myself and did some more experimentation. Checking project.assets.json, i noticed that I didn't always have the version of EFCore packages that I thought I was getting when fiddling with preview3 version numbers in csproj. This may have been the difference between poiting to aspnet-dev and aspnet-dev-cli. So setting the packagereferences all to rtm-* makes no difference. It's the Tools package that seems to be creating the problem. Anything higher than preview3-* causes the problem. I started explicitly with the first version of the rtm packages: 2.0.0-rtm-26151 and it's failing there.

@smitpatel
Copy link
Member

Investigating this. I hit the issue with rtm-16182.
preview3 worked fine (gave error on DiagnosticSource though)

@bricelam
Copy link
Contributor

bricelam commented Jul 10, 2017

#8963 (Remove GetTempFileName) may have regressed this.

cc @jbagga @Eilon @ajcvickers

@smitpatel
Copy link
Member

It is indeed culprit. I checked out packages before that commit went in (from aspnetci since the myget feed does not have packages).
It works when we generated .tmp files. It fails with above error when we started generating using tempfilename api.

@bricelam
Copy link
Contributor

Bummer. Let's revert it.

@smitpatel smitpatel self-assigned this Jul 10, 2017
@smitpatel
Copy link
Member

Fixed via #9131
I manually verified with locally built package that it works now.

@smitpatel smitpatel added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Jul 10, 2017
@smitpatel smitpatel added this to the 2.0.0 milestone Jul 10, 2017
@Eilon
Copy link
Member

Eilon commented Jul 18, 2017

What was the actual cause of this? That is, why did changing the temp file break?

@ajcvickers
Copy link
Member

@smitpatel @bricelam I think it's clear that the change caused the regression, but I don't know why. 🐑 Can one of you explain to us mere managers. 😉

@smitpatel
Copy link
Member

Perhaps...
From https://msdn.microsoft.com/en-us/library/d62kzs03(v=vs.110).aspx
File.Create(string) method Remarks

The FileStream object created by this method has a default FileShare value of None; no other process or code can access the created file until the original file handle is closed.

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. type-bug
Projects
None yet
Development

No branches or pull requests

5 participants