1) Clone this sample: https://github.com/xamarin/Sport
2) Build it from XS
XA Version 18.104.22.168
Diagnostic build output: https://gist.github.com/kdubau/9823afecb4373d03f9c0274f4b242685
Resources/layout/Tabbar.axml(2): error APT0000: No resource identifier found for attribute 'tabIndicatorColor' in package 'com.xamarin.sport_public'
Resources/layout/Tabbar.axml(2): error APT0000: No resource identifier found for attribute 'tabGravity' in package 'com.xamarin.sport_public'
Resources/layout/Tabbar.axml(2): error APT0000: No resource identifier found for attribute 'tabMode' in package 'com.xamarin.sport_public'
Resources/layout/Tabbar.axml(2): error APT0000: No resource found that matches the given name (at 'background' with value '?attr/colorPrimary').
Resources/layout/Tabbar.axml(2): error APT0000: No resource found that matches the given name (at 'theme' with value '@style/ThemeOverlay.AppCompat.Dark.ActionBar').
Resources/layout/Toolbar.axml(2): error APT0000: No resource found that matches the given name (at 'background' with value '?attr/colorPrimary').
Resources/layout/Toolbar.axml(2): error APT0000: No resource found that matches the given name (at 'theme' with value '@style/ThemeOverlay.AppCompat.Dark.ActionBar').
Resources/layout/Toolbar.axml(2): error APT0000: No resource found that matches the given name (at 'popupTheme' with value '@style/ThemeOverlay.AppCompat.Light').
Builds successfully in XA 22.214.171.124 (C8SR0.1)
I cannot replicate this issue.
It looks similar to 44425. It seems the Nuget resources cache is corrupt.
try deleting all the Xamarin.* folder (leave Mono for Android)
and building again.
Might be worth backing up your current ~/.local/share/Xamarin and doing a diff between the two to see what changes.
@Dean, I tried your suggestion but was still able to reproduce the errors when building from XS.
I realized, I am able to successfully build the droid project using xbuild on the command line so this must have something to do with XS/XA integration? Because reverting _only_ XA to 126.96.36.199 resolved the build errors within the same XS build.
Cc'ing Greg. Odd it builds from the command line ok but not in XS..
ok we need to narrow this one down a bit.
Can you use the XS form the C7 release and try XA from master and see what happens.
If we still get failures then we need to do a diagnostic build with the detailed summary for both the working and non working versions.
Then we can look at what is different between the two. We did have a problem recently where the Before/After Targets in the .targets files were NOT being honoured as a result all sorts of weird stuff happened.
I'll try in XS today and see if I can repo, but if you can also get the info that would really be helpful.
building from the command line the only way I can repo that bug(45137) is to pass /p:DesignTimeBuild=true on the second build so I do
`xbuild Sport.Mobile.Droid.csproj /t:UpdateAndroidResources /p:DesignTimeBuild=true /v:d`
which is what XS does when it first loads the project. This updates the resources.. the first build will fail because we don’t get the “additional” stuff it needs for a design time build
now if I do
`xbuild Sport.Mobile.Droid.csproj /t:SignAndroidPackage /v:d`
next it downloads the stuff it needs and the build works, which is not what we see in XS when the user hits “Build"
the only way to repo the bug we get in XS is to run
`xbuild Sport.Mobile.Droid.csproj /t:SignAndroidPackage /v:d /p:DesignTimeBuild=true`
which suggests that XS is keeping the property around or passing it for normal builds. But looking at the code its only mentioned once when calling 'UpdateAndroidResources'
Weirdly. During a build of the project in XS it seems the value for DesignTimeBuild is being reset to ''.
Its setting set to false
The later the value appears to be ''
as a result it gets set to true and the dependencies are not downloaded.
This seems to be happening only in Xamarin Studio. I have tried via the command line and via a custom build app which uses the msbuild Engine class directly and don't get the problem.
Fixed in xamarin-android/master/0ca2c216
Unfortunately, some bad news. Firstly, I can still reproduce this same behavior in master. Second, whatever breaking change caused this seems to have made it's way into C8SR1 as I can not reproduce this on our release candidates for C8SR1.
Diagnostic build output: https://gist.github.com/kdubau/e58d78c5a41c4053660fce0863b1182f
About information: https://gist.github.com/abe0c971b146fd17ec54c7dc2024f99b
Diagnostic build output: https://gist.github.com/kdubau/893f85c6d96c500e1d8410ee02c3496b
## Regression status
Again, I still have no problem building this sample in C8SR0 XA 188.8.131.52
Given this can now be reproduced in C8SR1, I'm changing the milestone and bumping the severity.
I made a typo in Comment 9, I meant to say I CAN reproduce this on our release candidates for C8SR1.
Based on the clue about the difference in behavior between `xbuild` command line builds and building in XS, I had a hunch this bug might be caused by the `Microsoft.Bcl.Build.targets` just like Bug 35323 (where there was a very similar discrepancy between command line builds and builds in XS). In short, it looks like the problem in this new bug _is_ closely related:
- I was able to replicate the problem as described in Comment 0 using Xamarin.Android 184.108.40.206 + Xamarin Studio 220.127.116.11 + Mono 4.6.2 (db69866).
- I was able to stop the problem by commenting out the following line from Sport.Mobile.Droid.csproj and then cleaning and rebuilding the project
> <Import Project="..\packages\Microsoft.Bcl.Build.1.0.21\build\Microsoft.Bcl.Build.targets" Condition="Exists('..\packages\Microsoft.Bcl.Build.1.0.21\build\Microsoft.Bcl.Build.targets')" />
- I was able to reintroduce the problem by un-commenting the line and cleaning and rebuilding again.
## Additional test: experimental MSBuild setting also stops the problem
Test: I tried enabling "Xamarin Studio > Preferences > Build > Build with MSBuild instead of xbuild (EXPERIMENTAL)" to see if that might stop the problem (based on the analysis from Bug 35323 where xbuild appeared to be the culprit).
Result: "GOOD". Enabling this setting also stopped the problem. One little hiccup I noticed is that after changing the preference I had to close and reopen the solution in Xamarin Studio in order to get Xamarin Studio to use MSBuild rather than xbuild during the build.
Current state of affairs and analysis:
@peterc narrowed down the breakage to these commits:
Rephrased, the fix for Bug #44633 "caused" bug #45137.
Note the "scare quotes" in "caused".
The apparent cause of Bug #44633 was that builds within Xamarin Studio would seemingly "ignore" AfterTargets and BeforeTargets values:
So the "actual" cause of Bug #44633 is seemingly related to the MSBuild integration with Xamarin Studio. The *actual* cause/problem here was never determined, e.g. *why* was Xamarin Studio+xbuild ignoring AfterTargets and BeforeTargets? We still don't know.
The fix for Bug #44633 was to *remove* all use of AfterTargets and BeforeTargets, instead using "normal" property overrides, which seemed to work as expected.
The problem here, in bug #45137, appears to be the same: *something* in the Xamarin Studio/MSBuild integration is "wrong". This time it's not AfterTargets/BeforeTargets; now it's related to setting the values of MSBuild properties.
MSBuild and xbuild support "Global Properties". These are properties with values which *cannot be changed from "code"*, such as .targets files:
Which brings us to the $(DesignTimeBuild) MSBuild property. This is a property, provided by the IDE, to let us know if we're doing a "real" build ($(DesignTimeBuild)=False), or just building for the Designer, i.e. there's a user sitting around, Waiting To Do Something™, so we really shouldn't go off and download GBs of data ($(DesignTimeBuild)=True).
In Visual Studio, this is a normal property.
In Xamarin studio, this is a global property.
Thus, if we update Xamarin.Android.Common.targets to *always* set $(DesignTimeBuild) to False:
...which would be a less-than-stellar user experience, because starting the designer would require that you download all dependencies...
...it still fails. DesignTimeBuild is *always* True, as can be seen in Xamarin Studio diagnostic output when using a "patched" Xamarin.Android.Common.targets via the above gist;
# jonp: DesignTimeBuild=true
*Because* $(DesignTimeBuild) is True, our build system will *never* download referenced dependencies, or add those dependencies to the `aapt` invocation.
Thus, the question: Why is $(DesignTimeBuild) a Global Property, and how do we fix it so that $(DesignTimeBuild) *isn't* a Global Property.
Assigning to marius for him to take a look from XS side
From my debugging efforts, it seems like the XBuild Build Engine _does_ get the global property cleared from the XS side, and even inspecting BuildEngine.GlobalProperties shows that the property is removed.
Might be a bug in xbuild where it gets cached?
Also, the reason why it's a global property, and not a normal property is because Project.SetProperty is not implemented in xbuild 
 - https://github.com/mono/mono/blob/0bcbe39b148bb498742fc68416f8293ccd350fb6/mcs/class/Microsoft.Build.Engine/Microsoft.Build.BuildEngine/Project.cs#L796-L803
Given that it works with MSBuild, this clearly states that the bug is in xbuild itself.
As clarification, the MSBuildPropertyGroup for both the project being built _and_ the engine have no property with the key DesignBuildTime.
I'm going on a whim here, but:
Shouldn't we set the project to need re-evaluation when we set back the old global properties?
I tested with the build from https://wrench.internalx.com/Wrench/ViewLane.aspx?lane=mono-mono-4.6.0-xbuild-bug&host_id=148&revision_id=826498
but the issue remains, unfortunately.
XS About info, https://gist.github.com/kdubau/657e1c16d11fbc71f6e6c1e39c18a5dc
Assigning to Ankit, as this is an xbuild bug:
XS code is here, we do unset the global property for DesignBuildTime.
The code I tried to fix was here: https://github.com/mono/mono/commits/mono-4.6.0-xbuild-bug
*** Bug 46700 has been marked as a duplicate of this bug. ***
Verified fixed against mono/mono-4.6.0-branch/08fd525c3392305e0b8f5c9d9ca902f36a055ff3.
Didn't find this bug until now. I think I wrote a duplicate bug yesterday:
*** Bug 46782 has been marked as a duplicate of this bug. ***
*** Bug 46171 has been marked as a duplicate of this bug. ***