Bug 57016 - Cannot build Xamarin.Android library project if an invalid/unrecognized device is attached over USB
Summary: Cannot build Xamarin.Android library project if an invalid/unrecognized devic...
Status: RESOLVED NORESPONSE
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: 7.3 (15.2)
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: dean.ellis
URL:
Depends on:
Blocks:
 
Reported: 2017-05-31 17:21 UTC by Dan Bishop
Modified: 2017-08-21 20:47 UTC (History)
3 users (show)

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

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:
Status:
RESOLVED NORESPONSE

Description Dan Bishop 2017-05-31 17:21:14 UTC
I have twice run into an issue where my Xamarin.Android library project fails to build due to an invalid/unrecognized device being attached over USB. The build just hangs indefinitely with no feedback on what is going on. 

Information on my setup:
- Visual Studio 2017 version 15.2 (26430.12)
- Xamarin version 4.5.0.476
- Xamarin.Android version 7.3.1.2
- I have both a Nexus 5 and Nexus 9 device that are connected over USB

Potential Repro steps:
- Attach Nexus 5 & Nexus 9 devices over USB
- Open Visual Studio and verify both devices appear in the debug targets dropdown list
- Put computer to sleep
- Wakeup computer
- Go to Visual Studio and verify that one or both of the Nexus 5/9 devices no longer appear in the dropdown list (I'm not sure how reproducible this is, but it is the behavior that I observed)
- Set the MSBuild log level to Diagnostic within VS2017
- Try to build the library project
- Verify that the build just hangs and never completes (it will stay this way forever if you let it)
- Cancel the build
- Check the MSBuild Diagnostic output for this detail (right near the end of the logs):
Done building target "_SetupDesignTimeBuildForIntellisense" in project "Gateway.Droid.Core.csproj".
Target "_GetPrimaryCpuAbi" in file "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Xamarin\Android\Xamarin.Android.Common.Debugging.targets" from project "D:\Dev\GatewayMobile\Src\Gateway.Droid.Core\Gateway.Droid.Core.csproj" (target "_CheckInstantRunCondition" depends on it):
Using "GetPrimaryCpuAbi" task from assembly "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Xamarin\Android\Xamarin.Android.Build.Debugging.Tasks.dll".
Task "GetPrimaryCpuAbi"
  Adb Task:
    AdbTarget: 
    AdbOptions: 
    DevicePropertyCache: obj\Debug\devices.cache
  Reading properties for 09a41f4002975bbe
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Xamarin\Android\Xamarin.Android.Common.Debugging.targets(311,2): warning : One or more errors occurred.
Done executing task "GetPrimaryCpuAbi".
Done building target "_GetPrimaryCpuAbi" in project "Gateway.Droid.Core.csproj" -- FAILED.

What I tried in my efforts to resolve/workaround this:
- Closing all instances of VS and re-opening
- Cleaning the solution
- Deleting the .suo
- Cloning the GitHub repo into a new folder and opening VS, then trying to build
- Uninstalling & re-installing the Xamarin SDK

What finally worked:
- Unplug the devices from the USB ports, and plug them back in

Ultimately, there was a simple way to workaround this, but figuring out that workaround was very time-consuming. Because I was only trying to *build* the solution (not debug or deploy), I never considered that the attached USB device could have affected the result.
Comment 1 Jon Douglas [MSFT] 2017-06-27 17:36:39 UTC
Sadly I cannot reproduce this. Typically `adb devices` seems to retain a connection through putting my computer to sleep. Thus these devices appear in the dropdown for Visual Studio as long as it's a Xamarin.Android project. An Xamarin.Android Library project however should not show these devices as they would be "Unsupported" because this is a library project and there's no deployment of the library unless it's referenced by an Xamarin.Android application project.

However this is not the first time I've seen an issue around the target _GetPrimaryCpuAbi". Basically in the _GetPrimaryCpuAbi target, there are calls to "adb" which you can further see in the "Adb" task that happens inside. This then goes far enough to find the primary cpu of each device that is connected. Really what should be happening for some of these cases is that we should explicitly give the architecture instead of going out using adb to retrieve it from each device. There are many situations where adb will fail such as devices no longer being connected...etc.

I am setting this bug to NEEDINFO as we will need reliable reproduction steps to CONFIRM this behavior. Although I'm familiar with this potential issue, we will need to address the severity of this issue as one could just ensure they replug their devices and ensure "adb devices" has those items inside. Potentially sleeping a machine could disconnect those devices when attempting to build again.

If you have a reliable reproduction project or steps that I can follow, please add them as a comment. I had already tried the "Potential repo steps" to no avail. Thank you for your time reporting this issue!
Comment 2 Jon Douglas [MSFT] 2017-08-21 20:47:50 UTC
Because we have not received a reply to our request for more information we are closing this issue. If you are still encountering this issue, please reopen the ticket with the requested information. Thanks!