Bug 45137 - Seeing new AAPT0000 errors when building certain projects against master
Summary: Seeing new AAPT0000 errors when building certain projects against master
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: 7.1 (C9)
Hardware: PC Mac OS
: --- blocker
Target Milestone: 7.0.1 (C8SR1)
Assignee: Ankit Jain
: 46171 46782 ()
Depends on:
Reported: 2016-10-06 21:15 UTC by Kyle White
Modified: 2016-11-14 20:19 UTC (History)
8 users (show)

Is this bug a regression?: Yes
Last known good build: XA

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 on Developer Community or GitHub 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.

Related Links:

Description Kyle White 2016-10-06 21:15:03 UTC
To repro:
1) Clone this sample: https://github.com/xamarin/Sport
2) Build it from XS

XA Version
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 (C8SR0.1)
Comment 1 dean.ellis 2016-10-07 10:35:45 UTC
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.
Comment 2 Kyle White 2016-10-10 16:54:29 UTC
@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 resolved the build errors within the same XS build.
Comment 3 dean.ellis 2016-10-11 08:00:38 UTC
Cc'ing Greg. Odd it builds from the command line ok but not in XS..
Comment 4 dean.ellis 2016-10-11 08:52:00 UTC

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.
Comment 5 dean.ellis 2016-10-12 10:06:01 UTC
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'
Comment 6 dean.ellis 2016-10-14 16:40:47 UTC
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.
Comment 7 dean.ellis 2016-10-17 10:28:55 UTC
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.
Comment 8 dean.ellis 2016-10-26 09:13:39 UTC
Fixed in xamarin-android/master/0ca2c216
and monodroid/master/af65c9e6
Comment 9 Kyle White 2016-11-06 20:08:15 UTC
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. 

About information:
Diagnostic build output: https://gist.github.com/kdubau/e58d78c5a41c4053660fce0863b1182f

## C8SR1
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

Given this can now be reproduced in C8SR1, I'm changing the milestone and bumping the severity.
Comment 11 Kyle White 2016-11-06 20:22:26 UTC
I made a typo in Comment 9, I meant to say I CAN reproduce this on our release candidates for C8SR1.
Comment 12 Brendan Zagaeski (Xamarin Team, assistant) 2016-11-07 17:30:24 UTC
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 + Xamarin Studio + 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.
Comment 13 Jonathan Pryor 2016-11-07 23:58:35 UTC
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.
Comment 14 Jonathan Pryor 2016-11-07 23:59:26 UTC
Thus, the question: Why is $(DesignTimeBuild) a Global Property, and how do we fix it so that $(DesignTimeBuild) *isn't* a Global Property.
Comment 15 Greg Munn 2016-11-08 16:17:37 UTC
Assigning to marius for him to take a look from XS side
Comment 16 Marius Ungureanu 2016-11-09 15:00:53 UTC
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?
Comment 17 Marius Ungureanu 2016-11-09 15:03:26 UTC
Also, the reason why it's a global property, and not a normal property is because Project.SetProperty is not implemented in xbuild [0]

[0] - 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.
Comment 18 Marius Ungureanu 2016-11-09 15:09:23 UTC
As clarification, the MSBuildPropertyGroup for both the project being built _and_ the engine have no property with the key DesignBuildTime.
Comment 19 Marius Ungureanu 2016-11-09 15:22:41 UTC
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?
Comment 20 Kyle White 2016-11-09 22:22:49 UTC
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.
Comment 21 Kyle White 2016-11-09 22:24:02 UTC
XS About info, https://gist.github.com/kdubau/657e1c16d11fbc71f6e6c1e39c18a5dc
Comment 22 Marius Ungureanu 2016-11-10 00:09:44 UTC
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
Comment 23 dean.ellis 2016-11-10 11:59:53 UTC
*** Bug 46700 has been marked as a duplicate of this bug. ***
Comment 25 Peter Collins 2016-11-11 15:17:27 UTC
Verified fixed against mono/mono-4.6.0-branch/08fd525c3392305e0b8f5c9d9ca902f36a055ff3.
Comment 26 Jon Douglas [MSFT] 2016-11-11 16:17:52 UTC
Didn't find this bug until now. I think I wrote a duplicate bug yesterday:

Comment 27 Jon Douglas [MSFT] 2016-11-11 16:32:39 UTC
*** Bug 46782 has been marked as a duplicate of this bug. ***
Comment 28 Jonathan Pryor 2016-11-14 20:19:26 UTC
*** Bug 46171 has been marked as a duplicate of this bug. ***