Created attachment 3420 [details]
Example project for reproducing this issue
Over the last couple of days I was getting some weird errors when compiling a MfA solution (Visual Studio 2012, MfA 4.4.55):
The type of namespace name 'XXX' could not be found (are you missing a using directive or an assembly reference?)
The weird thing was that the error only occurred randomly. Once it occurred, I just had to build the solution again (without any changes) and the error would disappear. (There is no actual error but the compiler complains anyway.)
Today, I decided to track down the problem. Before I get into the details, here's a video of the problem:
I found out that the problem only occurred after packaging a project (using "Build" -> "Package ProjectName for Android (.apk)").
So I trimmed down my solution and attached it to this report.
To reproduce the error (see video):
1. Open solution ResourceErrorsAfterPackaging.sln
2. Set "StepDetector" as startup project
3. Build the solution
4. Package the "StepDetector" project (using "Build" -> "Package StepDetector for Android (.apk)")
5. Make a small change to "MainActivity.cs" in "StepDetector", so that VS thinks it needs to compile the StepDetector project
6. Build the solution (using "Build" -> "Build Solution"; don't use "Rebuild Solution").
7. Repeat steps 5 and 6 a couple of times (2 - 5) to trigger the error. If it doesn't occur, first do step 4 again, and then repeat steps 5 and 6.
I think the cause is (somehow) that the project "Commons.MonoDroid" is referenced in all other projects.
Here are the ways I found to make the error disappear (in the example solution):
* Remove the "DebugInfoExchangeProtocol.MonoDroid" project from the solution. Note that the library project "DebugInfoExchangeProtocol.MonoDroid" is not referenced by the "StepDetector" project (or any other project).
* Remove any of the existing project references.
* Move the "Commons.MonoDroid" project from "<solutiondir>/commonslib/monodroid" to "<solutiondir>/commons".
I also noted that the error is easier to trigger the more projects (and references?) you have in your solution. On my original solution, I can trigger the error every time (unlike the example solution attached to this post).
Vinicious: This looks like a race condition. We suspect someone is using Threads or the TPL to perform some tasks, and this is why it randomly fails when building.
Definitely didn't make it into 4.8.3, and Vinicius is consumed right now with 4.10.1 and 1.8 issues. Perhaps this could be re-assigned to Dean.
I've managed to replicate this issue.
The output from the msbuild job is at https://gist.github.com/dellis1972/d4b4b3346f881f848334
gonna start looking into why this is happening.
looks like the MapLocation.MonoDroid is loosing its reference to Commons.MonoDroid
This has been fixed in XamarinVS/master/3b86509eb4
The problem seems to have been caused by the Android extension shelling out to msbuild to do the deployment and packaging instead of using the internal MSbuild engine within visual studio.
Moving the deployment and packaging to use the internal engine resolves the issue, the example provided now builds correctly with the fix.
This fix should be in the 1.12 release.
Sebastian it would be helpful for us to be able to include the sample you provided in our unit tests, can we have your permission to do so please?
Guess you meant the 4.12 release?
No, he meant the 1.12 release. Our version numbers are...confusing. :-/
In this case, he means "Visual Studio plugin v1.12". The Visual Studio plugin is in turn included within Xamarin.Android and Xamarin.iOS (for now...), and (depending on timing) will either be included in XA 4.12 or be punted until XA 4.14.
Hi Jonathan, thanks for clarification - I want to try to enable parallel builds after you release the fix, so clear evidence which version will contain the solution is quite useful to me ;-)
I have checked this issue with following builds:
I have followed all steps. I am not able to reproduce this issue.
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 Links.
Create a new report for Bug 10433 on Developer
Community or GitHub if you have new information to add and do not yet see a matching
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
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.