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 32498 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
Android.Support.v4, Android.Support.v7.AppCompat, and Android.Support.Design each download a separate copy of android_m2repository_r16.zip
If an Android app project references all of the following NuGet packages, it will download android_m2repository_r16.zip from  three separate times.
> - <package id="Xamarin.Android.Support.Design" version="126.96.36.199" targetFramework="MonoAndroid50" />
> - <package id="Xamarin.Android.Support.v4" version="188.8.131.52" targetFramework="MonoAndroid50" />
> - <package id="Xamarin.Android.Support.v7.AppCompat" version="184.108.40.206" targetFramework="MonoAndroid50" />
This might be a mostly ignorable issue, but I figured I would file an enhancement request anyway for documentation if nothing else.
## Steps to reproduce
1. Delete the following folders if they exist (to force the build to repopulate them):
> - ~/.local/share/Xamarin/Android.Support.Design/22.2.1
> - ~/.local/share/Xamarin/Android.Support.v4/22.2.1
> - ~/.local/share/Xamarin/Android.Support.v7.AppCompat/22.2.1
2. Build the attached test case (or add the Xamarin.Android.Support.Design NuGet package to a new Android app project, and build that).
3 identical copies of android_m2repository_r16.zip (about 96 MB each) are downloaded during the build. At least on my network connection, dl-ssl.google.com is not terribly fast, so the extra delay of downloading 2 extra times is quite noticeable.
### Excerpt from the diagnostic MSBuild output
> Downloading https://dl-ssl.google.com/android/repository/android_m2repository_r16.zip into /Users/macuser/.local/share/Xamarin/Android.Support.v4/22.2.1
> Downloading https://dl-ssl.google.com/android/repository/android_m2repository_r16.zip into /Users/macuser/.local/share/Xamarin/Android.Support.v7.AppCompat/22.2.1
> Downloading https://dl-ssl.google.com/android/repository/android_m2repository_r16.zip into /Users/macuser/.local/share/Xamarin/Android.Support.Design/22.2.1
## Possible improvements
Perhaps the `~/.local/share/Xamarin` cache folder could be restructured so there would be a shared "android_m2repository" subfolder to store all of the cached downloads of those `.zip` files? The `.zip` files could then be symlinked (or hardlinked, or even just copied) into the individual package folders if needed for backwards compatibility.
## Additional version info (brief)
### Mac OS X 10.10.4
Xamarin Studio 5.9.5 (build 6)
Created attachment 12239 [details]
Created attachment 12240 [details]
Diagnostic build output
Created attachment 12241 [details]
Additional version information
I believe we are aware of this and there is nothing that we can do at this time. Can you verify?
Right now the way attributes are specified, we actually are extracting a .aar file from within a .zip file. This gets extacted to `~/.local/share/Xamarin/Android.Support.Design/22.2.1/`, however inside that folder the actual .aar contents are extracted to an `embedded`folder. If we were to point each support library to the same shared cache/extract location, they would all expect their .aar contents to be in the same `embedded` which of course would be incorrect.
So, tl;dr, unfortunately the way the attributes currently work, we cannot share a downloaded .zip file. It would work if we didn't need to extact the .aar from within the zip, but this is not the case.