This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 42168 - A numeric comparison was attempted on "$(_DeviceSdkVersion)" that evaluates to "" instead of a number, in condition "$(_DeviceSdkVersion) >= 21".
Summary: A numeric comparison was attempted on "$(_DeviceSdkVersion)" that evaluates t...
Alias: None
Product: Android
Classification: Xamarin
Component: General (show other bugs)
Version: 6.1.0 (C7)
Hardware: PC Windows
: High critical
Target Milestone: 7.0 (C8)
Assignee: dean.ellis
Depends on:
Reported: 2016-06-25 03:45 UTC by Cody Beyer (MSFT)
Modified: 2016-08-03 18:50 UTC (History)
9 users (show)

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


Description Cody Beyer (MSFT) 2016-06-25 03:45:01 UTC
# Description

When attempting to deploy a test app from Visual Studio to Android, the following error is thrown:

>A numeric comparison was attempted on "$(_DeviceSdkVersion)" that evaluates to "" instead of a number, in condition "$(_DeviceSdkVersion) >= 21".

# Build Logs

# Steps to Reproduce

	1. Create blank Android app
	2. Attempt to deploy to Android emulator or device

# SDK Versions

Android SDK Tools: 25.1.7
Android SDK Platform-tools: 24
Android SDK Build-tools: 23.0.3

# Versions

Microsoft Visual Studio Professional 2015
Version 14.0.25123.00 Update 2
Microsoft .NET Framework
Version 4.6.01584

Installed Version: Professional

LightSwitch for Visual Studio 2015   00322-40000-00000-AA193
Microsoft LightSwitch for Visual Studio 2015

Visual Basic 2015   00322-40000-00000-AA193
Microsoft Visual Basic 2015

Visual C# 2015   00322-40000-00000-AA193
Microsoft Visual C# 2015

Visual C++ 2015   00322-40000-00000-AA193
Microsoft Visual C++ 2015

Visual F# 2015   00322-40000-00000-AA193
Microsoft Visual F# 2015

Windows Phone SDK 8.0 - ENU   00322-40000-00000-AA193
Windows Phone SDK 8.0 - ENU

Application Insights Tools for Visual Studio Package   5.2.60328.3
Application Insights Tools for Visual Studio

ASP.NET and Web Tools 2015.1 (Beta8)   14.1.11106.0
ASP.NET and Web Tools 2015.1 (Beta8)

ASP.NET Web Frameworks and Tools 2012.2   4.1.41102.0
For additional information, visit

ASP.NET Web Frameworks and Tools 2013   5.2.40314.0
For additional information, visit

Common Azure Tools   1.7
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

JavaScript Language Service   2.0
JavaScript Language Service

JavaScript Project System   2.0
JavaScript Project System

Microsoft Azure Mobile Services Tools   1.4
Microsoft Azure Mobile Services Tools

NuGet Package Manager   3.4.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit

PreEmptive Analytics Visualizer   1.2
Microsoft Visual Studio extension to visualize aggregated summaries from the PreEmptive Analytics product.

SQL Server Data Tools   14.0.60311.1
Microsoft SQL Server Data Tools

TypeScript tools for Visual Studio

Visual Studio Tools for Universal Windows Apps   14.0.25219.00
The Visual Studio Tools for Universal Windows apps allow you to build a single universal app experience that can reach every device running Windows 10: phone, tablet, PC, and more. It includes the Microsoft Windows 10 Software Development Kit.

Xamarin (34a92cd)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin.Android (7db2aac)
Visual Studio extension to enable development for Xamarin.Android.

Xamarin.iOS (3cf8aae)
Visual Studio extension to enable development for Xamarin.iOS.
Comment 3 Brendan Zagaeski (Xamarin Support) 2016-06-25 05:03:35 UTC
Based on the logs, the next thing I'd curious about would be, what happens if you run the following 2 commands in a `cmd.exe` command prompt immediately after you hit the error with the build:

C:\Users\beyer\AppData\Local\Xamarin\MonoForAndroid\AndroidSDK\platform-tools\adb.exe -s  shell getprop


The prediction would be that the first command would produce empty output or an error message, and the second command would return an error level of 1, matching up with the log output:
> "adb.exe" exited with code 1.

(As hinted at in one of the forum comments [1], the issue seems to be that `adb.exe` is not communicating successfully with the emulator at this step.  Based on the forum comment, it sounds like one possible cause of that problem is if the emulator is using its own mismatched version of `adb`.)


## Sample "good" results

For comparison, if I run the corresponding 2 commands from the first test environment I'm looking at here [2], I get the following results:

> C:\>C:\android-sdk\platform-tools\adb.exe -s  shell getprop
> 23
> C:\>echo %ERRORLEVEL%
> 0

[2] Google x86 API 23 2-core hardware accelerated emulator running on OS X, deploying from Visual Studio in a Windows VM hosted on the same machine.
Comment 4 Cody Beyer (MSFT) 2016-06-25 18:43:55 UTC
Slightly different than expected. Upon deployment failing, it appears that ADB either disconnects, or never actually connects

>C:\Users\beyer\Documents\Visual Studio 2015\Projects\uuidTest\uuidTest>adb -s >  shell getprop
>error: device '' not found

>C:\Users\beyer\Documents\Visual Studio 2015\Projects\uuidTest\uuidTest>echo %errorlevel%

However, after after this occurred, I connected ADB manually

>C:\Users\beyer\Documents\Visual Studio 2015\Projects\uuidTest\uuidTest>adb connect >
>connected to

>C:\Users\beyer\Documents\Visual Studio 2015\Projects\uuidTest\uuidTest>adb -s >  shell getprop

from here, I attempted to deploy again and was able to deploy the app.

Interestingly, if I run

>adb devices

while the build/deploy process underway, the following error is thrown. 

>adb server version (36) doesn't match this client (35); killing...
>could not read ok from ADB Server
>error: could not install *smartsocket* listener: cannot bind to Only one >usage of each socket address (protocol/network address/port) is normally permitted. >>(10048)
>* failed to start daemon *
>error: cannot connect to daemon

Not sure if this is related in any way at this time, but it is persistent while it is deploying. Again, after the deployment failure, I am able to connect with

>C:\Users\beyer\Documents\Visual Studio 2015\Projects\uuidTest\uuidTest>adb connect >

and then deploy.
Comment 5 dean.ellis 2016-07-06 09:01:39 UTC

I cannot replicate this on a clean VS 2015 + VS Emulator installation. 
Looking at the thread on the forum it is more than likely the miss match adb client issue [1].
Can you do a search on the failing PC to see how many copies of adb.exe you have. 
On my system I have one which is in 

c:\Program Files (x86)\Android\andorid-sdk\platform-tools\

We cannot control which adb we use. That setting is passed to us via the settings in Visual Studio. So if that is pointing to an outdated/incompatible version there isn't much we can do.

Comment 6 Peter Collins 2016-07-06 18:45:27 UTC
My investigation appears to confirm Dean's (and others) comments about mismatching adb severs running simultaneously.

I'm unable to reproduce this using various physical devices, an API 23 x86 google emulator, and an API 19 VS Emulator. I am however able to reproduce using an API 23 genymotion emulator, but _only_ when the following is true:

> 1. I toggle the checkbox which tells Genymotion to use it's own SDK tools (instead of the path Xamarin knows about).
> 2. Any such "custom tools" Genymotion emulator must be actively running.
When the latter condition is true, deployment attempts to _any_ connected device will fail. At this point I have three adb.exe processes running, and any invocation of `adb` will fail due to a server mismatch.

> adb server version (x) doesn't match this client (y); killing...

@Cody did you by chance also have a genymotion emulator running in the background while trying to deploy to the VS emulator? 

If not, do you have multiple Android SDK installations? The VS emulator uses the 'Path' variable from the following registry key[0] to determine which tools to use. 

Does this key exist, and is it different from the path set in VS under `Tools -> Options -> Xamarin -> Android Settings -> Android SDK Location`?

Presumably if the path in this key and the path in the IDE are pointing to mismatched versions of ADB this would also result in the same failure reported.

If this is the case, I'm also not sure what can be done on the C7SR1 timeline outside of better communication/education around this possible failing scenario.

Comment 7 Cody Beyer (MSFT) 2016-07-06 20:43:56 UTC

I do not have genymotion installed, nor did I have any other emulators running. I do have two SDKs installed (Android Studio and Xamarin as separate SDKs). They are pointing to different locations.

This brings up a scenario which we may want to trap, its not unheard of at all for two different Android SDKs to exist, and for there to be this mismatch. Would it be prudent to add some sort of messaging? I would not want to imply that users should check their registry, but if we can compare the two paths (whats in reg versus whats in Visual Studio) we may be able to print an error message that asks for the customer to update one of the other.

Comment 9 2016-07-07 11:29:44 UTC
I have this same issue and my registry value matches my VS value for the location of the SDK.  I did an update of visual studio and the issue started happening.  I updated to VS 2015 update 3.  Also, I don't use the emulators I always use a device.
Comment 10 dean.ellis 2016-07-07 14:31:16 UTC

Can you give any more details on your system setup.
How many versions of adb.exe are present on your system. 
Which devices are you seeing the issue on? 
If it fails on a device can you see if

'adb shell getprop'

returns anything .
Comment 11 2016-07-08 13:42:28 UTC
I have three versions of build tools on my machine: 19.1.0 21.1.2 and 23.0.1.  
Where should I run that adb command?  I tried it from the visual studio command and it did not recognize it, same result from a windows command.

I get the same result on every device.  I have tried a nexus 7 a Samsung S7 and a Samsung Note.  All fail the same.
Comment 12 dean.ellis 2016-07-15 18:55:37 UTC
This was fixed in monodroid/cycle7/13cf91a and cp'd to cycle7sr1. 

Still needs to be revisited in cycle8. So I am changing the milestone.
Comment 13 dean.ellis 2016-07-26 09:04:04 UTC
On the latest master if we try to "Install" with Genymotion when its using its own adb we get the following message.

"* failed to start daemon *
		error: cannot connect to daemon
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets: error : Tool exited with code: 1. Output: error: could not install *smartsocket* listener: Address already in use
List of devices attached
adb server version (32) doesn't match this client (36); killing...
ADB server didn't ACK
* failed to start daemon *
error: cannot connect to daemon

/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets: error : Error executing task GetPrimaryCpuAbi: Failed to run adb. Arguments are: devices
		Build FAILED.
Which seems reasonable to me.
Comment 14 dean.ellis 2016-07-29 10:11:02 UTC
Fixed in monodroid/cycle8/8c464ed48d1d1ce3e7a49dd372f77fbe01f5d4a8
Comment 15 englishguy64 2016-08-01 14:04:46 UTC
Updated to Visual Studio 2015 Update 3 Latest patch

A numeric comparison was attempted on "$(_DeviceSdkVersion)" that evaluates to "" instead of a number, in condition "$(_DeviceSdkVersion) >=

Was not deploying. This happened on all of the sample solutions but other lots of trial and error some of them deployed

This however did the trick 

A reboot of the Android Nexus 5 handset after disconnecting it from the PC.

Reconnected to pc and then deployed OK after a successful clean and re-build has been done before disconnecting and re-booting.
Comment 16 Abhishek 2016-08-03 18:50:00 UTC
I checked this issue and able to reproduce this issue at my end:

Application Output:

To verify this issue I have checked this issue with XVS C8 and master.

Screencast C8 XVS:
Application Output:

Screencast Master XVS:
Application Output:

Hence closing this issue.


Note You need to log in before you can comment on or make changes to this bug.