Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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 on
GitHub or Developer Community with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
In VS 2015, do a File / New Project for a Xamarin Blank App (Native Portable). Now try to build the project on a Mac, using xbuild. That happens, in for example, when you use the new Xamarin iOS build task in Visual Studio Team Services.
Result: xbuild gets an error on the build complaining about a missing GUID in the project reference, like the following:
/Users/vso112383/vsts-agent/_work/2/s/HelloWorld/Xamarin.HelloWorld.sln (default targets) ->
(Build target) ->
/Users/vso112383/vsts-agent/_work/2/s/HelloWorld/HelloWorldApp/HelloWorldApp.iOS/HelloWorldApp.iOS.csproj (default targets) ->
/Library/Frameworks/Mono.framework/Versions/4.2.3/lib/mono/4.5/Microsoft.Common.targets (AssignProjectConfiguration target) ->
/Library/Frameworks/Mono.framework/Versions/4.2.3/lib/mono/4.5/Microsoft.Common.targets: error : Project reference '../HelloWorldApp/HelloWorldApp.csproj' has invalid or missing guid for metadata 'Project'.
As a workaround, you can edit the iOS csproj file and add the PCL project's guid to the reference manually, adding a GUID line as shown here:
That makes the build work, but of course shouldn't be necessary.
Likely we should fix xcode to work in this scenario.
This was a customer reported issue, from an email thread that Mikayla and myself were cc'ed on. It's easily reproduced.
This has already been fixed in cycle7 (Mono 4.4.x) which is currently on the alpha update channel.
I constructed a test case and verified that it works correctly with the xbuild in in Mono 188.8.131.52.
On inspection the AssignProjectConfiguration code in MSBuild, it appears that MSBuild used to require a GUID in project references, but it was changed to lookup by path when the GUID is are not present. xbuild doesn't have this fallback, but in the case described in the bug this doesn't seem to be a problem in practice. We'll be moving to MSBuild soon so this will be a moot point.
Looks like I spoke too soon.
I tried a more complex example, and even with the fix, it errors out.
Using task AssignProjectConfiguration from Microsoft.Build.Tasks.AssignProjectConfiguration, Microsoft.Build.Tasks.v4.0, Version=184.108.40.206, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
/Library/Frameworks/Mono.framework/Versions/4.4.0/lib/mono/4.5/Microsoft.Common.targets: warning : Project reference '../App1/App1.csproj' could not be resolved.
We need to do as MSBuild does and write the full file path for each project into CurrentSolutionConfigurationContents, and have AssignProjectConfiguration use the path as a fallback if the GUID is not set.
NOTE: I bumped priority on this because our VS extension is creating projects without the GUID in the project references.
This appears to be fixed in the C7 version of the extension (https://github.com/xamarin/XamarinVS/commit/9d5af3a1a1ef8d91fa11b2cf8f2eb6be729ef23d) but there will likely be many existing projects that hit this bug in xbuild.
Created attachment 15619 [details]
This has been fixed in master and the C7 (4.4.0) branch: