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 for Bug 37820 on
Developer Community or GitHub 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
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
A newly created wear app has errors: http://screencast.com/t/bnhkoyYJ
These go away when I compile the project, close it and re-open it. It looks like the Resources.designer.cs isn't being updated and loaded into the type system like it is for normal android apps.
Fixed in version 184.108.40.20624 (master)
Author: Greg Munn
Commit: 2a8c3e9f0af326849b5f6ed1f0025dcf0439d388 (xamarin/md-addins)
Included in Commit: 3ad46bff1c430f9718af58610550f9db8aa2a532 (mono/monodevelop)
Ok, so not completely related to the issue I fixed in the commit in comment #1
This variant seems to be that the call to resgen is invoked too early, since we get these errors:
> Updating Resources...
> Reference 'Xamarin.Android.Wearable' not resolved
> No resource identifier found for attribute 'rectLayout' in package 'com.companyname.wear1'
> No resource identifier found for attribute 'roundLayout' in package 'com.companyname.wear1'
Re-building fixes the issue because the package has been added by that stage. I think in this case it would be correct to wait until the project was fully instantiated (and packages added) before we try to generate the resources file. However, I don't know of any api that we could leverage to make this work.
I suspect that even using the coming Generator support for resource items would fail because we'd still be in the same situation.
mmm. I can get it to detect and fix the first error
> Reference 'Xamarin.Android.Wearable' not resolved
but the other 2 remain and I still have to perform a build in order for the code issue to be removed. In fact, it appears that a build is a must in this case. Forcing the resources to be generated by editing a resource file, closing and re-opening the project don't resolve the issue.
ok. asking for help from the XA team.
1. Create a Wear app
2. Wait for the nugets to be restored
3. Do NOT do a build
4. run the following on the cmdline
> xbuild /t:UpdateAndroidResources /p:DesignTimeBuild=true
5. You should see the following errors
> Resources/layout/Main.axml(2): error APT0000: No resource identifier found for attribute 'rectLayout' in package 'com.companyname.wear14'
> Resources/layout/Main.axml(2): error APT0000: No resource identifier found for attribute 'roundLayout' in package 'com.companyname.wear14'
This looks like its because we are not getting "AdditionalAndroidResourcePaths" for some reason. I'll take a look
now that I think about it ... this is expected. You will get the errors
identifier found for attribute 'rectLayout'
if you have NOT built properly first. This is because the building of the Resource cache will involve downloading stuff from the internet.
For example wear apps need 'm2repository/com/google/android/support/wearable/1.3.0/wearable-1.3.0.aar' which is going to have to be downloaded.
DesignTimeBuilds purposely DO NOT download stuff. This is because VS requires that those builds are quick (for intellisense purposes). So this is totally expected.
Once a normal build has been done those errors will go away.
So the tasks are working as expected in this case.
I'm re-assigning to Dean because the real issue is in the targets. (Edit: Dean beat me to it, but here's the gist of it).
"I think I need to rework the task a bit more and I’ve just had an idea on how to do that. it might be that I can just skip the download bit but do all the other bits it does" -- Dean (private message to me on Nov 22 '16)
The issue is that the resgen target fails to generate any resources because a build hasn't been done. The reason is because the target doesn't think the appropriate files have been downloaded. However, except for the very first run on a machine, the files have been downloaded, it's just that the resgen target isn't aware of the fact until after a build is done.
I don't see how XS can resolve this by itself without forcing a build to be done as soon as the project is created, or manually adding in a resource id from the template (and I'm not sure we can actually do that).
Note: This won't fix the very first instantiation of a template for that api level on that machine, since the files it needs won't actually be downloaded yet. This is just to work around all the other cases. I'm not sure how that should be solved right now. Maybe it's something we can address with on demand downloads - we can then trigger the resgen target and (without a build) it can pick up the fact that the files are available and generate the appropriate resource ids.