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

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


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

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
Runtime:
	Mono 3.2.3 ((no/8d3b4b7)
	GTK 2.24.20
	GTK# (2.12.0.0)
	Package version: 302030000
Xamarin.Android
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=4.0.0.0, 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=1.0.0.0, 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.

Oops.
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. ***

Note You need to log in before you can comment on or make changes to this bug.