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

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.

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 5
Comments: 20 (6 by maintainers)

Commits related to this issue

Handle unix slashes in project file paths in a .sln file Given 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... — committed to mono/msbuild by deleted user 7 years ago
workaround for restore sln on unix ref https://github.com/Microsoft/msbuild/issues/1957 — committed to enricosada/Paket by enricosada 6 years ago
workaround for restore sln on unix ref https://github.com/Microsoft/msbuild/issues/1957 — committed to enricosada/Paket by enricosada 6 years ago
Workaround https://github.com/Microsoft/msbuild/issues/1957 — committed to fsprojects/FAKE by matthid 6 years ago
Convert solution relative paths to OS slashes Fixes #2022, fixes #1957. Ported the code change only from https://github.com/mono/msbuild/commit/86adc961fedefef300b6273b22611410ac87270b. — committed to rainersigwald/msbuild by rainersigwald 6 years ago
Convert solution relative paths to OS slashes Fixes #2022, fixes #1957. Ported the code change only from https://github.com/mono/msbuild/commit/86adc961fedefef300b6273b22611410ac87270b. — committed to rainersigwald/msbuild by rainersigwald 6 years ago
Workaround for failing build according to Microsoft/msbuild#1957 — committed to MonacsLib/Monacs by bartsokol 6 years ago

Most upvoted comments

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

damageboy on Dec 27, 2017

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:

https://github.com/ctaggart/froto/commit/fb2bf7f3e8e39fd5ccf096b14a0620d59647933f

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

ctaggart on Dec 25, 2017

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)

mahald on Oct 25, 2017

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 ® Build Engine version 15.3.409.57025 for .NET Core Copyright © 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.

jasonsturges on Sep 1, 2017

@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.

rainersigwald on Apr 27, 2018

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

braunsonm on Mar 1, 2018

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.

eliasby on Sep 17, 2017

I’ll open a PR for this in a few days. This is the patch that I am using: https://github.com/mono/msbuild/commit/4a3d1b1da80606c7b2e3c602cb23f10ec7865921

radical on May 2, 2017