Most of my development efforts are focused on Web, Desktop and Server scenarios; but with the launch of Visual Studio 2017 and all of the new Mobile Development capabilities, I figured it was time to invest in establishing a minimal proficiency with mobile apps. While the setup and configuration for most people is simple, there are a couple of considerations that can result in some twists and turns in getting things going – and it seems I hit every one of them!
The first problem was triggered by the fact I do 99.9% of my development in a virtual environment. For well over a decade the usage of Virtual Machines (VM) has been the norm. I spun up a Windows 10 VM, and installed Visual Studio 2017, selecting the appropriate workloads. Although I knew it from prior experience this was a blocker for getting the Android (and other) emulator installed, since the emulators are themselves Hyper-V based.
This meant it was time to install on Physical Hardware. Over the years, as more of my resources moved to Azure, spare hardware has been reduced so the easiest thing to do was to run it directly on one of my server [Hyper-V host]. This allowed the emulators to be selected, and the Visual Studio installation completed. Alas, when I tried to create a Xamarin project, I received a blocking notification that this project type was not supported on Server editions of Windows.
At this point, the effort became a personal challenge. Rummaging through the storage area I located a laptop that had been retired. It already had a bunch of stuff on it, but was not actively being used so it seemed to be a reasonable platform.
Starting the VS-2017 install on this hardware, it quickly became apparent that there was not sufficient room on the C: drive. This should not be an issue as there was also an E: drive that had a bunch of room and VS-2017 allowed you to specify the target directory. Hope returned.
The hope was short lived as the installation failed. It turns out the current release of VS-2017 downloads *all* of the packages to the TEMP location; which is under the current user’s profile directory and, of course, this is on the nearly full C: drive. It took a little bit of time to realize that this was what was happening, but once I was aware of the situation, I figured it would be simple to simply change the system environment variable to TEMP and point it to a location on the E: drive where there was plenty of room.
After a cleanup and reboot, I started the process once again. Even though both the temporary download location and the final target were set to E:, I was still getting the warning that there was not sufficient space. At this point, I connected with some people at Microsoft who indicated that there were some limitations to their estimation logic (which is scheduled to be improved) and that I should try the actual install.
The install ran for a while, and then once again failed with an out of space condition. It turns out a number of third party components [including the Android Emulator] will still be installed under C:\Program Files rather than the specified target directory. Fortunately, there were a few applications installed that I could easily remove to provide sufficient space.
In the end, I did get a good development environment setup. The vast majority of developers work directly on the hardware (not in VM’s) using a client edition of Windows – eliminating the original hurdles. I am having a good time going through the development, test, CI/CD capabilities and it is all quite good.
Hopefully, this post will help some people get to a working environment without the twists and turns that the conditions here triggered.
Do you need to upgrade to Visual Studio 2017? Contact us today to schedule your upgrade by filling out the form below or calling us at (800) 565-0510.
