_From @colinbowern on June 25, 2017 20:45_
Class library compiles
Failed with error MSB4025: The project file could not be loaded. Could not find file '/mnt/c/Users/colinb/Projects/TestProject/src/Library/Library.fsproj.metaproj
No tooling along the way creates a metaproj file. This file does not exist.
dotnet --info output:
.NET Command Line Tools (1.0.4)
Product Information:
Version: 1.0.4
Commit SHA-1 hash: af1e6684fdRuntime Environment:
OS Name: ubuntu
OS Version: 16.04
OS Platform: Linux
RID: ubuntu.16.04-x64
Base Path: /usr/share/dotnet/sdk/1.0.4
_Copied from original issue: dotnet/cli#7000_
_From @dmbarbour on June 29, 2017 16:16_
I'm seeing the same problem with any attempt to create a solution. Steps to reproduce:
mkdir tmp; cd tmp
mkdir A; cd A; dotnet new classlib -lang f#; cd ..
dotnet new sln
dotnet sln add A/A.fsproj
dotnet build
Error at this point is: /tmp/A/A.fsproj.metaproj : error MSB4025: The project file could not be loaded. Could not find file '/tmp/A/A.fsproj.metaproj'. Same dotnet version as @colinbowern, above.
Note: this issue does not appear with C# projects, only for the F# projects. Further, the dotnet restore from the toplevel solution seems to ignore all the F# projects and only restores C# projects.
_From @dmbarbour on June 29, 2017 23:29_
I have a workaround: I'm just using a toplevel project instead of a toplevel solution.
_From @livarcocc on July 10, 2017 21:23_
@rainersigwald Is this something else that msbuild needs to address? Why would it fail to generate the metaproj for a solution with fsprojs? Are we setting the wrong project type, maybe?
EDIT: Ignore this! Info is superseded.
@colinbowern I can't reproduce this with your instructions. I ran into #2022, but after applying the workaround for that I can successfully build the solution.
@dmbarbour's repro does error for me though.
Don't use the .sln to build; instead build at your "overall" project or use a top-level "traversal" project that points to your projects (as mentioned https://github.com/Microsoft/msbuild/issues/2275#issuecomment-314252491).
Set the environment variable MSBuildEmitSolution=1. This causes MSBuild to emit the files to disk (for debugging), but then they exist and can be found. I don't recommend checking them in.
Example, after applying the workaround for #2022.
$ MSBuildEmitSolution=1 dotnet build tmp.sln
Microsoft (R) Build Engine version 15.1.1012.6693
Copyright (C) Microsoft Corporation. All rights reserved.
A -> /mnt/s/work/fs/tmp/A/bin/Debug/netstandard1.6/A.dll
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:10.29
Sorry, that was bad analysis!
I'm not sure I can reproduce this issue. I see a different error (warning MSB4046) when following @dmbarbour's repro steps.
My issue is a (bizarre!) manifestation of #2022. After changing relative-path slash directions in the .sln file, I can build successfully.
The problem isn't that the .metaproj doesn't exist (it does, in memory); it's that its contents only emit the error:
<Target Name="Build" Condition="'$(CurrentSolutionConfigurationContents)' != ''">
<Warning Text="Error reading project file "A\A.fsproj": Could not find file %27/mnt/s/work/fs/temp/A\A.fsproj%27." Code="MSB4046" HelpKeyword="MSBuild.SolutionParseErrorReadingProject" />
</Target>
<Target Name="Clean" Condition="'$(CurrentSolutionConfigurationContents)' != ''">
<Warning Text="Error reading project file "A\A.fsproj": Could not find file %27/mnt/s/work/fs/temp/A\A.fsproj%27." Code="MSB4046" HelpKeyword="MSBuild.SolutionParseErrorReadingProject" />
</Target>
<Target Name="Rebuild" Condition="'$(CurrentSolutionConfigurationContents)' != ''">
<Warning Text="Error reading project file "A\A.fsproj": Could not find file %27/mnt/s/work/fs/temp/A\A.fsproj%27." Code="MSB4046" HelpKeyword="MSBuild.SolutionParseErrorReadingProject" />
</Target>
<Target Name="Publish" Condition="'$(CurrentSolutionConfigurationContents)' != ''">
<Warning Text="Error reading project file "A\A.fsproj": Could not find file %27/mnt/s/work/fs/temp/A\A.fsproj%27." Code="MSB4046" HelpKeyword="MSBuild.SolutionParseErrorReadingProject" />
</Target>
That's what the solution-parser does when it can't open the project.
I also don't seem to be able to reproduce the MSB4025 using a .NET Core SDK 2.0.0-preview build on macOS.
If you see this (@colinbowern especially), I'd like to know more about how your project is set up. A zip file might also be useful.
Closing due to lack of response. If you see this and can give more details about your code, please comment and we can reopen.
I was also having this problem when I noticed that when the project was added to the solution file it got added as hello\hello.fsproj instead of hello/hello.fsproj.
After manually changing this I was able to build from the sln.
@rainersigwald I'm also getting this error on Ubuntu on dotnet build. dotnet restore works fine:
error MSB4025: The project file could not be loaded. Could not find file '*.fsproj.metaproj'
However, it is not consistent. I managed to get it working on one repo by recreating the .sln file using SDK2. However, trying to fix another repo the same way did not help. Manually switching from to / in the project path fixes it. But don't know if it will work on Windows anymore now.
So, for one solution in paths is ok, but for another it's not.
dotnet --info
.NET Command Line Tools (2.0.0)
Product Information:
Version: 2.0.0
Commit SHA-1 hash: cdcd1928c9Runtime Environment:
OS Name: ubuntu
OS Version: 16.04
OS Platform: Linux
RID: ubuntu.16.04-x64
Base Path: /usr/share/dotnet/sdk/2.0.0/Microsoft .NET Core Shared Framework Host
Version : 2.0.0
Build : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d
Hmm...something strange just happened. I tried to recreate the .sln file a second time using SDK2 and deleting the obj/ and bin/ folders in the project folder and then doing dotnet restore and dotnet build and now it works. I don't know why recreating the .sln file did not help the first time.
I had a similar problem with Ubuntu 17.
rm -r -f obj
rm -r -f bin
sudo dotnet restore
sudo dotnet build
Works...
One possible reason could be that if you run dotnet restore without sudo it will fail silently on restore, not writing all the files but thinking that the restore was ok, and then when you try to build, there are not everything correct.
yes deleting /obj during the build fixed it for me
I have the same issue when I add a NodeJS project in my solution.
Here is the build result
`[Stage_BlablaSolution] Running shell script
/var/lib/jenkins/workspace/Stage_BlablaSolution/Tascona.Lib/Tascona.Lib.Utils/Tascona.Lib.Utils.csproj : warning NU1603: NEST 5.5.0 depends on Newtonsoft.Json (>= 10.0.0 && < 11.0.0) but Newtonsoft.Json 10.0.0 was not found. An approximate best match of Newtonsoft.Json 10.0.1 was resolved.
/var/lib/jenkins/workspace/Stage_BlablaSolution/ThirdFlemingo.Net/ThirdFlemingo.UnitTest/ThirdFlemingo.UnitTest.csproj : warning NU1603: NEST 5.5.0 depends on Newtonsoft.Json (>= 10.0.0 && < 11.0.0) but Newtonsoft.Json 10.0.0 was not found. An approximate best match of Newtonsoft.Json 10.0.1 was resolved.
/var/lib/jenkins/workspace/Stage_BlablaSolution/ThirdFlemingo.Net/ThirdFlemingo.Net/ThirdFlemingo.Net.csproj : warning NU1603: NEST 5.5.0 depends on Newtonsoft.Json (>= 10.0.0 && < 11.0.0) but Newtonsoft.Json 10.0.0 was not found. An approximate best match of Newtonsoft.Json 10.0.1 was resolved.
/var/lib/jenkins/workspace/Stage_BlablaSolution/Tascona.Lib/Tascona.Lib.Data.Repo/Tascona.Lib.Data.Repo.csproj : warning NU1603: NEST 5.5.0 depends on Newtonsoft.Json (>= 10.0.0 && < 11.0.0) but Newtonsoft.Json 10.0.0 was not found. An approximate best match of Newtonsoft.Json 10.0.1 was resolved.
/var/lib/jenkins/workspace/Stage_BlablaSolution/Tascona.Lib/Tascona.Lib.Business/Tascona.Lib.Business.csproj : warning NU1603: NEST 5.5.0 depends on Newtonsoft.Json (>= 10.0.0 && < 11.0.0) but Newtonsoft.Json 10.0.0 was not found. An approximate best match of Newtonsoft.Json 10.0.1 was resolved.
/var/lib/jenkins/workspace/Stage_BlablaSolution/Tascona.Lib/Tascona.Lib.Data.DAL/Tascona.Lib.Data.DAL.csproj : warning NU1603: NEST 5.5.0 depends on Newtonsoft.Json (>= 10.0.0 && < 11.0.0) but Newtonsoft.Json 10.0.0 was not found. An approximate best match of Newtonsoft.Json 10.0.1 was resolved.
/var/lib/jenkins/workspace/Stage_BlablaSolution/Tascona.App.Presentation/Tascona.Presentation.Web/Tascona.Presentation.Web.csproj : warning NU1603: NEST 5.5.0 depends on Newtonsoft.Json (>= 10.0.0 && < 11.0.0) but Newtonsoft.Json 10.0.0 was not found. An approximate best match of Newtonsoft.Json 10.0.1 was resolved.
/var/lib/jenkins/workspace/Stage_BlablaSolution/NodejsConsoleApp1/NodejsConsoleApp1.njsproj.metaproj : error MSB4025: The project file could not be loaded. Could not find file '/var/lib/jenkins/workspace/Stage_BlablaSolution/NodejsConsoleApp1/NodejsConsoleApp1.njsproj.metaproj'.`
And here is the dotnet --info
.NET Command Line Tools (2.1.3)
Product Information:
Version: 2.1.3
Commit SHA-1 hash: a0ca411ca5
Runtime Environment:
OS Name: ubuntu
OS Version: 16.04
OS Platform: Linux
RID: ubuntu.16.04-x64
Base Path: /usr/share/dotnet/sdk/2.1.3/
Microsoft .NET Core Shared Framework Host
Version : 2.0.4
Build : 7f262f453d8c8479b9af91d34c013b3aa05bc1ff
I can reproduce this by attempting to dotnet publish a multi-project solution using WSL.
I just ran into this and can confirm that switching .sln project references from \ to / fixed it. How bizarre.
Here is my Travis build before: https://travis-ci.org/hedgehogqa/fsharp-hedgehog/builds/338361850
Here it is after: https://travis-ci.org/hedgehogqa/fsharp-hedgehog/builds/338379628
As above, switched \ to / in my .sln solved this.
But when you switch from to / in the .sln file things like SonarQube wont work.
SonarQube.Scanner.MSBuild.exe
Switch from \ to / in the .sln solved for me, but i try another way and removed ProjectDependencies from .sln file for projects. You can find like this in your .sln file:
ProjectSection(ProjectDependencies) = postProject
after this .sln file successfull build with both variant of paths on unix and windows _(i think, what \ is more correct variant)_.
Upgraded on MacOS from 2.0.x to 2.1.4 and me too. Workaround with changing slash direction works though.
Ran into the same issue, C# projects only though. Also no ProjectDependencies section in my .sln. Changing all backslashes to forward slashes in project paths resolved the six errors if the form
error MSB3202: The project file "/path/to/project.csproj.metaproj" was not found.
when trying to dotnet build or dotnet test my solution with a total of 28 projects. Never had any issues with dotnet restore as well. Working on macOS with dotnet version 2.1.103.
@takerukoushirou Slash-direction problems should be fixed with #2963 which should be available in the .NET Core SDK versions 2.1.200 and 2.1.300, which have previews available.
@rainersigwald
I now run 2.1.4 but the same problem here. Created a dotnetcore solution using the command line sdk. Edited the solution with VS2017. Tried to build it on macosx -> errors ;-)
/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'.
@halcwb What msbuild version are you using? dotnet msbuild -version. As I mention above, this is fixed in the .NET Core SDK 2.1.200 and 2.1.300, neither of which has hit final release yet.
Most helpful comment
I was also having this problem when I noticed that when the project was added to the solution file it got added as
hello\hello.fsprojinstead ofhello/hello.fsproj.After manually changing this I was able to build from the sln.