Bug 58561 - VS2017 - Xamarin.Android project "Start without debugging" taking almost 1 minute even without code change
Summary: VS2017 - Xamarin.Android project "Start without debugging" taking almost 1 mi...
Status: RESOLVED DUPLICATE of bug 58865
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: 8.0 (15.4)
Hardware: PC Windows
: High normal
Target Milestone: 15.5
Assignee: dean.ellis
Depends on:
Reported: 2017-08-03 09:54 UTC by Michal Dobrodenka
Modified: 2017-10-09 13:47 UTC (History)
4 users (show)

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

Detailed build log. (139.38 KB, text/plain)
2017-08-03 09:54 UTC, Michal Dobrodenka
Diagnostic build log (597.66 KB, application/x-zip-compressed)
2017-08-03 15:42 UTC, Michal Dobrodenka
Diagnostic build log with timing (676.89 KB, application/x-zip-compressed)
2017-08-03 15:55 UTC, Michal Dobrodenka
Deployt after build with XA 8.0.33 (551.64 KB, application/x-zip-compressed)
2017-10-05 09:45 UTC, Michal Dobrodenka
deploy log with <BuildingInsideVisualStudio>true</BuildingInsideVisualStudio> (623.97 KB, application/x-zip-compressed)
2017-10-09 11:58 UTC, Michal Dobrodenka
csproj file (17.87 KB, application/x-zip-compressed)
2017-10-09 11:59 UTC, Michal Dobrodenka

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 Michal Dobrodenka 2017-08-03 09:54:47 UTC
Created attachment 23999 [details]
Detailed build log.

Every time when I want to run applciation from VS2017 it takes a long time. Even when I made no changes. I have even Improved fast deployment on. Why is it processing so many resources?

1>  Processing: obj\Debug\res\drawable\detail_icon15.xml
1>  Processing: obj\Debug\res\drawable\detail_icon17.xml
1>  Processing: obj\Debug\res\drawable\detail_icon18.xml

Every nuget date is older than "now".

Attaching build log from deploy without any change. On Xamarin.Studio deploy is almost instant in this case.
Comment 1 Jon Douglas [MSFT] 2017-08-03 15:32:13 UTC
To get a better idea of how long the build is taking, can you please attach a "Diagnostic Build Output"? It seems this build was only set to "Detailed".


This will include items such as MSBuild Task timings which we would be interested in to see how long respective Tasks are taking in the build process.

Thank you!
Comment 2 Michal Dobrodenka 2017-08-03 15:42:33 UTC
Created attachment 24011 [details]
Diagnostic build log
Comment 3 Michal Dobrodenka 2017-08-03 15:44:43 UTC
Attaching diagnostic build log. I don't know why, I can't see tasks timing.
Comment 4 Jon Douglas [MSFT] 2017-08-03 15:49:38 UTC
Attempt to just build your project and not deploy it. It should contain the timing information that way.
Comment 5 Michal Dobrodenka 2017-08-03 15:55:49 UTC
Created attachment 24012 [details]
Diagnostic build log with timing
Comment 6 Jon Douglas [MSFT] 2017-08-21 22:08:32 UTC
Just ballparking based on the Task timing, it looks like this build in particular took about ~47 seconds. There was a recent enhancement added for _UpdateAndroidResGen:


You should be able to get an Alpha build this week with this fix in it to see if this helps build timing at all. If not, we should refer to Dean Ellis (Assigned this bug) to look further into this.

I'm not sure if your project has many library projects referenced, but it never hurts to try:


Finally, it would be a very good idea to include a binary log using (msbuild.exe /bl) to this post. You can find details for how to get one here:


Thank you!
Comment 7 Jonathan Pryor 2017-08-28 17:27:22 UTC
I suspect that this is related to Bug #58865, which is also fixed xamarin-android/master, but not d15-4.

Reading Attachment #24012 [details], the biggest problem is `_CompileJava` and `_CompileToDalvikWithDx`:

1>    13334 ms  _CompileToDalvikWithDx                     1 calls
1>    15321 ms  _CompileJava                               1 calls

Those are responsible for ~28s of execution, and *because* they run the entire .apk will need to be rebuilt and redeployed.

`_CompileToDalvikWithDx` runs because `_CompileJava` ran.

`_CompileJava` runs because:

>Target "_CompileJava: (TargetId:149)" in file "C:\Program Files (x86)\Microsoft Visual Studio\Preview\Community\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets" from project "C:\work\taphome\TapHome.Android\TapHome.Android.csproj" (target "_FindCompiledJavaFiles" depends on it):
>Building target "_CompileJava" completely.
>Input file "obj\Debug\android\src\\md5041e9719878e964dc8182d13a2656f18\CommonUIFrame.java" is newer than output file "obj\Debug\_javac.stamp".

`CommonUIFrame.java` in turn should be created by the `<GenerateJavaStubs/>` task:

>Target "_GenerateJavaStubs: (TargetId:139)" in file "C:\Program Files (x86)\Microsoft Visual Studio\Preview\Community\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets" from project "C:\work\taphome\TapHome.Android\TapHome.Android.csproj" (target "_GetAddOnPlatformLibraries" depends on it):
>Building target "_GenerateJavaStubs" completely.
>Input file "obj\Debug\android\assets\TapHome.Android.dll" is newer than output file "obj\Debug\android\typemap.jm".

What updated `TapHome.Android.dll`? It was rebuilt:

>Target "CoreCompile: (TargetId:96)" in file "C:\Program Files (x86)\Microsoft Visual Studio\Preview\Community\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets" from project "C:\work\taphome\TapHome.Android\TapHome.Android.csproj" (target "Compile" depends on it):
>Building target "CoreCompile" completely.
>Input file "..\TapHome.Commons\FormatValue.cs" is newer than output file "obj\Debug\TapHome.Android.dll".

That sounds decidedly weird; Comment #0 says "no changes," yet the `CoreCompile` target says "files changed".

In fact, that's the very first line of Attachment #24012 [details]!

>Project 'TapHome.Android' is not up to date. Input file 'c:\work\taphome\taphome.commons\formatvalue.cs' is modified after output file ''.

@Michal: Is this *actually* a "no changes" build? Is it possible that "something" is touching `TapHome.Commons\FormatValue.cs`?

All that said -- and the `FormatValue.cs` issue should be investigated further -- rebuilding `TapHome.Android.dll` shouldn't matter *that* much: `<GenerateJavaStubs/>` shouldn't update `.java` timestamps unless the content has changed. This is why Bug #58865 looks like the actual culprit to me:

>Target "_CreateBaseApk: (TargetId:146)" in file "C:\Program Files (x86)\Microsoft Visual Studio\Preview\Community\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets" from project "C:\work\taphome\TapHome.Android\TapHome.Android.csproj" (target "_CompileJava" depends on it):
>Building target "_CreateBaseApk" completely.
>Input file "obj\Debug\android\AndroidManifest.xml" is newer than output file "obj\Debug\android\bin\packaged_resources".

That's the same symptom as Bug #58865: `AndroidManifest.xml` is *always* instead, which causes the `.apk` to always be rebuilt, which -- I *think* -- is what's causing the .java to be rebuilt in the first place.

*** This bug has been marked as a duplicate of bug 58865 ***
Comment 8 Michal Dobrodenka 2017-10-05 09:44:08 UTC
VS2017 15.4 Preview 4,Visual Studio Tools for Xamarin & Xamarin.Android

Build without code change is now instant. 

But when I want to deploy it, it takes at least 1 minute and it is rebuilding. Attaching new log. 

- Without any code change - closed all windows.
- Rebuild.
- Deploy - 1 minute
Comment 9 Michal Dobrodenka 2017-10-05 09:45:19 UTC
Created attachment 25119 [details]
Deployt after build with XA 8.0.33
Comment 10 dean.ellis 2017-10-05 11:42:30 UTC

Looks like the Csc is being called. 

"1>Building target "CoreCompile" completely.
1>Output file "__NonExistentSubDir__\__NonExistentFile__" does not exist."

This is usually when `BuildingInsideVisualStudio` is not set. 
Which should be set by Visual Studio itself....
Comment 11 Michal Dobrodenka 2017-10-05 15:38:21 UTC

And how to set it? What should I do with it?

Would it help to create project file from scratch and add files?
Comment 12 dean.ellis 2017-10-09 09:43:30 UTC
@Michal, `BuildingInsideVisualStudio` should be set by VS.. that said you could work around the problem by adding it to your project 


That might force the issue. One a side note we have been unable to replicate this issue here. Do you have a sample which we could use to replicate the problem?
Comment 13 Michal Dobrodenka 2017-10-09 11:57:52 UTC

Unfortunately, it didn't help. Attaching build log with 


in project.

Will also attach csproj file.
Comment 14 Michal Dobrodenka 2017-10-09 11:58:24 UTC
Created attachment 25221 [details]
deploy log with  <BuildingInsideVisualStudio>true</BuildingInsideVisualStudio>
Comment 15 Michal Dobrodenka 2017-10-09 11:59:52 UTC
Created attachment 25222 [details]
csproj file
Comment 16 dean.ellis 2017-10-09 13:47:16 UTC

you are hitting [1]. The `__NonExistentSubDir__\__NonExistentFile__` will trigger the CoreCompile task to always run :(

I guess try


I have no idea how that will effect things in the IDE though.

[1] https://github.com/Microsoft/msbuild/blob/5df95761c73cd6b1b2c35a827ed168e32546388e/src/Tasks/Microsoft.Common.CurrentVersion.targets#L3355