Bug 60182 - MSBuild struggles to restore for unknown reasons
Summary: MSBuild struggles to restore for unknown reasons
Alias: None
Product: Tools
Classification: Mono
Component: msbuild ()
Version: unspecified
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Ankit Jain
Depends on:
Reported: 2017-10-13 17:38 UTC by Matthew Leibowitz
Modified: 2017-10-25 20:34 UTC (History)
2 users (show)

Is this bug a regression?: ---
Last known good build:

binlog (1.64 MB, application/x-gzip-compressed)
2017-10-20 15:53 UTC, Matthew Leibowitz
Simple TestCase (8.41 KB, application/zip)
2017-10-25 01:30 UTC, Matthew Leibowitz

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report for Bug 60182 on GitHub or Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description Matthew Leibowitz 2017-10-13 17:38:37 UTC
There appears to be some issue during the restore, it just says a task failed, but then no error:

    Build FAILED.
        0 Warning(s)
        0 Error(s)

This is nothing special, it was working fine in the 5.4 alpha and the 5.2 stable. As soon as I upgraded, the build failed.

I downloaded: 


and then run:

    msbuild /t:restore source/SkiaSharpSource.Mac.sln
Comment 1 Matthew Leibowitz 2017-10-14 00:07:41 UTC
I am not sure where the issue lies exactly, but I think I can find out the start. If I try and restore the solution, it fails. If I remove the projects that reference the iOS, macOS, tvOS binding libraries, then it restores.

Another thing to note is that Android is fine, just the iOS, macOS, tvOS projects have issues.

In the solution I have a SkiaSharp.Views.Forms.*, SkiaSharp.Views.* and SkiaSharp.* projects with the dependencies in that order.
Comment 2 Matthew Leibowitz 2017-10-16 20:55:52 UTC
I am just adding a note that I am using <ProjectReferences>
Comment 3 Matthew Leibowitz 2017-10-17 00:56:40 UTC
Looking at this some more, I noticed something strange. It actually always "failed", but in v5.2, the NuGets were restored so the build worked.

Mono 5.2: https://gist.github.com/mattleibow/04ebe1b7481932c0f593c47b274c9935
Mono 5.4: https://gist.github.com/mattleibow/cd54fc53e26570159644bf57ebb9b2cb
Comment 4 Kirill Osenkov 2017-10-17 14:05:07 UTC
Consider using http://msbuildlog.com/ and attach the .binlog here so we can see what's going on during the build.
Comment 5 Matthew Leibowitz 2017-10-20 15:53:54 UTC
Created attachment 25384 [details]
Comment 6 Matthew Leibowitz 2017-10-25 01:30:01 UTC
Created attachment 25434 [details]
Simple TestCase

After much testing, I have narrowed it down to something super weird. It appears to occur when these conditions are met:

 - there is an iOS library XX that depends on library AA
 - the iOS library AA has this element:
 - the library XX is listed before the library AA in the sln:


  Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "ClassLibraryXX", "ClassLibraryXX\ClassLibraryXX.csproj", "{BA5021FE-4690-43A2-B492-6C86F12D1148}"
  Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "ClassLibraryAA", "ClassLibraryAA\ClassLibraryAA.csproj", "{E9FAB283-5E54-447A-9F8A-5E16FFC3468F}"


  Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "ClassLibraryAA", "ClassLibraryAA\ClassLibraryAA.csproj", "{E9FAB283-5E54-447A-9F8A-5E16FFC3468F}"
  Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "ClassLibraryXX", "ClassLibraryXX\ClassLibraryXX.csproj", "{BA5021FE-4690-43A2-B492-6C86F12D1148}"

Now... if we remove the <MSBuildWarningsAsMessages> element from library AA, then the order in the solution does not matter. If we keep it, we have to make sure library AA project is listed before library XX.

I tried with iOS binding projects and iOS class libraries, the same result.

The reason to keep the <MSBuildWarningsAsMessages> element is to avoid the annoing warning:

  warning MSB9004: ManifestResourceWithNoCulture item type is deprecated.
  Emit EmbeddedResource items instead, with metadata WithCulture='false',
  Type='Resx', and optional LogicalName.

This warning appears for iOS binding projects, so, until that warning is fixed I would like to keep the element.
Comment 7 Ankit Jain 2017-10-25 20:34:18 UTC
Tracking this in an upstream issue too - https://github.com/Microsoft/msbuild/issues/2667 .