Showing Wall-E infront of a yellow VW bus with taxi stripes

I have taken quite a liking into Fabulous - a wrapper around Xamarin.Forms allowing you to write functional UIs with F#. When first looking at the project I noticed that is was being built on AppVeyor and Travis. I asked myself: Why use two CI Systems for compiling one project? After some further digging I found out that there are no hosted macOS Agent on AppVeyor. Travis on the other hand did come with agents for Windows and macOS but did not have the Xamarin Toolchain installed on the agents. Installing the Xamarin Toolchain on every run lead to a build time of over 30 minutes. Since Azure DevOps supports building on Windows and macOS I thought I would give it a go and setup a Pipeline to build Fabulous - I mean how hard can it be? Well hard enough to write a blog post to sum up the steps to get over the pitfalls

TLDR: How to run your FAKE scripts on Azure DevOps

Fabulous uses FAKE to execute the build, tests and create the NuGet packages. FAKE is a power full tool for writing build scripts. FAKE is also a .Net Core CLI tool which is designed for being installed and executed from the command line, so it should be a great fit for running on any build server.

Installing FAKE

Azure DevOps build agents do not come with FAKE preinstalled. Since FAKE is a .Net Core CLI tool this is no problem. The following command should solve this issue:

dotnet tool install fake-cli -g

Unfortunately executing FAKE after installation fails. This is because the installation directory on the Azure DevOps build agents differs from the standard installation location of .Net Core - Why? you ask, well the answer given is security. On Windows we can circumvent this fact by installing FAKE into the Workspace directory:

dotnet tool install fake-cli --tool-path .

Under macOS (and Linux) this approach still fails. The suggested solution is to set DOTNET_ROOT. I ended up with the following lines to be executed on the macOS agent:

export DOTNET_ROOT=$HOME/.dotnet/
export PATH=$PATH:$HOME/.dotnet/tools:/Library/Frameworks/Mono.framework/Versions/Current/Commands
dotnet tool install fake-cli -g

On Linux the approach had to adopted again - go figure. I ended up with these lines:

export PATH=$PATH:$HOME/.dotnet/tools:/Library/Frameworks/Mono.framework/Versions/Current/Commands
dotnet tool install fake-cli -g

Now you should be able to run your FAKE script on Azure DevOps

Using NuGetFallbackDirectory

This part is not directly related to FAKE but is something I stumbled over while running on Azure DevOps. One test script was referencing the NuGet packages via the global NuGetFallbackDirectory and was looking for them under the default location. Under macOS the location is in the users home directory, so adopting the path as follows did the trick:

let tfsEnvironment = Environment.GetEnvironmentVariable("TF_BUILD")
if (String.IsNullOrEmpty(tfsEnvironment)) then
    let homepath = Environment.GetEnvironmentVariable("HOME")
    Path.Combine(homepath, ".dotnet/sdk/NuGetFallbackFolder")

Note that the variable TF_BUILD is expected to only be set on TFS/VSTS/Azure DevOps. This will allow the script to fall back to the default location should it be executed on a developers machine.

But why even bother?

What is the motivation of migrating from a working CI to another? Are you doing because you are a Microsoft MVP?

These were questions I got when talking with colleagues about my endeavors to build Fabulous on Azure DevOps. I think AppVeyor and Travis are great tools and they have shown that they are up to the task building and testing Fabulous. Other than because I was curious how hard it could be, there were two aspects why I wanted to try to migrate the build to Azure DevOps:

  1. Merging the builds, having two places doing one thing always comes with overhead.
  2. The other one was seeing how much the build time would be reduced by not having to install Xamarin.

So here is a comparison between the build times before and after:

CI PlatformAgent OSBuildTestTime (minutes)
Azure DevOpsmacOS~13-14
Azure DevOpsWindows~6

Now to keep in mind, the build on macOS and Windows are ran in parallel. So in case of AppVeyor and Travis the resulting build time would be 30-32 minutes. With Azure DevOps this can be brought down to 13-14 minutes.

I would argue that merging two build scripts into one and cutting build time roughly in half are good arguments for why Azure DevOps seems to be a better fit for Fabulous. Then again there was some pain on getting the .Net CLI tools running, which I hope the Azure DevOps team will solve in the future - being products from the same company and all cough

Another aspect was having a build on Linux in the future, since Fabulous supports GTK since 0.30 it would be nice to also compile it on Linux. At the time of writing there were still a few kinks in the build process of Fabulous, but nothing that can't be solved in the future.


Thank you Timothé Larivière and Stuart Lang for all the tips and hints along the way



When developing an app e.g. a mobile app for iOS, Android and Windows 10 or a web app what initially stands in the spotlight is a core idea that brings a core value to it’s users. As soon as the scope is better known one ideally starts developing a Minimal Viable Product which demonstrates the core ideas and let’s the creators get first feedback from potential users. With the initial ideas and the feedback the team starts to add more and more functionality to the app and all is well. Until users start reporting some odd behaviour and the well intended changes start having side effects on other features. So every release gets thoroughly tested before it is sent out. The time it takes to check on all features starts to increase, but holding off of going through all the tests may lead to a new bug that snuck into the app. So what to do?

Bring The Fairy Dust - Automated UI tests

This is often the point where one person e.g. a non-technical manager hears about a UI testing framework – which solves exactly the problem of automating manual tests. Plus one great thing about a UI testing framework usually is that there are no changes required in the app. The coverage of a test is very high since one works against the entire stack.

Automated UI tests simulate user interaction on the UI layer of an app. Depending on what kind of app there are different frameworks that one can choose from. For mobile apps on iOS and Android the solution we will be looking at is Xamarin Test Cloud (XTC) which is based on the Calabash testing framework. XTC allows to create UI test that can be used across platforms. They can be run locally i.e. read “phones attached to the Computer of the tester”. Far more interesting though is the opportunity of running the same tests in Xamarins Test Cloud which offers hundreds of devices (with different OS versions) on which the app and tests can be run on.

But as so many things in life - UI tests come at a cost. Compared to unit- or integration tests they are rather slow and like integration tests they tend to be more on the brittle side i.e. a test fails due to changes to the app. This is especially true if the UI is still under a lot of change. That being said they can be a great tool to bring down manual testing time. But solely relying on UI tests for your mobile tests will most probably not result in the result you were hoping for. So what are the sweet spots where automated UI tests will bring you the largest benefit?

Well lets start by looking at what kind of tests you can actually implement when considering mobile applications:


As the graphic indicates the wider the pyramid the more tests you will probably want to have in your project. So lets dive into what the main benefits are for the different areas and let’s also look at how they could be implemented.

Unit Tests

Testing your basic logic of a class is where Unit Tests come into play. A Unit Test should not rely on any dependencies a class may have and therefore requires Stubs and Mocks to evaluate the correct working of business logic. Unit Tests should always pass without an error since they check the basic logical implementations of an app.

UI Tests should always pass i.e. be green since they only test logic without any dependencies.

Further Unit Tests are fast. In fact a Unit Tests is considered slow if it runs longer than100 milliseconds. For larger projects it is not uncommon to have a large number of these tests checking that all the small building blocks are working according to specification/user story. The additional work required for stubbing out dependencies may result in tedious work for certain parts of an app that are mainly coordinating workflows. Further since they only test logic in isolation the Unit Tests do not give any feedback how the components work together. But when all Unit Tests are green the confidence in the logic of an is very high and allows to shift the focus on search for an issue to the interaction of the building blocks which is where Integration Tests come into play.

Characteristics of a Unit Test

What is testedLogic Blocks, single Classes, Parts of Classes
Execution Time / Test< 100 ms
ReliabilityVery High
Impact on ArchitectureHigh

Integration Tests

When multiple parts e.g. classes of an app want to be tested an integration test is usually the way to go. Integration tests can range from testing a couple of classes that work closely together to system tests that require multiple parts of a system up and running. For external services that are not part of the developed app stubs and mocks may be used to ensure that tests do not fail due to services failing outside of the teams scope. Integration tests usually take more time to run since they run the real life scenarios. Due to the number of different parts and sub-systems an integration test may be running through the tests tend to be more brittle than a unit test. Further it can get harder to pin point errors to a specific area of a project, so unit tests are a perfect completion to integration tests as they allow to test complex logical parts in separation. If we look at a standard app built according to the MVVM pattern, the Integration tests are usually run from the View Model or lower in the stack. Integration Tests do not only allow to test for functional correctness of an app but also allow to get a feel for how performant an app is. If you are interested to run your tests on an actual device you can read more about this topic here.

One issue with integration tests is that the View is not being tested. Even though may argument that when the MVVM pattern is applied correctly there is only minimal logic remaining in the View, the user will still use the app via the view. This leaves the possibility that the app will still have issues when operating it through the view. Here (automated) UI tests come into play.

Generally speaking if a project has no automated tests at all, integration tests tend to give a bigger bang for the buck. Since the architectural requirements are not equally thorough.

Characteristics of an Integration Test

What is testedInteraction between componentens, Integration with other System parts, Network communications, Long running tests, memory consumption
Execution Time / TestSeconds to hours
ReliabilityMedium - High
Impact on ArchitectureMedium

UI Tests – Xamarin Test Cloud

Now it might be tempting to avoid testing your app altogether when having a sophisticated test suite of Unit- and Integration Tests, but in the end the user will interact via the UI with the app. And generally speaking they do not care if the logic beneath is sound, when the app crashes on their Device due to some incompatibility with a UI element that is used in the app. So the minimum UI testing every app project should be performing is the manual test. A person taps through the app and ensures that the UI responds as expected and follows the intended workflow. Now as stated before a manual test takes a lot of time and the resource performing the test I.e. a human might feel a bit underwhelmed. So generally speaking where can we utilise automated UI tests to improve test coverage:

  • Smoke Testing
  • Workflows
  • Testing interaction
  • Presence of Elements
  • Localization
  • Multi device tests

It might be tempting to think one can eliminate manual testing altogether, but there are some areas that UI tests just won’t be able to cover automatically and will always need a human:

  • Layout (Elements not rendering correctly)
  • System Interactions
    • Camera
    • Photo Album
    • Sharing
  • UI “Snappiness”
  • Exploratory Testing
  • Offline Testing
  • Bluetooth

Even though the Layout can be covered by an automated test insofar, that it takes pictures which can be verified by a user/MD5 Hash compared. A computer (at least at the time of writing) does not have the capability to analyse the layout of an app for its correctness. So a human eye and brain is still needed for some tests, this is something to keep in mind when automating all the things. Other limitations come either from the setup e.g. there must be a WiFi connection to the phone to run the automated UI tests. In general testing interconnectivity to other devices i.e. proprietary hardware or plainly some other phone that has to be paired, UI tests often become quite cumbersome to setup and the XTC does generally not support these kind of scenarios. So yes there are limitations to UI tests but using them properly will not only greatly enhance the coverage of automated tests but also free up valuable tester time that can then be used to put the human brain to more advanced testing tasks then numbly tapping through an app.

Characteristics of a UI Test

What is testedTests entire app software stack, Smoke Testing, Workflow Testing
Execution Time / TestMinutes
ReliabilityMedium – Low
Impact on ArchitectureLow


There are multiple different ways how one can approach automated testing of a mobile app. On one end there are tests verifying the logic of the single building blocks an application is built upon. Integration tests allow to verify the correct interworking of parts of the app, this can extend over the border of a an app and also include calls to a backend for verifying correct integration. The highest level tests available to mobile applicaitons are automated UI tests. The Xamarin Test Cloud allows create UI tests that can be executed on many hundred of devices. Testing apps on so many devices before the app ships can lead to valuable insights and automating these tests allows to easily perform regression tests not only on logic and integration layers but also for the UI. Think about an upcoming OS release and you want to check if there any issues with your app, given automated UI tests you can easily run a test suite that will quickly inform you if there is any concern with the upcoming update.


Overview of UWP Apps Platforms

With UWP apps it has become easier then ever to write a single app that will run natively on all Windows 10 devices be it a phone, tablet, PC, Xbox et. al. Now we don’t just want our apps to be able to run on a device we want them to shine while they are running. In this blog post we will look at the basics on how to adopt to different screen sizes within your UWP app.


The devices and screen sizes

UWP runs on many different platforms some might not even come with a screen by default e.g. Internet of Things (IoT) devices or others that require a unique UI such as HoloLens which should be available for a few lucky developers later this year. Now while those platforms are very interesting in certain scenarios a wide array of apps will most probably be developed for mobile devices such as phones, tablets and phablets aka BAPHs (Big a** Phones). The unique thing about the UWPs in comparison to Android and iOS apps is that you apps will not only run on mobile devices but on desktop machines, laptops and even larger screens such as the new Surface Hub.

Windows 10 Devices
Now write once run everywhere and look like crap is easy to do. But the great benefit of creating a UWP app is that you can adopt to the different screen sizes and even adopt to different user input such as touch vs mouse and keyboard. But before we dive into the details of how we can write responsive UIs with XAML lets have a look at some basic layout rules.

Devices and screen sizes

A general split up of the devices can be made as follows.

CategoryScreen sizeWidth in Effective PixelsInputs
Phone4” to 6”340+Touch & Voice
Phablet6+” to 7”720+Touch & Voice
Tablet7” to 13.3”1024+Toch, Stylus, External keyboard*, Mouse*, Voice*
PCs and Laptops13” and greater1024+Mouse, Keyboard, Touch*, Gamepads
Surface Hub Devices55” and 84”1024+Touch, Pen, Voice, Keyboard, remote Touchpad

*: occasionally

Basic layout guides

Since UWP apps are built from the ground up to run on all kinds of different devices i.e. form factors the platform comes with many helpers that make life easier to design for multiple platforms. One basic concept are effective pixels. Effective pixels differ from actual physical pixels so 24 effective pixels on a phone will scale up to a larger physical appearance on a larger screen. The scaling of effective to physical pixels is all done by the framework and does not require any special attendance by the developer i.e. designer.

Image showing the diferent scale factors accroding to the device.

Note: Often small screens do have very large Dots Per Inch (DPI), this is also handled by the platform so even if you are running on a small device with a cheap display i.e. low DPI the text will still be readable as clearly as on a higher end display with more pixels i.e. a higher DPI.

The scaling is based on multiple of fours (4), so when defining layouts make sure they are a multiple of four e.g. 16. This will ensure that the scaling will not lead to strange effects. When using icons, rather than using images try to use a font (for example the new Segoe MDL2 Assets) that provides the icon you are looking for (or close enough). Though Windows 10 does provide a mechanism that chooses between different resolutions of an image according to the screen size, a font will always scale without any further effort.

Implementing responsive layouts that adapt to the available screen space

When working with different resolutions there are multiple layout adjustments that can be performed to improve general User Experience (UX) and – Interaction. UWP offer a variety of ways to adjust the layout of an app according to the available screen space.

  1. Changing layout of elements on a page according to form factor and available screen space
  2. Reflow e.g. adding text columns when the screen size increases
  3. Reveal information/functionality depending on the device and it’s resolution
  4. Replace elements such as navigation bars with fly out menus to accommodate smaller screen estate
  5. Change screen flow e.g. of master detail sites

So lets dive into how we can change the layout of UI elements according to the screen space.

Responsive Layout


One new feature of UWP apps is the possibility to adapt the layout of the controls according the available screen size i.e. the effective pixels width of the app windows. This lets the UI adapt to different screen sizes e.g. phones and tablets but also lets the UI adapt to the size a Window has on a desktop.

Lets assume you have the following screen flow and layout in your app:

Shows app running with fewer than 720 effective pixels.

The basic Layout of the app looks as follows:

    <Rectangle x:Name="Image" Width="80" Height="80" Fill="Gray" Margin="8"></Rectangle>
    <Rectangle x:Name="TextLine1" Height="16" Width="200" Fill="Gray" RelativePanel.RightOf="Image" RelativePanel.Below="" Margin="8,8,8,4"/>
    <Rectangle x:Name="TextLine2" Height="16" Width="200" Fill="Gray" RelativePanel.RightOf="Image" RelativePanel.Below="TextLine1" RelativePanel.AlignLeftWith="TextLine1" Margin="8,8,8,4"/>
    <Rectangle x:Name="TextLine3" Height="16" Width="168" Fill="Gray" RelativePanel.RightOf="Image" RelativePanel.Below="TextLine2" RelativePanel.AlignLeftWith="TextLine1" Margin="8,8,32,4"></Rectangle>

Note: that rendering the items in a RelativePanel allows the elements within i.e. the Rectangle to align themselves relative to one another. This is a new layout feature available in Windows 10 UWP apps which previously had to be done with a Grid or StackPanel. The benefit of using relative layouts is when we focus on how we might want to realign the content for a different screen(size).

For instance when displayed on a tablet you might not just want to show a small image next to the text but go with a banner. Using a VisualStateManagerone can easily define trigger points for the minimal window Width and  if the trigger fires adopt the layout of the predefined layout:

        <VisualState x:Name="wideView">
                <AdaptiveTrigger MinWindowWidth="720" />
                <Setter Target="Image.(Width)" Value="720"/>
                <Setter Target="TextLine1.(Width)" Value="720"/>
                <Setter Target="TextLine2.(Width)" Value="720"/>
                <Setter Target="TextLine3.(Width)" Value="600"/>
                <Setter Target="TextLine1.(RelativePanel.Below)" Value="Image"/>
                <Setter Target="TextLine1.(RelativePanel.AlignLeftWith)" Value="Image"/>
        <VisualState x:Name="narrowView">
                <!-- Adjust view for narrow view -->
                <AdaptiveTrigger MinWindowWidth="0" />

The name of the Target matches the x:Name given to the controls. The page will now re-render if the app has more then 720 effective pixels:

Shows app running with more than 720 effective pixels.

The page will also adjust when resizing the window on a Windows 10 desktop machine which allows the user to have multiple applications open at once with them seamlessly adapting to new windows sizes.


In this post we saw that Universal Windows Platform Apps not only run on multiple devices but that the platform provides the developers and designers with the necessary tooling of creating a great User Experience no matter the screen size and resolution without having to create multiple page layouts from the ground up and having to somehow figure out the size of the screen itself.

You can find the entire project on GitHub.


See how you can offer cross platform APIs based on C# that you can consume in Universal Windows Platform Apps (UWP), Xamarin.iOS, Xamarin.Android, Xamarin.Forms, ASP.Net and even your classic .Net WPF app. In my last post I showed how one can use platform specific libraries and code in a Portable Class Library with dependency injection. This approach is great when you are developing your own app but it gets somewhat quirky, when you want to offer a library to fellow co-workers/developers, as you force them to setup your own library through dependency injection. But there is of course another way that allows you to encapsulate your implementation details neatly while still providing platform specific features to your PCL code.

The library in this blog post will provide the OS version for a UWP, Xamarin.iOS and Xamarin.Android app.

Setting up the library

The library consists of four projects:

  • OSVersion.Core
  • OSVersion.UWP
  • OSVersion.Droid
  • OSVersion.iOS

One thing which is a bit special about all the projects is that all of their Default Namespace and the Assembly name all have the same name.


In each project we implement the SystemInformationHandler.cs class, on the PCL we simply implement a stub:

public class SystemInformationHandler
    #region Implementation of ISystemInformationHandler

    public static string OSVersion => "Gnabber";


For the other platforms such as UWP we implement the calls to the UWP specific APIs:

public class SystemInformationHandler
    public static string OSVersion
        get { return OsVersionString(); }

    private static string OsVersionString()
        string sv = AnalyticsInfo.VersionInfo.DeviceFamilyVersion;
        ulong v = ulong.Parse(sv);
        ulong v1 = (v & 0xFFFF000000000000L) >> 48;
        ulong v2 = (v & 0x0000FFFF00000000L) >> 32;
        ulong v3 = (v & 0x00000000FFFF0000L) >> 16;
        ulong v4 = (v & 0x000000000000FFFFL);

        return $"Windows {v1}.{v2}.{v3}.{v4}";

So in the end we have implemented the generic class in the PCL and specific classes for each platform we target to support. Now lets see how we can consume this library in an app.

Consuming the library

The app will exist of the usual cross platform mobile app setup which means we will have usual suspects covering Windows, Android and iOS with a Portable Class Library aka Core to share the reusable code.


In the core we have our business logic code and view models (I’m a huge fan of the MVVM Light library, to find out more just view my mvvm light posts). In the NativePcl.Core project we have a service OsVersionService.cs for returning the version number:

public class OsVersionService : IOsVersionService
    public string GetVersion()
        return SystemInformationHandler.OSVersion;

Reference the OSVersion.Core library as binary – DO NOT reference it as project or you will be facing compile errors in one of the next steps. Don’t ask me how I know Winking smile

Because all our assemblies of the OSVersion library will be compiled to assemblies with the same name we can’t just simply reference the project file but have to add the binary i.e. the compiled version of the library. If you are looking at the sample from GitHub, make sure to compile the solution under release build as the OSVersion is referenced via binary in the release output folder of the projects.

The method invokes the OSVersion property in the OSVersion library - leaving out the specific project e.g. UWP intent fully here. On the clients for example the Android app we have a single screen showing the version number defined in the MainView.xaml:

    DataContext="{Binding Source={StaticResource Locator}, Path=Main}"

    <Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
        <TextBlock Text="{Binding OSVersion}" VerticalAlignment="Center" HorizontalAlignment="Center" Style="{StaticResource TitleTextBlockStyle}"></TextBlock>

And the corresponding code behind or as we are using view models MainViewModel.cs:

public class MainViewModel : ViewModelBase
    private readonly IOsVersionService _osVersionService;

    public MainViewModel(IOsVersionService osVersionService)
        if (osVersionService == null) throw new ArgumentNullException(nameof(osVersionService));
        _osVersionService = osVersionService;

    public string OSVersion => _osVersionService.GetVersion();

If we now run the app we will get the follow output:


Now this is the output we defined in the OSVersion.Core, if we now reference the binary of the OSVersion.UWP in the NativePcl.UWP project things get really interesting. Instead of receiving an error because we are adding two assemblies with the same name the compiler will prefer the platform specific library over the PCL implementation. And even though we never invoke the library directly from our NativePcl.UWP app the OS version returned now is returned from the platform specific i.e. OSVersion.UWP implementation of the GetVersion() method resulting in the following output:


Now while this approach allows for writing platform independent logic in the PCL and calling platform specific implementations during runtime it is somewhat tedious as it requires that the developer will reference the correct version of the library. And all of them have the same name which is just calling for some frustrated minutes to happen due to referencing the wrong version of the library. Luckily there is a technique that allows to use the approach described above without burdening the developer consuming the library of referencing the binaries correctly. By wrapping the library in a NuGet package consuming the library is as simple as adding the package to all of your projects and the NuGet package manager will just like the build engine prefer to link the platform specific binary over the PCL library to the project. So instead of having to choose which binary to add the developer can now simply add the identical NuGet package to all of the projects and it will just work.


In this post you saw how to create APIs that can be consumed in the PCL and still provide platform specific functionality. For all of this to work we had to set the namespace and assembly of the projects to identical names. On the consumer one can either simply add a NuGet package containing all of the implementations i.e. PCL, UWP, Android and iOS or add the binaries of the corresponding API compilation to the app implementation e.g. OSVersion.Coreto NativePcl.Core.

This approach allows you to create APIs which can be reused across multiple platforms providing the same method definitions across the platforms.

You can find the sample on GitHub. (make sure to compile it first as a release build)


This has been driving me bonkers the last couple of days so I just wanted to jot down the steps to get the Emulator up and running under Windows 10. In my case after upgrading from Win 8.1. So if you ever received one of the following errors:

  • [Critical] An internal virtual network switch is required for emulated devices to run.
  • [Critical] XDE Exit Code: CouldntCreateInternalSwitch (16)
  • [Critical] XDE Exit Code: CouldntStartVm (10)
  • [Critical] XDE Exit Code: InvalidArguments (3)
  • For UDP connection errors see update of July 2016 at the end.

These steps should help you bring the Emulator back up and running:

Disclaimer: Please note that you perform these steps at your own risk. Generally speaking all should run just fine but some steps will remove some Hyper-V settings and this might affect your network connectivity or virtual machine setup. So take these steps as worked on my machine advice.

  1. Ensure no XDE.exe task is running (Task Manager)
  2. Repair Android SDK – Open Programs and Features > Microsoft Visual Studio Emulator for Android > select Change in the menu bar and choose Repair in the Visual Studio dialog
  3. Remove All Hyper-V virtual switches – open the  Hyper-V Manager > select the Virtual Switch Manager… (located in the menu on the right) > select each virtual switch and select remove > click onto Apply
    1. If there is an error while removing a virtual switch, try restarting your computer
  4. Run XdeCleanup.exe – Depends on your install but on the Surface Pro 3 you should find it under: "C:\Program Files (x86)\Microsoft XDE\10.0.10240.0"

Now try to get your Emulator up and running. If you still receive error messages try the following steps:

  • (Surface Pro 3) Reinstall the network drivers > Open the Device Manager> under View select Show hidden devices > Uninstall Marvell AVASTAR Wireless-AC Network Controller and Surface Ethernet Adapter > Restart which will automatically reinstall the drivers from the recovery partition
  • Clean up network bridges > Open Network Connections > Add Bridge (this option only showed up the first time) > Remove the added bridge again

Now your Emulator should fire up.


I had to repeat step 3 a couple of times – even after the emulator would start up the first time but maybe that is just a configuration issue on my machine…

Hope this helps and happy coding! Smile



Update - 20. July 2016

Managed to wreck my Android Emulator again yesterday. This time none of the above attempts fixed it for me. Since this is one of the more frequented blog posts I thought I would update to share another possible solution.

The Error message was that no UDP connection could be established with the Emulator. Following these steps solved the issue:

  • Open Device Manager (On Win10 simply search for Device Manager in the Start Menu)
  • Under Viewselect Show hidden devices
  • Delete all virtual network devices except your Network card (you do not have remove the Bluetooth devices)
  • Open Hyper-V and remove all Hyper-V virtual network endpoints as described under Point 3
  • Reboot
These steps solved the mentioned issue above and is based on the following Troubleshooting articleby Microsoft.