Bug 15162 - Rebuild entire solution upon rerun
Summary: Rebuild entire solution upon rerun
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: 4.8.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: Jonathan Pryor
: 12584 ()
Depends on:
Reported: 2013-10-03 07:01 UTC by Andrei
Modified: 2013-11-20 10:22 UTC (History)
3 users (show)

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

First build (5.69 MB, text/plain)
2013-10-03 10:30 UTC, Andrei
Second build (5.65 MB, text/plain)
2013-10-03 10:31 UTC, Andrei
Test application build (39.43 KB, application/x-gzip)
2013-10-03 10:46 UTC, Andrei

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 Andrei 2013-10-03 07:01:51 UTC
The Xamarin Studio rebuilds entire Android solution when run. 
Steps to reproduce:
1. Create a new Android project.
2. Create a new Android Library project.
3. Add a reference from the Android project to the Library project.
4. Run the Android project (it builds the solution)
5. Run the Android project again (it rebuilds the solution).

The solution should not be rebuilt as it is up-to-date. In the build output I see lots of stuff, including this:

				Tool /Library/Frameworks/Xamarin.Android.framework/Versions/Current/bin/smcs execution started with arguments: /noconfig /debug:full /debug+ /optimize- /out:obj/Debug/TestLib.dll /resource:obj/Debug/TestLib.obj.Debug.__AndroidLibraryProjects__.zip,__AndroidLibraryProjects__.zip Resources/Resource.designer.cs TestClass.cs /target:library /define:"DEBUG;__MOBILE__;__ANDROID__;__ANDROID_1__;__ANDROID_2__;__ANDROID_3__;__ANDROID_4__;__ANDROID_5__;__ANDROID_6__;__ANDROID_7__;__ANDROID_8__" /reference:/Library/Frameworks/Xamarin.Android.framework/Versions/Current/lib/mono/2.1/System.dll /reference:/Library/Frameworks/Xamarin.Android.framework/Versions/Current/lib/mono/2.1/System.Xml.dll /reference:/Library/Frameworks/Xamarin.Android.framework/Versions/Current/lib/mandroid/platforms/android-8/Mono.Android.dll /reference:/Library/Frameworks/Xamarin.Android.framework/Versions/Current/lib/mono/2.1/System.Core.dll /warn:4

So, the compiler is run for the test library whilst its output is up-to-date. 

This bug is not important for small projects, but on real projects it takes about 2 minutes for complete rebuild.
Comment 1 Andrei 2013-10-03 07:03:53 UTC
My versions of Xamarin Studio and Android are current in Stable update channel:
Xamarin Studio
Version 4.0.12 (build 3)
Installation UUID: 5541daf3-8e76-4b33-b486-fecce6a7229d
	Mono 3.2.3 ((no/8d3b4b7)
	GTK 2.24.20
	GTK# (
	Package version: 302030000
Version: 4.8.1 (Business Edition)
Android SDK: /Users/andrei/Library/Developer/Xamarin/android-sdk-mac_x86
	Supported Android versions:
		2.1   (API level 7)
		2.2   (API level 8)
		2.3   (API level 10)
		3.1   (API level 12)
		4.0   (API level 14)
		4.0.3 (API level 15)
		4.2   (API level 17)
Java SDK: /usr
java version "1.6.0_51"
Java(TM) SE Runtime Environment (build 1.6.0_51-b11-457-11M4509)
Java HotSpot(TM) 64-Bit Server VM (build 20.51-b01-457, mixed mode)
Comment 2 Jonathan Pryor 2013-10-03 10:12:44 UTC
Does this happen with `xbuild` as well or just within Xamarin Studio?

For example, within Terminal.app:

    $ cd path/to/solution
    $ time xbuild Solution.sln /v:diag > build-1.txt
    $ time xbuild Solution.sln /v:diag > build-2.txt

If nothing has changed, the 2nd xbuild invocation shouldn't take long (it won't be instantaneous, but it should be only a few seconds...I hope).

If the 2nd xbuild invocation isn't fast, this isn't a Xamarin Studio bug; please attach the build-*.txt files.
Comment 3 Andrei 2013-10-03 10:30:13 UTC
Created attachment 5051 [details]
First build
Comment 4 Andrei 2013-10-03 10:31:33 UTC
Created attachment 5052 [details]
Second build

The build is run immediately after the first build succeeded.
Comment 5 Andrei 2013-10-03 10:34:07 UTC
$ time xbuild STA.Mono.Android/STA.Mono.Android.sln /v:diag > build-1.txt

real	2m21.829s
user	1m40.324s
sys	0m11.791s
$ time xbuild STA.Mono.Android/STA.Mono.Android.sln /v:diag > build-2.txt

real	1m19.209s
user	0m48.015s
sys	0m7.405s

So, after all, it is faster, but not by much. So I assume it is a bug in xbuild. Or maybe I have misconfigured projects?
Comment 6 Andrei 2013-10-03 10:44:51 UTC
I have built the real project. 
Now I have tested it with test application I've described in the bug. Even worse:
$ touch TestApplication/MainActivity.cs 
$ touch TestLib/TestClass.cs 
$ time xbuild TestApplication.sln /v:diag > build-1.txt

real	0m6.810s
user	0m5.922s
sys	0m0.762s
$ time xbuild TestApplication.sln /v:diag > build-2.txt

real	0m6.205s
user	0m5.035s
sys	0m0.696s

I will attach the build files.
Comment 7 Andrei 2013-10-03 10:46:18 UTC
Created attachment 5053 [details]
Test application build

build-1.txt is run after changes in files, build-2.txt is run immediately after.
Comment 8 Jonathan Pryor 2013-10-03 11:52:24 UTC
Looking at Attachment #5052 [details], this is interesting:

>		Target CoreCompile needs to be built as input file 'obj/Debug/STA.CommonClasses.obj.Debug.__AndroidLibraryProjects__.zip' is newer than output file 'obj/Debug/STA.CommonClasses.Android.dll'

Since you're rebuilding a .dll, everything that depends on the .dll needs to be rebuilt, contributing to the build time.

So why is obj/Debug/STA.CommonClasses.obj.Debug.__AndroidLibraryProjects__.zip newer than obj/Debug/STA.CommonClasses.Android.dll?

> 			Task "Copy"
> 				Using task Copy from Microsoft.Build.Tasks.Copy, Microsoft.Build.Tasks.v4.0, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
> 				Copying file from '/Users/andrei/svyaznoy/STA.CommonClasses/obj/Debug/__AndroidLibraryProjects__.zip' to '/Users/andrei/svyaznoy/STA.CommonClasses/obj/Debug/STA.CommonClasses.obj.Debug.__AndroidLibraryProjects__.zip'
> 			Done executing task "Copy"
> 			Done building target "CopyNonResxEmbeddedResources" in project "/Users/andrei/svyaznoy/STA.CommonClasses/STA.CommonClasses.Android.csproj".

STA.CommonClasses.obj.Debug.__AndroidLibraryProjects__.zip is newer because it's always copied, and thus will always have an updated timestamp, thus requiring that STA.CommonClasses.Android.dll always be rebuilt, etc., etc., and everyone is sad.

...continue digging, and:

> 			Task "CreateManagedLibraryResourceArchive"
> 				Using task CreateManagedLibraryResourceArchive from Xamarin.Android.Tasks.CreateManagedLibraryResourceArchive, Xamarin.Android.Build.Tasks, Version=, Culture=neutral, PublicKeyToken=null
> 				CreateManagedLibraryResourceArchive Task
> 				  OutputDirectory: obj/Debug/library_project_imports
> 				  AndroidAssets:
> 				  ResourceDirectory: obj/Debug/res/
> 				  AndroidJavaSources:
> 				  AndroidJavaLibraries:
> 				writing __res_name_case_map.txt...
> 				Saving contents to /Users/andrei/svyaznoy/STA.CommonClasses/obj/Debug/__AndroidLibraryProjects__.zip
> 			Done executing task "CreateManagedLibraryResourceArchive"

which is the REAL problem: the CreateManagedLibraryResourceArchive task ALWAYS regenerates __AndroidLibraryProjects__.zip.

Comment 9 Jonathan Pryor 2013-10-03 13:08:01 UTC
Fixed in monodroid/c909129e.
Comment 10 Jonathan Pryor 2013-11-20 10:22:56 UTC
*** Bug 12584 has been marked as a duplicate of this bug. ***