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 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.
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.
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.
Created attachment 24011 [details]
Diagnostic build log
Attaching diagnostic build log. I don't know why, I can't see tasks timing.
Attempt to just build your project and not deploy it. It should contain the timing information that way.
Created attachment 24012 [details]
Diagnostic build log with timing
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:
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 ***
VS2017 15.4 Preview 4,Visual Studio Tools for Xamarin 220.127.116.11 & Xamarin.Android 18.104.22.168
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.
- Deploy - 1 minute
Created attachment 25119 [details]
Deployt after build with XA 8.0.33
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....
And how to set it? What should I do with it?
Would it help to create project file from scratch and add files?
@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?
Unfortunately, it didn't help. Attaching build log with
Will also attach csproj file.
Created attachment 25221 [details]
deploy log with <BuildingInsideVisualStudio>true</BuildingInsideVisualStudio>
Created attachment 25222 [details]
you are hitting . 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.