Debugging Xamarin projects from VirtualBox on the Android emulator
The other day I decided to try using Visual Studio with Xamarin to write cross-platform code for three mobile platforms at once. Since I used to deal with AndroidStudio, I lacked the ability to port code to other platforms.
The description of the Visual Studio Community 2017 says beautifully that they say the unified business logic for iOS, Android and Windows 10, a unified approach to creating controls via Xamarin.Forms, the own Xamarin Instant Player emulator and other buns. Why pay more if you can for free?
Without thinking for a long time, I download and install VisualStudio, select the options I want and specify the path on drive D. And almost immediately I get a warning that there is no space left on drive C. How so?
And it turns out, except for VisualStudio on the C drive, a huge number of tools, components and utilities are dropped into the “Program Files” folder. As I later understood, they cannot be transferred. They should be in the folder on the system drive (I have an SSD drive C and it has only 5 GB of free space). Of course, there is an option to create symlinks to a folder on disk D, but on a running system I’m afraid to experiment.
')
As a result, for the experiment I decide to install VisualStudio in the VirtualBox emulator (it is free and quite functional). Things are easy. And now everything is installed, and I am creating the first HelloWorld application in C # from templates.
Trying to run on the emulator and get a bummer. It turns out Hyper-V must be disabled, HAXM is not compatible with it. I do according to the instructions
Reboot virtualka and ... nothing. The same mistake.
Well, I think, okay, I'll try through PowerShell
I reboot a virtualka and again an error.
I turn off the virtual machine, and in its settings I turn off virtualization completely (System → Acceleration parameter → Para-virtualization interface → “None”), while the VT-X / AMD-V remains on!
I launch the virtual machine and click on the debug button in the built-in VisualStudio emulator. Now the studio happily reports that I don’t have VT-X at all (although an Intel Core i5 processor + emulation of the ICH9 chipset). What combinations did not try - the result is one. The built-in studio emulator on VirtualBox does not start from the word at all. The same problem with AndroidStudio on a virtual machine - it does not start the Android Emulator.
I'm trying to install HAXM on a virtual machine, but unfortunately unsuccessfully.
Having scratched my brain, I come across such a feature-request , where users are asked to make HAXM inside VirtualBox. Apparently, this has not yet been implemented, in contrast to the same VMWare.
Well, as a man with experience, not for the first time to fasten a tambourine. It is necessary to run the emulator on the host and give virtual machine access over the network. And here there is a problem - it is impossible to reach the emulator. Its IP (10.0.2.15) is outside the range of my network (192.168.1.x). Reassigning IP to network cards either on the host or on the virtual machine does not give anything. Apparently the ADB service listens only to the interface 127.0.0.1, as I understand it for the purpose of security.
Along the way, I find an interesting article about access to the virtual machine emulator , but unfortunately a bit outdated (Xamarin Android Player is no longer supported and its images are also not updated. The latter comes with API 23). Therefore, I decide all the same to achieve work with android emulator.
Finally, I follow the instructions for port forwarding using the assembled program from source (the compiled file has already gone into non-existence). The option with port forwarding using netsh does not work - you cannot specify 127.0.0.1 ( proof ) as the destination in it.
Then I do adb kill-server on the host and on the virtual machine. On the virtual machine I write “adb connect 192.168.1.2: 5585” and ... I get “adb server version (36) does not match this client (39); killing ... ". Already good, but what's the problem?
It turns out I have two adb services on a virtual machine. One service is in "C: \ Users \\ AppData \ Local \ Android \ sdk \ platform-tools" and the second in "C: \ Program Files (x86) \ Android \ android-sdk \ platform-tools". One installed with AndroidStudio, the second with VisualStudio. I take the one that came with AndroidStudio and try again. Hooray! This time the connection is established! I get "connected to 192.168.1.2:5585".
In VisualStudio my running image automatically pops up in the Android emulator on the host. The connection count in PortForwarding shows the active connection (it must be one).
And finally, here it is - the result that has been waiting for so long:
Now a few conclusions for which I started this test:
1. Debugging in this way is not stable. Periodically there are freezes when building the project, errors are generated which are eliminated by restarting VisualStudio and the emulator.
2. Running AndroidStudio on the virtual machine knocks out the ADB connection to the host. Therefore, for AndroidStudio on the virtual machine you need to look for other debugging options with an emulator, or use a physical device.
3. The physical device does not need to be debugged through the network port. The virtual player sees it as a USB device (only you need to connect it in the settings).
And a bit of offtopic:
Now I sit and think, is it really worth it to bother so much to pull the framework with you?
The description of the Visual Studio Community 2017 says beautifully that they say the unified business logic for iOS, Android and Windows 10, a unified approach to creating controls via Xamarin.Forms, the own Xamarin Instant Player emulator and other buns. Why pay more if you can for free?
Without thinking for a long time, I download and install VisualStudio, select the options I want and specify the path on drive D. And almost immediately I get a warning that there is no space left on drive C. How so?
And it turns out, except for VisualStudio on the C drive, a huge number of tools, components and utilities are dropped into the “Program Files” folder. As I later understood, they cannot be transferred. They should be in the folder on the system drive (I have an SSD drive C and it has only 5 GB of free space). Of course, there is an option to create symlinks to a folder on disk D, but on a running system I’m afraid to experiment.
')
As a result, for the experiment I decide to install VisualStudio in the VirtualBox emulator (it is free and quite functional). Things are easy. And now everything is installed, and I am creating the first HelloWorld application in C # from templates.
Trying to run on the emulator and get a bummer. It turns out Hyper-V must be disabled, HAXM is not compatible with it. I do according to the instructions
bcdedit /set hypervisorlaunchtype off Reboot virtualka and ... nothing. The same mistake.
Well, I think, okay, I'll try through PowerShell
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Hypervisor I reboot a virtualka and again an error.
I turn off the virtual machine, and in its settings I turn off virtualization completely (System → Acceleration parameter → Para-virtualization interface → “None”), while the VT-X / AMD-V remains on!
I launch the virtual machine and click on the debug button in the built-in VisualStudio emulator. Now the studio happily reports that I don’t have VT-X at all (although an Intel Core i5 processor + emulation of the ICH9 chipset). What combinations did not try - the result is one. The built-in studio emulator on VirtualBox does not start from the word at all. The same problem with AndroidStudio on a virtual machine - it does not start the Android Emulator.
I'm trying to install HAXM on a virtual machine, but unfortunately unsuccessfully.
Having scratched my brain, I come across such a feature-request , where users are asked to make HAXM inside VirtualBox. Apparently, this has not yet been implemented, in contrast to the same VMWare.
Well, as a man with experience, not for the first time to fasten a tambourine. It is necessary to run the emulator on the host and give virtual machine access over the network. And here there is a problem - it is impossible to reach the emulator. Its IP (10.0.2.15) is outside the range of my network (192.168.1.x). Reassigning IP to network cards either on the host or on the virtual machine does not give anything. Apparently the ADB service listens only to the interface 127.0.0.1, as I understand it for the purpose of security.
Along the way, I find an interesting article about access to the virtual machine emulator , but unfortunately a bit outdated (Xamarin Android Player is no longer supported and its images are also not updated. The latter comes with API 23). Therefore, I decide all the same to achieve work with android emulator.
Finally, I follow the instructions for port forwarding using the assembled program from source (the compiled file has already gone into non-existence). The option with port forwarding using netsh does not work - you cannot specify 127.0.0.1 ( proof ) as the destination in it.
Then I do adb kill-server on the host and on the virtual machine. On the virtual machine I write “adb connect 192.168.1.2: 5585” and ... I get “adb server version (36) does not match this client (39); killing ... ". Already good, but what's the problem?
It turns out I have two adb services on a virtual machine. One service is in "C: \ Users \\ AppData \ Local \ Android \ sdk \ platform-tools" and the second in "C: \ Program Files (x86) \ Android \ android-sdk \ platform-tools". One installed with AndroidStudio, the second with VisualStudio. I take the one that came with AndroidStudio and try again. Hooray! This time the connection is established! I get "connected to 192.168.1.2:5585".
In VisualStudio my running image automatically pops up in the Android emulator on the host. The connection count in PortForwarding shows the active connection (it must be one).
And finally, here it is - the result that has been waiting for so long:
Now a few conclusions for which I started this test:
1. Debugging in this way is not stable. Periodically there are freezes when building the project, errors are generated which are eliminated by restarting VisualStudio and the emulator.
2. Running AndroidStudio on the virtual machine knocks out the ADB connection to the host. Therefore, for AndroidStudio on the virtual machine you need to look for other debugging options with an emulator, or use a physical device.
3. The physical device does not need to be debugged through the network port. The virtual player sees it as a USB device (only you need to connect it in the settings).
And a bit of offtopic:
- Running an already installed application with Xamarin.Forms takes a lot of time (much longer than regular Java projects).
- In addition to the very big size of the application (HelloWorld takes more than 12 MB), we also get the Mono Shared Runtime (42 MB) and Xamarin Android support (for API23, this is 23 MB).
Now I sit and think, is it really worth it to bother so much to pull the framework with you?
Source: https://habr.com/ru/post/335680/
All Articles