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 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.
*** Bug 12045 has been marked as a duplicate of this bug. ***
Do you have a test case we can use to reproduce this?
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.
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.
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
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.
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.
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.
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.
*** Bug 12532 has been marked as a duplicate of this bug. ***
JonP: any ETA on a fix for this?
Eno: Please see Comment #6 and Comment #7.
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" .
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.
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.
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.
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.
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.
Binding projects no longer use the <MSBuild/> task as of monodroid/5bfddb16.
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.
=== 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)
=== 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 ===