VS 2017 RC error: Cannot find project info for... This can indicate a missing project reference

[rpokrovskij]

Steps to reproduce

1. Create ASP.Core project (.NET Framework), then update to latest Nuget packages;
2. Create Class Library 1 (.NET Framework), add Microsoft.EntityFrameworkCore.SqlServer nuget package
3. Create Class Library 2 (.NET Framework), add Microsoft.EntityFrameworkCore.Relational nuget package
4. Compile to test: solution should be possible to compile
5. Create References:
   add project reference "Library 1" to "Library 2"
   add project reference "Library 2" to ASP.Core
6. Compile

Expected behavior

Compiled solution. Or compilation error message that contains useful information.

Actual behavior

Compilation error

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview4-004233)

Product Information:
Version: 1.0.0-preview4-004233
Commit SHA-1 hash: 8cec61c6f7

Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\1.0.0-preview4-004233

Solution:

WebApplication2.zip

[ByronAP]

same issue here with a .net standard class library

[xiexin36]

I have the same problem, anyway can solve it?

[NickCraver]

Also hitting this in my ASP.NET Core samples, unsure of the cause yet.

[NickCraver]

Okay so the issue is that transitive dependencies do not work. If Project A references Project B, then Project A must (at the moment) directly reference the projects referenced in Project B.

For example: if A references B and B references C, to get rid of this error A must reference B and C directly.

[zefeiji]

same issue here.

[BizzyIzDizzy]

Same issue - Is this behaviour intentional?

[TheRealPiotrP]

@dsplaisted I believe this is fixed in most recent SDK. Can you confirm?

[BizzyIzDizzy]

@piotrpMSFT I couldn't reproduce this behaviour with one of the latest builds:

λ dotnet --info
.NET Command Line Tools (1.0.0-rc4-004598)

Product Information:
Version: 1.0.0-rc4-004598
Commit SHA-1 hash: 1dfee9e

Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\1.0.0-rc4-004598

[mgwalm]

The problem still occurs today using VS2017 RC 26020.
However it is not always possible to do as suggested because it could add cycles of references.

[BizzyIzDizzy]

@mgwalm I don't think this is a problem with the latest sdk rc4 but with the visual studio plugin - I have been finding a lot of differences between building from command line using dotnet build and building through visual studio 2017 rc. I believe the plugin is not up to date or VS is doing something "smart".

[mgwalm]

Do MS know this?

[TheRealPiotrP]

@mgwalm can you install the latest VS RC? as @BizzyIzDizzy pointed out, this is not repro'ing in recent CLI builds, including the RC3 build that went out in the latest Visual Studio RC. If you see this atop the latest VS, please let us know!

[lyminhquanoutlookcom]

I have the same problem, but in MacOS with VS for Mac, open solution in VS 2017 in Windows is okay. So boring, I dreamed about one day I can code dotnetcore in my Mac :(

[bkapo]

@piotrpMSFT i have the same problem in MacOS (Visual Studio for Mac Preview - Version Preview 3 (7.0 build 1077)

.NET Command Line Tools (1.0.0-rc3-004530)
Product Information:
Version: 1.0.0-rc3-004530
Commit SHA-1 hash: 0de3338
Runtime Environment:
OS Name: Mac OS X
OS Version: 10.12
OS Platform: Darwin
RID: osx.10.12-x64
Base Path: /usr/local/share/dotnet/sdk/1.0.0-rc3-004530

[TheRealPiotrP]

@bkapo that's a fairly old CLI build. Can you install RC4 from the home page of this repo and, if you're still seeing an issue, can you open a new one? If there is a problem in VS for Mac then the investigation will be fairly independent of this issue.

[mgwalm]

Ive got RC.3+26127.3 and the problem seems to have been resolved.

[TheRealPiotrP]

Thanks @mgwalm. That's what I see as well.

[bkapo]

I have the same problem with RC4.
I am using VS for Mac ...

.NET Command Line Tools (1.0.0-rc4-004767)
Product Information:
Version: 1.0.0-rc4-004767
Commit SHA-1 hash: f7978d9
Runtime Environment:
OS Name: Mac OS X
OS Version: 10.12
OS Platform: Darwin
RID: osx.10.12-x64
Base Path: /usr/local/share/dotnet/sdk/1.0.0-rc4-004767

[TheRealPiotrP]

If there is a problem in VS for Mac then the investigation will be fairly independent of this issue.

[clearbucketLabs]

Same here on a mac (though probably not really related to the os).

How i fixed it was to delete all the obj and bin folders manually and restore the packages with CLI.(restore failed in VS for mac, "object not set to an instance..." but command line was fine). Then rebuilt and it worked. this is on the latest .net core tools, standard library etc... on a multi-project solution.

[ericwj]

I'm on Windows 10. VS 26206.0. I'm getting this from the command line too. dotnet --version 1.0.0-rc4-004771.

I had some success deleting bin and obj too, but remained stuck with non-transitive errors. The CLI and the VS Editor were complaing about identifiers I defined that are right there. Closing and reopening files would help, or reloading the solution. At least until I added another package dependency or a new code file. The depenency tree for the proejct couldn't open level 3 nodes (i.e. show transitive dependencies). I've seen build errors for transitive dependencies too. VS stops building complaining about a "" path. Some MSB3277 about Microsoft.Extensions.DependencyModel. Etc

[ghost]

Same issue here with Windows 10. VS 26206.0. dotnet --version 1.0.0-rc4-004771
Steps to reproduce:

1. Existing Console App 1 (.NET Framework).
2. Create ASP.Core project (.NET Framework)
3. Create References:
   add project reference ASP.Core to Console App 1
4. Install a nuget package for ASP.Core
5. Compile

[StenPetrov]

This issue is marked closed but I'm seeing it with the released VS 2017, how do I fix it?
I tried adding all the references to my .NET Core project still no luck

[CornedBee]

Also had this in a TFS build using Visual Studio solution task set to use VS2017 RTM. Making the transitive project references direct solved it, but seems suboptimal.

[munyirik]

Seeing this problem with released VS 2017 as well.

[livarcocc]

Can you share a repro of this issue? Does restoring/building through the command line work?

[munyirik]

Found out what I was doing wrong. I was thrown off by the error message...

Severity Code Description Project File Line Suppression State
Error Cannot find project info for ... This can indicate a missing project reference...

My problem was that I was targeting net452 in the class library I was referencing in a asp.net core app targeting netcoreapp1.1. I'd expect a 'mismatch' error instead.

[livarcocc]

Please, file an issue for the better error message at dotnet/sdk repo.

[ch-hristov]

I just got this today, is it moved to another issue or?

[rkosafo]

Just had this issue as well. No net452 class library. All apps were .net core only. Trying to reference all transient libraries did not work. Any work around?

[mgSantiago]

I've fixed this problem just setting the project with this issue to the same target framework that the refference project. My main project was on the framework 4.5.2 and the refference project was on 4.6.2. To change the framework of your project just go to: right click on your project >> properties >> Application >> Target Framework

[clearbucketLabs]

@slaters I got the issue with no such mismatch, .net core not 4.x versions. either error message is misleading or it's something else. surprised this shipped with vs 2017... impossible to do serious work when you spend 90% of your project trying to figure out these vague errors for common project setups.

[EliiseS]

I had this problem. Command: donet restore fixed this.

[flipchart]

I had the same error. It was caused by an invalid hint path that VS added with one of the quick actions. Delete the hint path and all good again

[jhudsoncedaron]

1. Running dotnet restore is mandatory or it won't work. VS's "restoring packages" somehow doesn't make it work.
2. The error message is pretty useless. It doesn't even flag the right project but always the last no-link project on the list.

[HelloKitty]

Like @flipchart said, If you guys changed the dependencies' target standard, like from netstandard1.5 to netstandard1.0, you will have to remove the hintpath in the target project's .csproj.

For example <HintPath>..\FreecraftCore.Serializer.Metadata\bin\Debug\netstandard1.5\FreecraftCore.Serializer.Metadata.dll</HintPath>
Hints to netstandard1.5 directory so we need to remove the hint path manually by opening up the .csproj file and removing it.

[jhudsoncedaron]

@HelloKitty : The case I found had zilch-all to do with HintPath; there was no HintPath in the .csproj file.

[atanasa]

I am hitting this with a directly referenced project and no HintPath. I am running VS 2017 (15.2)

Project A is for netstandard1.0
Project B is for netstandard2.0 and net45
Project B references project A

Doing a manual dotnet restore seems to fix it.

[ghost]

@HelloKitty Thanks for the help. I did switch my .NET Core version, and had endless frustration until I read your comment.

[Allann]

I am seeing same error in VSTS builds, works fine in vs2017 15.2 (26430.16). Even if I build the code retrieved directly by the build agent in VS it works fine. Extract from build log below:

2017-07-18T22:19:45.9363559Z _TransformWebConfig:
2017-07-18T22:19:45.9363559Z Updating web.config at 'D:\agent_work\3\s\Dev\Jbssa.MasterData\src\Jbssa.MasterData.Web\obj\Release\netcoreapp1.1\PubTmp\Out\web.config'
2017-07-18T22:19:45.9988579Z ##[error]C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk.Publish\build\netstandard1.0\PublishTargets\Microsoft.NET.Sdk.Publish.MSDeployPackage.targets(124,7): Error MSB4184: The expression "[System.IO.Path]::GetDirectoryName('')" cannot be evaluated. The path is not of a legal form.
2017-07-18T22:19:45.9988579Z ##[debug]Processed: ##vso[task.logissue type=Error;sourcepath=C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk.Publish\build\netstandard1.0\PublishTargets\Microsoft.NET.Sdk.Publish.MSDeployPackage.targets;linenumber=124;columnnumber=7;code=MSB4184;]The expression "[System.IO.Path]::GetDirectoryName('')" cannot be evaluated. The path is not of a legal form.
2017-07-18T22:19:45.9988579Z C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk.Publish\build\netstandard1.0\PublishTargets\Microsoft.NET.Sdk.Publish.MSDeployPackage.targets(124,7): error MSB4184: The expression "[System.IO.Path]::GetDirectoryName('')" cannot be evaluated. The path is not of a legal form. [D:\agent_work\3\s\Dev\Jbssa.MasterData\src\Jbssa.MasterData.Web\Jbssa.MasterData.Web.csproj]
2017-07-18T22:19:45.9988579Z ##[debug]Processed: ##vso[task.logdetail id=684ee0b4-95e9-4006-9e71-2878c4d45827;parentid=bb44fdf5-ab76-4f98-b9c0-ee7786811479;type=Build;result=Failed;finishtime=2017-07-18T22:19:45.9988579Z;progress=100;state=Completed;parentid=bb44fdf5-ab76-4f98-b9c0-ee7786811479;name=;]
2017-07-18T22:19:45.9988579Z Done Building Project "D:\agent_work\3\s\Dev\Jbssa.MasterData\src\Jbssa.MasterData.Web\Jbssa.MasterData.Web.csproj" (default targets) -- FAILED.

This error occurs on both our local build agent and the VSTS Hosted2017 agent.

Further investigation tells me this comes from the ASP.NET Core web application project. When this project was not part of the solution the other projects worked. These include .NetStandard 1.6 and .NetCore 1.1 and xUnit test projects.

I have included the csproj file for the web project:

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

  <PropertyGroup Label="Globals">
    <SccProjectName>SAK</SccProjectName>
    <SccProvider>SAK</SccProvider>
    <SccAuxPath>SAK</SccAuxPath>
    <SccLocalPath>SAK</SccLocalPath>
  </PropertyGroup>

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

  <PropertyGroup>
    <PackageTargetFallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</PackageTargetFallback>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore" Version="1.1.2" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.3" />
    <PackageReference Include="Microsoft.AspNetCore.Session" Version="1.1.2" />
    <PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="1.1.2" />
    <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="1.1.2" />
    <PackageReference Include="Microsoft.VisualStudio.Web.BrowserLink" Version="1.1.2" />
    <PackageReference Include="Telerik.UI.for.AspNet.Core" Version="2017.2.621" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.1" />
  </ItemGroup>
  <ItemGroup>
    <ProjectReference Include="..\Jbssa.MasterData.BusinessLogic\Jbssa.MasterData.BusinessLogic.csproj" />
    <ProjectReference Include="..\Jbssa.MasterData.Security\Jbssa.MasterData.Security.csproj" />
  </ItemGroup>

</Project>

Not sure if it has anything to do with the Telerik package which needs a service endpoint created.

[sturlath]

This answer on StackOverflow got me to just update all my projects from .net 4.5.2 to .net 4.6.1 and now this error is gone. Hope this info helps somebody.

[Allann]

This appears to be a "generic error" that they spit out. It turned out to be an error in the default values the msbuild task added in the build definition. I changed the MSBuild Arguments to this:

/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactstagingdirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"

and all was good again. I don't think adding a new target framework is a good idea in many circumstances. Your applications should be targeting specific frameworks for a reason I assume.

[se7vanj]

On a similar problem with my machine, I had to reset the below file which was accidentally modified when I was trying to make my assemblies to be on net45 and core api targetting to net45. After that it was not building my solution and started to throw different errors, even after I reverted back everything to target with .net core. Tried deleting VS related cache/settings folders of my local user login, no result, then I was about to uninstall VS2017, before that found the below file had a modified timestamp and somehow got its original content. Now its fine to build and run my original solution which is targetting to .net core.

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets

[WolfyUK]

For me, this was a case sensitivity issue. The folder containing the dependent project had been renamed and the consuming project file updated, but the solution file had not. Making sure all paths match correctly in .sln, .csproj and physically on disk resolved the Cannot find project info issue.

[MovGP0]

I had to delete the .FileListAbsolute.txt and nuget.g.targets files to make the build work for me:

Get-ChildItem . -Recurse -Force | where { $_.Name -match ".*FileListAbsolute.txt" } | Remove-Item
Get-ChildItem . -Recurse -Force | where { $_.Name -match ".*nuget.g.targets" } | Remove-Item

[MumenTayyem]

I restarted VS and it worked fine.

[sysaxis]

Open /obj/project.assets and remove the project from the targets. Worked for me. For some reason the project.assets contains even the referenced projects from excluded files.

[Citizen39]

Thank you @WolfyUK ! Same scenario for me, and your tip resolved my similar issue. Cheers!

[michaelthyregod]

I can confirm that it seems to be the casing of the path that needs to be exactly as it is in the filesystem. This goes for the Include in in *.csproj files and for any project path reference in the sln file.
Might be a good idea to implement a proper comparer for comparing the path, and not rely on casing.

[sivakspt]

I have unloaded the project and reloaded the project it work from me.

[mikebridge]

Deleting obj and bin and restoring worked for me as per @clearbucketLabs.

[vtkhanh]

dotnet restore works for me. oops...

[GHR-Arash]

@NickCraver

Okay so the issue is that transitive dependencies do not work. If Project A references Project B, then Project A must (at the moment) directly reference the projects referenced in Project B.

For example: if A references B and B references C, to get rid of this error A must reference B and C directly.

This is Not Correct Behavior , so what if then Project C reference project D and Project D Reference Project E and ....
should i add dependency graph manually ?

[Rui90]

So my problem was the following:

I had a project A that I've tried to add to a Project B. The problem was that everytime I added the reference I blow up the solution just like you say in the title. After banging a lot with my head I found out that the assembly name of the project A had the name of a project C which was already referenced in project B. So everytime I tried to add the reference and build, basically he wouldn't find the project a reference because it already existed associated with other reference.

So basically, I changed the name of the assembly name of the project A to the name of the project A.