Forum Xamarin.Android

Why modifying a XML or any other resource file force Xamarin to rebuild the entire project ?

Hello !

This is getting on my nerve.

I am not using a very fast PC for work, but whenever I have to modify an Android resource (be it a simple dimens.xml or activity xaml file), Xamarin Studio, upon saving the modifications, starts building for a long time (up to 2 minutes).

Morever, and this is very disturbing: when deploying the application after I modified the resources, Xamarin Studio completely removes the application in order to install it over, hence deleting any stuff inside the application directory (data, database, prefs etc.).
This is really a pain in you-know-where.

I am working on my layouts and a single modification to be saved uses my CPU to 100% (with aapt.exe) for a LONG time...

Why, just why ?

When I modify some code inside the Android project, it compiles very very fast and deploy in a matter of seconds. That's amazing.
When I modify some code inside a portable library referenced by the Android project, then it's the same problem as above all over again.

So big cons :

  • way too long buildind time and high CPU usage (computer almost unusable during build time) ;
  • application is entirely deleted from the targeted device, including the internal data ;

My computer : Asus Zenbook with a Dual Core i7 3517U CPU clocked at 3GHz

Thanks for the help !

PS: Using Android Studio is a bliss whenever it comes to designing layouts.
So for now I do all my designs with it.
But back when I used Java & Android Studio, adding XML or any resource was fast, flexible and efficient. With Xamarin Studio, my productivity is very low.



  • MihaMarkicMihaMarkic SI ✭✭✭✭

    There you go for preserving files.
    As per changes in axml or xml, I guess it has to rebuild resources and for some reason your building process is slow in that case. perhaps outdated Android SDK tools? What Xamarin version?

  • VincentRicardVincentRicard USMember ✭✭

    Thank you @MihaMarkic for your quick answer !

    I will immediately check the option to preserve my files, that is perfect ! I will report to see if it worked as expected !

    As to your questions, I can understand that the Resource.Designers.cs has to be rebuild. But it takes too much time.
    I mean, if I just add a single space or character or single change in any XML/AXML file and save that modification, it looks like Xamarin is entirely rebuilding all resources files !

    Here are the details you asked :

    • Android SDK Tools v. 24.1.2 (seems like a new version is available : 24.2 will it change anything ?)
    • Android SDK Plateform-tools v. 22 (no available update)
    • Xamarin Android version 5.1.0 (Indie Edition)
    • Xamarin Studio stable version 5.9 just updated today with build 431

    Seems OK to me. Do you see something wrong here ?

    Thanks again !

  • MihaMarkicMihaMarkic SI ✭✭✭✭

    Looks fine to me.

  • VincentRicardVincentRicard USMember ✭✭

    Then I am at a loss :/

    My productivity is very slow as I am working a lot on the layouts. I managed to load off a lot of work in Android Studio because its designer is very good, but I will be facing long building time each time I need to try either a slight change or a big change. No difference here !

    Anyway, you have my thanks.

  • MihaMarkicMihaMarkic SI ✭✭✭✭

    Hey, hold one. Perhaps we'll find the source of the problem. How big is your solution? if you create a blank android app are slow build times similar?

  • VincentRicardVincentRicard USMember ✭✭

    Alright after multiple tests and some debugging I tried your solution.

    I created a whole new solution. I edited the single activity and the building time was blazing short !
    So this would concur with your idea of my solution being heavy.

    For that matter I currently have:

    • over a 100 drawables (pictures, images & drawables like gradient)
    • 17 layouts (over 10 activities, a few fragments / layout items)
    • a handful of color, strings, dimens and styles XML files

    So you could say it's a big project. It's supposed to be, I am not created a simple app.
    The lis of features is impressive and I am only at the beginning ! ^^

    That's why I hate it when Xamarin rebuilds all of these files. No wonder it takes so much time !
    I wonder why it would not build only the file that were actually created/modified/deleted ?

    What do you think ?

  • rmaciasrmacias USBeta, University ✭✭✭✭✭

    This sound it could be similar to your situation. Maybe you can add your log files (after you re-create the issue) to the bug report and someone can take a look at it.

  • VincentRicardVincentRicard USMember ✭✭

    Hmm sorry but my case seems to be different from that bug report.

    First the author states that Xamarin does recompile all ressources when a modification occurs which conforts me in my position.

    The difference is, however, that the IDE does not get hanged. I can still do stuff. But my CPU is bottlenecked at 100% during build time. And the more ressources files, the longer the build time is :/

  • DanielVartdalDanielVartdal USMember ✭✭
    edited May 2015


    In Visual Studio I have the same irritating problem as you; Minor changes in the layout forces a rebuild that takes up to 2 minutes. (100% cpu all the way)

    Including new resources (include file) takes ages. (100% cpu all the way)

    When I need to include new resources in my solution I use Xamarin Studio to include new files. This is 100x faster. Then switch over to Visual Studio and start developing again.

    Do you have any components installed, like Android Support libraries? Appcompat or similar?

  • VincentRicardVincentRicard USMember ✭✭

    @DanielVartdal yes I am using Android Support libraries such as AppCompat and few other packages (like Oxyplot, Newtonsoft, MathNetNumerics).
    Is is "their" fault ?

    However, I am not using Visual Studio (only indie license). I am using Xamarin Studio so I cannot use your solution :/

    For now I am still using Android Studio. Once I am please with layouts, XMLs and other, I do a "big update" so that I compile only once.

    The only problem is that his workaround does not apply when trying to modify a single element... that's where I loose a lot of time !!

  • DanielVartdalDanielVartdal USMember ✭✭

    @VincentRicard I'm not quite sure. I have a little hypothesis that this could be the problem.

    I had another solution without the AppCompat libraries, and when I did adjustments on the layout it built very fast.

    It had similar amount of layouts, but not as many drawables as my current solution.

    Just a hypothesis of course, haven't had the time to test it any further on my solution.

  • VincentRicardVincentRicard USMember ✭✭

    @DanielVartdal so what do you think I should try out ? Thanks for your input !

  • DanielVartdalDanielVartdal USMember ✭✭
    edited May 2015

    @VincentRicard Well, the only thing I could say is; try and test it out.

    You could make a copy of your solution, containing all drawables, but removing the styles and layouts (since you're using AppCompat and using the appcompat themes?). And then remove the component.

    Try and build and see if it gets faster after doing changes in the layout. If not, then the problem is not the AppCompat component. If it gets faster, then all we can do is filing a bug and hope it will be fixed.

    If you still think it may be one of the components, then you need to remove one component at the time and build the solution, do changes, and build again to see if the problem exists. If the problem still exist. Try removing all drawables etc. And see if you can find the bottleneck when building your solution.

    I'm sorry that I can't give any precise answer. It's just my assumptions and hypothesis about what the problem can be.
    Currently I don't have time to test this myself since I'm currently in delivery of a solution (and not doing too many changes in the layouts)

  • VincentRicardVincentRicard USMember ✭✭

    @MihaMarkic I am sorry for answering so late, but it does not work. My app get uninstalled nonetheless and all of is internal data is gone each time.

    Why ?

  • VincentRicardVincentRicard USMember ✭✭

    @DanielVartdal I tried with an new Android Project and the build time is very short. So I believe that the amount of XML files will impact the build time. Although I do not gather why the system could not just rebuild the one what where modified.

  • DanielVartdalDanielVartdal USMember ✭✭

    @VincentRicard Yeah, I see the same for build times. Clean new solution has a short amount of build time. But I see when using PCL, Components and shared class libraries for my app, all these impact build time in a negative way.

    I added a new app last week, made some common code in a class library. Every time I do changes in this class library, the build time is slow (as in doing a minor change in a XML file). So I still think there are some issues with the Xamarin build and components/libraries that are referenced to by your main application.

    Using Xamarin Studio does improve build time slightly though.

  • TavroxTavrox FRMember ✭✭

    Hi vincent ricard !
    I have the EXACT same problem of productivity. I also have loads of views (around 25 layouts, 100 drawables) and my layout edition is very very slow. I have some leads about it, maybe you could try them too...

    I use unique ID for every elements (relative layouts, views, textview etc). This might cause the whole Resource.Designer to regenerate 3000 lines, which is long. I will try to simplify every layout and have them duplicate global ID.

    For instance...
    In layoutone.axml i have 3 texts.
    In layouttwo.axml i have 3 texts.
    in layout one > "layoutone_sometext" ; "layoutone_another" and "layoutone_something"
    in layout two > "layouttwo_sometext" ; "layouttwo_another" and "layouttwo_something"
    This make 6 id.
    A solution would be to make them the same id. As the view are locally thought (eg : toLeftOf property), maybe naming them the same way would work... ?
    It would become.

    in layout one > "text1" ; "text2" and "text3"
    in layout two > "text1" ; "text2" and "text3"
    Becomes 3 id. If you replace this around 20 layouts, it becomes significant.
    While you loose naming and code clarity, if it enhances performance I'm okay with it.

    I use java binding for SVG. I'll get rid of it soon because I'll use vector drawable only... do you have some java binding in your project ? maybe that's the cause of slow down ?

    also, I don't have licence for profiler, do you have one and if yes, did you launch some test ? Maybe that would give hints, not sure about that....

    I'll keep track of the post, if you have workarounds please post them :)


  • TavroxTavrox FRMember ✭✭
    edited June 2015

    FYI, just tried the unique ID solution, doesn't work. Xamarin auto regenerates an int for each ID, even if the object name is the same... crazy right ?

    It generates for example

    // aapt resource value: 0x7f02010c
    public const int relativeLayout1 = 2131296524;

    // aapt resource value: 0x7f09010c
    public const int relativeLayout1 = 2133596524;

    If you find a way to get rid automatically of comments and jump space between generated id, that would also reduce by 2/3 the size of resource designer.

    EDIT : After 6 months of Android, I'm finally getting on this really unclear thing

  • VincentRicardVincentRicard USMember ✭✭

    @Tavrox Thank you for your input.
    Regardinging the layout IDs. Are you talking about layout for which you really need an ID (meaning you need the views in code-behind on in axml for placements via RelativeLayout) ? You did not mention that because by default all views/layouts have an ID. But why not remove the ids for those that is not needed ? Could it save some time too ?

    By the way, if you do not mind, do you also have the issue where editing an xml files cause the app to be uninstalled and all of its internal data lost ?

  • TavroxTavrox FRMember ✭✭

    I always remove the views/layouts that don't need an id, but sometimes I just need them for a specific thing like giving data in code. You can remove them if you don't need them :).

    I'm not sure I have the xml editing issue, by internal data do you mean storage with db or something else ? When you speak about editing the xml, it is during runtime ?
    About this, have you tried AndroidOptions (project click) > Projects > Android > preserve data/cache between application deploys

    I'll be trying the ID solution with specifying @/id instead of @+id/ on all my views, I'll keep you updated to know if it really changes something on memory management.

  • DanielVartdalDanielVartdal USMember ✭✭

    @VincentRicard on my last post. Building on Xamarin Studio does not seem to be any faster after all.

    But having code(for sharing) put on a class library (Android class library, both apps are android) just makes the build time (if it's possible) even worse!

    If I build for debug on a device, it will be quick as long as I don't do any changes. But if I change to another device (with the same code) and build to it, aapt suddenly goes crazy (100% cpu) and the build takes up to 2-5 minutes..

    Any input on this post @BrendanZagaeski @JamesMontemagno ?

  • VincentRicardVincentRicard USMember ✭✭

    Sorry I was unclear.

    Anytime you edit a XML file from your project the next debug you launch will have your app unstinalled.
    By default, this means any internal data (from /data/data/app_package/app_name/) will be lost forever.

    I know of the option you mentioned as it was mentioned in the first posts from this thread '^^
    I made sure it was enabled and it is. Nonetheless, the app is uninstalled AND the internal data is gone.

    In my application I ofently need to store data. So each time you attempt to write data with

    System.Environment.GetFolderPath(System.Environment.SpecialFolder.Personal) it goes to /data/data/app_package/app_name/files directory.

    My problem is that any data within this directoy is lost and gone each time I have edited a XML file or added a layout file ... well each time the Resource.Designer is rebuilt.

    Why ?

    @DanielVartdal I was looking to creat Android Library Classes to export most of my code-behind outside of my Android App because I created modules that needed in other projects. I am sad that this will extend my build time. Such a shame...

  • DanielVartdalDanielVartdal USMember ✭✭

    @VincentRicard It seems like I just have to go back having the code in my application solution. And when it's tested, put it in a class library..

    But I don't see any other way, happily for my project there are just minor layouting left, so build times won't affect me too much on layouts. But having slow builds adding just one line of code in the class library is hurting too much..

  • VincentRicardVincentRicard USMember ✭✭

    @DanielVartdal the workarounds you and I that we are using are bad practices in my opinion.

    I hope Xamarin will consider this issue...

  • DanielVartdalDanielVartdal USMember ✭✭

    @VincentRicard Indeed it is. I've also seen another issue.

    When building once when a device is connected. Building again with only code changes in the same solution = fast
    When building once when a device is connected, then connect another device. Building again(with no changes at all) = slow

    The same is when building the project on debug with no devices connected, and you then connect a device and do a build on the non-modified code.

  • VincentRicardVincentRicard USMember ✭✭

    @DanielVartdal I don't believe I ran into the same issues as you. I will git it a try.

    However I can confirm that if you change only code (cs files) from your Android Application project, the build is god damn fast even with lots of code change. Way faster than Android Studio.

    Did you check Android Application project -> options -> Android Buid -> General (Tab) -> Packaging & Deployment -> Use Shared Mono runtime. This should help build faster when changing only code, right ?

  • DanielVartdalDanielVartdal USMember ✭✭

    @VincentRicard I've tried both Shared Runtime and Fast deployment. Neither fixes this problem.

    It looks like changes triggered by either a layout change, or in my case, a change in a project that is referenced too by my application is re-building the whole project. And taking a lot more time then just a simple code change in your solution.

    The same issue happens when I change the debug/release switch and changing devices connected by USB.

  • DanielVartdalDanielVartdal USMember ✭✭

    @VincentRicard does your issue somehow look similar to this bug:

    It's reported almost one and a half year ago, and still status new. This one looks like it explains the issues I'm having.

  • lufo88lufo88 USMember ✭✭✭
    edited August 2015

    I guess the problem is the creation of the Resource.Designer.cs file. In fact every object created in xml file need a reference in this file and the only way in Xamarin to update that file is to rebuild the android project.

  • OMG, thank you so much for this gem.

        <AndroidExplicitCrunch>true</AndroidExplicitCrunch >

    I have a project with over 400 images, 115 layouts, and growing.
    Today this issue was so bad that I can't even add a single image to the project without visual studio crashing.
    After putting this in my project file, it's working again.

  • DanielVartdalDanielVartdal USMember ✭✭

    Glad it could help others @DerekYoussi :) I was walking on clouds when I got this working.

  • I have also horribly slow build, mainly because of resources (Why Xamarin.Android build resources every time i change small thing in cs file?)

    I've tried setting AndroidExplicitCrunch but build failed and got this result:

    C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1033,2): error MSB4018: The "CopyAndConvertResources" task failed unexpectedly.\r
    C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1033,2): error MSB4018: System.ArgumentException: An item with the same key has already been added.\r
    C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1033,2): error MSB4018: at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)\r
    C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1033,2): error MSB4018: at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)\r
    C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1033,2): error MSB4018: at Xamarin.Android.Tasks.CopyAndConvertResources.Execute()\r
    C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1033,2): error MSB4018: at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()\r
    C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1033,2): error MSB4018: at Microsoft.Build.BackEnd.TaskBuilder.d__26.MoveNext()

  • If I want to avoid rebuilding the app every time I deploy app to device, I use Xamarin Studio, not VS.

  • mohkhmohkh USMember

    after one and half year the bug exists :(
    thanks man for solution :blush:

  • DanielVartdalDanielVartdal USMember ✭✭

    glad it helped you @mohkh :)

  • gvsharmagorintagvsharmagorinta USMember ✭✭

    Still....2017 and xamarin app is taking so much time to edit xml resource files and each time rebuilding app is awkward and emabarssing....

  • Matt_PerleyMatt_Perley CAMember ✭✭

    @VincentRicard said:
    @DanielVartdal the workarounds you and I that we are using are bad practices in my opinion.

    I hope Xamarin will consider this issue...

    i have felt the same way since starting working with xamarin.
    at first it was like cool i can use c#? F*** Yaa! lol now i brace myself for the bugs.

    if programming wasnt such a masochist pleasure id have quit years ago xD

  • FelipeSouzaLongoFelipeSouzaLongo USMember ✭✭

    @DanielVartdal said:

    After e-mailing Xamarin support, they finally came up with a solution that worked for me. The problem was (from my tests) that having around 2000 resource-files(images) slowed the build incredible.

    Putting this propertygroup in the Xamarin Android project:

          <AndroidExplicitCrunch>true</AndroidExplicitCrunch >

    Made my day!

    Build times went from 2 minutes to 30 seconds on re-build of the project (triggered by xml updates etc)

    Thank you very much @DanielVartdal.
    This single line is a life saver indeed.

    Check this links as well, i think they have usefful tips.

  • DanielVartdalDanielVartdal USMember ✭✭

    Great to see it helped. Thanks for the links, I wil definitely check them out :)


    @FelipeSouzaLongo said:

    @DanielVartdal said:

    After e-mailing Xamarin support, they finally came up with a solution that worked for me. The problem was (from my tests) that having around 2000 resource-files(images) slowed the build incredible.

    Putting this propertygroup in the Xamarin Android project:

            <AndroidExplicitCrunch>true</AndroidExplicitCrunch >

    Made my day!

    Build times went from 2 minutes to 30 seconds on re-build of the project (triggered by xml updates etc)

    Thank you very much @DanielVartdal.
    This single line is a life saver indeed.

    Check this links as well, i think they have usefful tips.

Sign In or Register to comment.