Repository navigation
[Mono] Error parsing solution file ... invalid image with Mono 5.14.0.177, msbuild 15.0 in Travis CI #7202
Description
From @denfromufa on August 14, 2018 3:47
This is from gitter chat in Mono: https://gitter.im/mono/mono
Any idea why we are getting "invalid image" error from VS solution file under certain conditions? Seems to be working under .NET Core and .NET Framework, but not Mono.
https://travis-ci.org/pythonnet/pythonnet/jobs/415741698#L1874
Currently running NuGet.exe 4.1.0. Updating NuGet.exe to 4.7.1. Update successful. MSBuild auto-detection: using msbuild version '15.0' from '/usr/lib/mono/msbuild/15.0/bin'. Error parsing solution file at /home/travis/build/pythonnet/pythonnet/pythonnet.sln: Invalid Image
Katelyn Gadd @kg 22:36
invalid image parsing sln makes it sound like it's having trouble loading msbuild assemblies
dotnet/msbuild#3282 this is the same error message
rather, the first part is the same. different exception
so it is indeed caused by a managed exception
rainersigwald/msbuild@7960c80#diff-af08e5d2c5235a664572f4581ba0e7c6R161 it looks like msbuild has had mono compatibility issues before
Denis Akhiyarov @denfromufa 22:41
@kg thanks for diagnostics, any easy workaround the get the CI builds going? I don't recall these errors last week for the same build configuration:
https://travis-ci.org/pythonnet/pythonnet/builds/413267958
Katelyn Gadd @kg 22:42
i'm sorry, i don't know enough to recommend a solution right now. you might want to ping @rainersigwald to see if he has any ideas
or you could file an issue since it's an exception in msbuild to see if they can suggest a fix. i think that error message is insufficient
so it is a useful defect report in the sense of 'we should at least improve this error message'
it looks like it only outputs exc.Message which is insufficient in this case
Copied from original issue: dotnet/msbuild#3604
Activity
rainersigwald commented on Aug 14, 2018
That error is actually thrown from NuGet here: https://github.com/NuGet/NuGet.Client/blob/203c517a85791243f53ea08d404ee5b8fae36e35/src/NuGet.Clients/NuGet.CommandLine/MsBuildUtility.cs#L378-L414
I'll move this to the NuGet repo. When we collect more information about what's actually going wrong, we may need to reactivate this bug and fix the underlying MSBuild problem, but the diagnosability problem is in NuGet.
den-run-ai commented on Aug 23, 2018
@rainersigwald @zhili1208 I tried to reproduce this issue locally in Virtualbox with no luck, hence opened a question on stackoverflow:
https://stackoverflow.com/questions/51988395/build-failures-with-mono-5-14-0-177-msbuild-15-0-nuget-4-7-1-on-travis-ci-not
den-run-ai commented on Aug 23, 2018
I may try to run this through travis ci docker image
den-run-ai commented on Oct 21, 2018
This issue has been fixed in pythonnet Travis CI temporarily by downgrading to msbuild 14.0:
https://github.com/pythonnet/pythonnet/blob/master/setup.py#L332
knocte commented on Jun 12, 2019
It's easy to reproduce this with the latest version of NuGet (5.0.2.5988) if you use the versions of mono (5.18.0.240) and xbuild (14.0) bundled by Ubuntu 19.04.
knocte commented on Jun 12, 2019
I tried this workaround (adding -MSBuildVersion 14 to the nuget restore call), and then I get this other problem:
kg commented on Jun 12, 2019
@knocte I'd be happy to help look into this in case it's a mono problem but from rereading the issue thread I do not understand what the actual problem is and how to reproduce it.
scripts: improve support for Ubuntu 19.04
scripts: improve support for Ubuntu 19.04
knocte commented on Jun 13, 2019
Thanks for your offer!
Well, after digging a bit, I think it's actually a NuGet bug to detect xbuild properly, more info to follow...
Fair enough, I'll try to clarify things and help you reproduce it.
The simple steps to reproduce should be:
Expected results: should restore packages listed in the packages.config file of each project
Current results:
Things to note: I used -Verbosity detailed so that we could get the stacktrace. And from this stacktrace we can gather the fact that @rainersigwald was not accurate when he thought that the problem lies in MsBuildUtility::GetAllProjectFileNamesWithXBuild method, because the method where it explodes is actually GetAllProjectFileNamesWithMsBuild. In fact I tested the method GetAllProjectFileNamesWithXBuild myself by compiling a simple program that does the same thing, and getting the project paths of a solution works fine using this version of ubuntu with this version of mono, so this is not the issue. The issue seems to be that NuGet ends up calling GetAllProjectFileNamesWithMsBuild when it should have called GetAllProjectFileNamesWithXBuild. How is this determined? By two factors:
https://github.com/NuGet/NuGet.Client/blob/203c517a85791243f53ea08d404ee5b8fae36e35/src/NuGet.Clients/NuGet.CommandLine/MsBuildUtility.cs#L452
I'm guessing that the check RuntimeEnvironmentHelper.IsMono works fine (I tested its implementation myself, separately, too), and the one failing is msbuildPath.Contains("xbuild"). To prove my theory I would need to compile NuGet myself, add some logging, and run it, didn't have time yet (any help is welcome here).
BTW, when I said:
I guess I was talking about a different bug, which is also still open: #6735. I hit this other bug too if, instead of using NuGet 5.0.2, I use NuGet 4.5.1 (without the need of using the -MSBuildVersion flag). I'm going to post a stacktrace of this problem in that other bug report.
NuGet.CommandLine: improve xbuild detection
knocte commented on Jun 17, 2019
Alright, I found a fix for this, which I proposed as a PR here: NuGet/NuGet.Client#2891
Now I will investigate my next issue: #6735