Bug 37820 - Newly created wear app has code issues
Summary: Newly created wear app has code issues
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: 7.1 (C9)
Hardware: PC Mac OS
: Normal normal
Target Milestone: master
Assignee: dean.ellis
Depends on:
Reported: 2016-01-19 23:58 UTC by Mikayla Hutchinson [MSFT]
Modified: 2017-03-21 20:21 UTC (History)
5 users (show)

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

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 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 original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • 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 Mikayla Hutchinson [MSFT] 2016-01-19 23:58:05 UTC
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.
Comment 1 Greg Munn 2016-01-20 15:35:26 UTC
Fixed in version (master)

Author: Greg Munn
Commit: 2a8c3e9f0af326849b5f6ed1f0025dcf0439d388 (xamarin/md-addins)
Included in Commit: 3ad46bff1c430f9718af58610550f9db8aa2a532 (mono/monodevelop)
Comment 3 Greg Munn 2016-11-21 19:25:07 UTC
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.
Comment 4 Greg Munn 2016-11-21 20:29:21 UTC
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.
Comment 5 Greg Munn 2016-11-21 20:43:25 UTC
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'

Comment 6 dean.ellis 2016-11-22 10:46:25 UTC
This looks like its because we are not getting "AdditionalAndroidResourcePaths" for some reason. I'll take a look
Comment 7 dean.ellis 2016-11-22 12:19:48 UTC

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.
Comment 8 Greg Munn 2016-12-13 15:50:50 UTC
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.