Project dependency specified in .sln file, causes build to fail, on Unix

[radical]

I have a .sln with:

Projects A, B and C.
A has a ProjectReference to B
B depends on C, specified in the .sln file

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "LibB", "LibB\LibB.csproj", "{34ED4F6B-145E-467E-AFFB-48B3237878D3}"
        ProjectSection(ProjectDependencies) = postProject
                        {9C743F94-9DA8-422B-8FB8-DEB139216381} = {9C743F94-9DA8-422B-8FB8-DEB139216381}
        EndProjectSection
EndProject

Building this with msbuild:

"/Users/ankit/Projects/SlnProjectDepsBug/SlnProjectDepsBug.sln" (default target) (1) ->
"/Users/ankit/Projects/SlnProjectDepsBug/LibB/LibB.csproj.metaproj" (default target) (5) ->
  /Users/ankit/Projects/SlnProjectDepsBug/LibB/LibB.csproj.metaproj : error MSB4025: The project file could not be loaded. Could not find file "/Users/ankit/Projects/SlnProjectDepsBug/LibB/LibB.csproj.metaproj".

From what I able to gather, the SolutionProjectGenerator creates a ProjectInstance for LibB.csproj.metaproj. When RequestBuilder starts to build the .sln.metaproj and wants to build LibB.csproj.metaproj, it doesn't seem to have access to the earlier ProjectInstance and tries to create a new one, which tries to access the file, but since that was just in-memory, it fails.

If you run it with MSBuildEmitSolution=1 then the LibB.csproj.metaproj is written to disk and the build succeeds.

Also, there is a bug due to which if you use MSBUILDEMITSOLUTION=1 (note the case!), the .sln.metaproj.tmp is written to disk before the .csproj.metaproj has been added to it, so you won't see it there. I'll add open a PR for that.

[radical]

This old blog should be relevant: https://blogs.msdn.microsoft.com/msbuild/2010/12/21/incorrect-solution-build-ordering-when-using-msbuild-exe/

[AndyGerlicher]

Team Triage:
Moving this out. @radical you mention this is a regression? Does this behavior work in VS2015 and is broken in VS2017?

[radical]

I was mistaken. It doesn't look like a regression. I will investigate why this is happening on mono/mac though.

[radical]

I'll open a PR for this in a few days. This is the patch that I am using: mono@4a3d1b1

[jasonsturges]

Likewise experiencing this issue on Mac - project solution from Visual Studio 2017, errors when built on VS Code.

Solution excerpt:

# Visual Studio 15
VisualStudioVersion = 15.0.26730.12
MinimumVisualStudioVersion = 10.0.40219.1
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "Archive", "Archive\Archive.csproj", "{08C511A8-3F8F-4182-A9C0-7D15262F73A2}"
	ProjectSection(ProjectDependencies) = postProject
		{5E854290-82A9-443D-83A8-BC85354817FD} = {5E854290-82A9-443D-83A8-BC85354817FD}
	EndProjectSection
EndProject

Generates error on build:

Microsoft (R) Build Engine version 15.3.409.57025 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

/Users/jsturges/Projects/archive-db/Archive/Archive.csproj.metaproj : error MSB4025: The project file could not be loaded. Could not find file '/Users/jsturges/Projects/archive-db/Archive/Archive.csproj.metaproj'.

Build FAILED.

VS Code, Version 1.15.1 (1.15.1) 41abd21
Visual Studio 2017, Version 15.3.3
MS Build: 15.3.409.57025

.Net Core 2.0 project specifying dependency to .Net Standard 2.0 library.

Removing the post project dependency from the .sln file builds without errors.

[bouassaba]

I have the same issue on Linux when the project dependency is specified in the .sln, I get the following error:

error MSB4025: The project file could not be loaded. Could not find file '/home/user/project/project.csproj.metaproj'.

But it works perfectly on Visual Studio 2017 and Visual Studio for Mac.

Removing the dependency in the .sln fixes the issue on Linux.

I'm using .NET Core 2.0 SDK.

[mahald]

while
dotnet publish -c Release -o out
is working on windows i had the same problem on linux. For me it got fixed by passing the csproj file like:
dotnet publish -c Release -o out project.csproj
it still builds the entire solution (maybe as in my case the project in project.csproj depends on all other projects)

[Saibamen]

Same here: https://travis-ci.org/Saibamen/BriskChat/jobs/293200595

[AlexandreOuellet]

My issue is slightly different, but I found a solution that might help you out.

In my Solution.sln, I have 3 csproj :

• A is standalone
• B depends upon A
• C depends upon both B and A

When I do a "dotnet restore", everything is fine, but doing a "dotnet publish ./MySolution.sln -c Release -o ./obj/Docker/publish", it gave me errors about .csproj.metaproj missing. But removing C's dependency on A seems to have fixed the problem.

Not saying this is the best solution (or even feasible in some situation), but I managed to fix it this way on my end.

edit : Just to mention, I'm running on Core 2.0 SDK and Ubuntu 16.04

[AlexandreOuellet]

To add to my previous fix : It worked for some sln, but not all of them (I don't know why it actually worked, maybe simply touching the csproj made a difference?)

Anyway, the fix is actually what @jasonsturges mentionned : the proper solution to remove the postProject part of your .sln file (anything between ProjectSection and EndProjectSection, including those tags)

[sherlock1982]

When deps are not specified in a solution file they're all published with a Debug configuration for some reason. When deps are specified than each and every dep requires framework and rid specified in csproj. So both ways are not working properly

[ms0713]

My .net core 2.0 console application runs properly in Windows OS. But I m having problem running it on RHEL7.

In my .sln file, I have 6-7 projects (.Net Stansard Library 2.0). Some projects depends on some other. But my solution file does not contain any word like postProject.

When I run following command, it gives no error and command prompt comes back without doing anything. Also it gives no error or nothing.
$ dotnet AppName.dll 1
1 is command line argument.

My application uses SQL connection, Reflection, Third Party dlls( developed in c++), socket connection etc.

I also tried running a demo application with command line arguments, SQL connection. It works fine in RHEL7.
My application dll has version like 1.2.3.4.
While Publishing my code, it gives target runtime as Portable. But another sample with target runtime as Portable wotks fine in RHEL7.

What could be the problem? If you have any idea regarding this please share.

[forki]

yes deleting /obj during the build fixed it for me

[ctaggart]

I can confirm that the workaround is to manually edit the .sln file and change the paths to use slashes instead of backslashes. The solution will then correctly restore on Windows and Linux. The changes I just made to make Froto.sln restore on Travis CI:

ctaggart/froto@fb2bf7f

This is a bug. We should have to make this change to make it work on Unix.

[damageboy]

Same here,
I just add the following POS to my build script:

if [ "$(uname)" == "Linux" ]; then
  echo "Unfucking xxx.sln for ${__BuildOS}"
  sed -i 's#\\#/#g' xxx.sln
fi

[enricosada]

Same with .net core sdk 2.1.3

[braunsonm]

Hey @rainersigwald I'm experiencing this issue with dotnet Core, when will your commit be made into a release to resolve the issue?

The suggested sed -i 's#\\#/#g' xxx.sln on linux fixes the build, but the same change on windows will cause the build to fail

[rainersigwald]

@Chaosca It should be in 2.1-preview2; unfortunately it didn't make -preview1.

[halcwb]

This is happening again in my solution first created on mac, then migrated to VS2017. Now when building the solution on macosx again I get the error:

/src/Informedica.GenUtils.Lib/Informedica.GenUtils.Lib.fsproj.metaproj : error MSB4025: The project file could not be loaded. Could not find file 'src/Informedica.GenUtils.Lib/Informedica.GenUtils.Lib.fsproj.metaproj'.

[rainersigwald]

@halcwb Editing the slashes back to / should keep it working cross-plat until VS overwrites them on save. A fixed .NET Core SDK will be released before too long.