Bug 11846 - Some warnings can't find its source file
Summary: Some warnings can't find its source file
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: 4.6.x
Hardware: PC Windows
: High normal
Target Milestone: ---
Assignee: Radek Doulik
: 12045 12532 ()
Depends on:
Reported: 2013-04-18 08:18 UTC by Peter Hultqvist
Modified: 2014-06-04 09:02 UTC (History)
9 users (show)

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

Screenshot of the "Can't find file" error message. (60.49 KB, image/png)
2013-04-18 08:18 UTC, Peter Hultqvist
Solution with two projects (15.04 KB, application/zip)
2013-05-01 03:10 UTC, Peter Hultqvist

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 Peter Hultqvist 2013-04-18 08:18:17 UTC
Created attachment 3829 [details]
Screenshot of the "Can't find file" error message.

My solution finished compilation with one error in a commonly used library project.

Problem 1: the warning is repeated multiple times, probably the same number of time the library is referenced.

Problem 2: When trying to go to the line of the error it says it cannot find the file.(See screenshot)
Though the file is there, I can open it manually and find the cause at line 83 as stated by the warning.
Comment 1 Mikayla Hutchinson [MSFT] 2013-04-30 16:28:55 UTC
*** Bug 12045 has been marked as a duplicate of this bug. ***
Comment 2 Mikayla Hutchinson [MSFT] 2013-04-30 16:29:29 UTC
Do you have a test case we can use to reproduce this?
Comment 4 Peter Hultqvist 2013-05-01 03:10:44 UTC
Created attachment 3901 [details]
Solution with two projects

I guess Jesse beat me to it, but here is another one.
One android project referencing one android library in which the warning is.
Two warning lines appear of which only one works, the other trigger the bug.

I couldn't repeat this on the master branch since android projects are not supported there,
but creating a similar console project and library with a warning did not trigger the bug.
Comment 5 Mikayla Hutchinson [MSFT] 2013-05-01 16:25:52 UTC
Okay, I really don't know for sure where to assign this bug. It seems to be a combination of problems.

This is a problem for Android projects but not other project, because only Android projects use the MSBuild engine by default, and it's a problem either with our MSBuild integration, with xbuild, or with the Android targets. Or possibly all of them.

The reason we get "file not found" is because XS gets back a project relative path from the MSBuild engine, and combines it with the base location of the project file. However, if the project implicitly builds a referenced project, and the is error comes from that referenced project, the the combined path that XS constructs is wrong.

The reason we get the errors multiple times is that the referenced project is being built multiple times. Projects are not supposed to build referenced projects, since they'll already have been built by the sln container. This is a bigger problem, since it slows the build and results in duplicate errors. And if we could fix this, then the first problem would go away.
Comment 6 Mikayla Hutchinson [MSFT] 2013-05-01 16:52:14 UTC
I initially assigned this to Android, because I can reproduce the problem with android projects in XS in Windows, i.e. using MSBuild not xbuild, but I cannot reproduce it with normal .NET projects in XS on Windows using MSBuild. This implies it's specific to the Android targets.

For some reason the Android targets seems to be hitting some _BuildDependencies target that's not hit in the normal .NET project.

When building the project in VS or commandline MSBuild, it still hits the _BuildDependencies target but prints "Resolved library outputs" instead of invoking the build target. I suspect VS and the MSBuild solution build have some special override of the _BuildDependencies to improve situations like this.

So we could improve the _BuildDependencies in XS by implementing the "Resolved library outputs" behavior in the XS msbuild runner , but something strange is going on with the Android targets given this doesn't happen with normal .NET projects.

XS on mac building a normal .NET project with the xbuild engine works the same way as XS+MSBuild i.e it does not invoke _BuildDependencies.

I can reproduce the problem in commandline xbuild on Mac and XS on Mac. They both appear to behave the same way as XS on Windows, i.e. the _BuildDependencies target re-builds the referenced project. So command-line xbuild project could use the same "Resolved library outputs" improvement.

So I think there are four things to fix here:
1) make XS pick up the correct files paths for errors from referenced projects
2) make XS override the _BuildDependencies target like VS and MSBuild sln build do 
3) make xbuild sln build override the _BuildDependencies the same way
4) make the android targets avoid triggering _BuildDependencies
Comment 7 Mikayla Hutchinson [MSFT] 2013-05-01 17:04:19 UTC
Huh. So _BuildDependencies is part of the Xamarin.Android.Common.targets and they EXPLICTLY invoke Build on all the referenced projects:
<MSBuild Projects="@(ProjectReference)" Targets="Build">

So I'm guessing the VS and MSBuild solution hosts have special handling for the MSBuild task.

But the Xamarin.Android targets really shouldn't be doing this. Building dependencies is supposed to be handled by the sln container. This appears to have been introduced by the fix for bug 10078.
Comment 8 Mikayla Hutchinson [MSFT] 2013-05-01 17:07:32 UTC
To clarify, #1 and #2 are XS issues, and #3 is an xbuild issue, but they're all very minor. The big issue is #4 which is in the android targets.
Comment 9 Mikayla Hutchinson [MSFT] 2013-05-01 17:13:32 UTC
Regarding #2 and #3, I suspect what VS and MSBuild are doing is making the MSBuild task caching and returning the result of previous invocations of the Target during the current build.

From MSDN:
Unlike using the Exec Task to start MSBuild.exe, this task uses the same MSBuild process to build the child projects. The list of already-built targets that can be skipped is shared between the parent and child builds. This task is also faster because no new MSBuild process is created.

So I guess if we fixed this we could skip fixing #4. But I'm still suspicious of #4. Re-implementing project dependencies seems suspect.
Comment 10 Mikayla Hutchinson [MSFT] 2013-06-17 20:23:51 UTC
*** Bug 12532 has been marked as a duplicate of this bug. ***
Comment 11 Mikayla Hutchinson [MSFT] 2013-06-17 20:24:34 UTC
JonP: any ETA on a fix for this?
Comment 12 Jonathan Pryor 2013-06-18 15:16:50 UTC
Eno: Please see Comment #6 and Comment #7.
Comment 13 Atsushi Eno 2013-06-19 01:24:02 UTC
hutch: I don't understand the claim on comment #7. IF anyone shouldn't *use* <MSBuild /> task, then what is the purpose of this task for? Also I don't see any reason why "Building dependencies is supposed to be handled by the sln container" .
Comment 14 Mikayla Hutchinson [MSFT] 2013-06-19 13:01:11 UTC
That argument doesn't make sense. Just because you have something doesn't mean there aren't right and wrong ways to use it e.g. you shouldn't use the Delete task on every file in the user's project :)

Yes, there appear to be bugs in issues with invoking the MSBuild task from XS on Windows. But you shouldn't be doing it in this case.

When you build a solution, the solution build takes care of ensuring that referenced projects are built before the projects that reference them. This means that projects do not need to build their references. By building the references you are slowing down the build and making the build log harder to follow. Consider if you have 3 projects, A, B and C, and A references B and C, and B references C, then A will be built once, B will be built twice, and C will be built 3 times. That's twice as many builds as necessary. And it gets much worse with larger projects.

This is not a problem in VS/MSBuild because the VS solution builder somehow hijacks the MSBuild task and skips them if it's already run them. But that's not something we're going to do in MD any time soon.
Comment 15 Atsushi Eno 2013-06-19 23:41:38 UTC
Of course there is reason we needed to use <MSBuild/>. We must not remove that MSBuild task because it brings more disasterous regressions about bug #10078 on how to deal with resources. Your reasoning is only talking about the *ideal* build process, which cannot surpass the benefit of fixing that bug. As long as the use of <MSBuild/> is legal, regardless of it is not ideal or not, it should be xbuild or XS side that needs fix, and it's more reasonable.
Comment 16 Mikayla Hutchinson [MSFT] 2013-06-20 13:23:48 UTC
Here's a suggestion. It's not perfect, it wouldn't fix bug 8425, but it would fix this and bug 12532.

1) Remove all DependsOn=_BuildDependencies from the current targets
2) Rename UpdateAndroidResources to _UpdateAndroidResources
3) Introduce a new <Target Name="UpdateAndroidResources" DependsOn="_BuildDependencies;_UpdateAndroidResources" />

So dependencies would only be built when the IDE directly invoked UpdateAndroidResources.
Comment 17 Mikayla Hutchinson [MSFT] 2013-06-20 14:16:17 UTC
Note: one definite problem with _BuildDependencies is that it does not take solution->project configuration mappings into account, so it may build the incorrect project configurations.
Comment 18 Jonathan Pryor 2014-03-06 12:31:17 UTC
I suspect that the fix for Bug #16589 also fixed this, as the _BuildDependencies target has been removed and the <MSBuild/> task is no longer used in Xamarin.Android.Common.targets.

Binding projects still use the <MSBuild/> task though.
Comment 19 Jonathan Pryor 2014-05-29 16:09:38 UTC
Binding projects no longer use the <MSBuild/> task as of monodroid/5bfddb16.
Comment 20 Mohit Kheterpal 2014-06-04 09:02:39 UTC
I have checked this issue and this issue does not exist while running attached project in comment 3 as shown in screencast : http://screencast.com/t/8oUQFlBxIVj

Hence closing this issue.

Environment info:
=== Xamarin Studio ===

Version 5.1 (build 302)
Installation UUID: 3b924754-5196-440a-b42b-05ebb3a3082e
	Microsoft .NET 4.0.30319.18408
	GTK+ 2.24.22 (MS-Windows theme)
	GTK# 2.12.25

=== Xamarin.Android ===

Version: 4.15.0 (Enterprise Edition)
Android SDK: E:\AndroidSDK
	Supported Android versions:
		1.6   (API level 4)
		2.1   (API level 7)
		2.2   (API level 8)
		2.3   (API level 10)
		3.1   (API level 12)
		3.2   (API level 13)
		4.0   (API level 14)
		4.0.3 (API level 15)
		4.1   (API level 16)
		4.2   (API level 17)
		4.3   (API level 18)
		4.4   (API level 19)
Java SDK: C:\Program Files\Java\jdk1.6.0_31
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing)

=== Build Information ===

Release ID: 501000302
Git revision: 37edec4110ed93f02581f1331d2ff5b38f9a3aa9
Build date: 2014-05-30 12:45:30-04
Xamarin addins: b4105598b2afb41dac2f91a523ce94dbb3f1efdf

=== Operating System ===

Windows 6.1.7601.65536