I just finished publishing a body of content on unit testing for JavaScript in the context of Apache Cordova, including both command-line and Visual Studio interfaces. I had a lot of fun learning about the subject and finding ways to communicate a number of concepts. I also found a direct example of a slight difference between JS runtimes that can bite you, but I'll leave that for the articles themselves.

You can find it all on http://taco.visualstudio.com/, the docs site for the Visual Studio Tools for Apache Cordova, under the "Test" node. Here are the individual topics:

There are two other topics in that node that I'll be revising and/or integrating into the stuff above: Test Apache Cordova apps with Karma and Jasmine and Test Apache Cordova apps with Chutzpah.

I'd love to know what you think, as this material is easily the basis for a video course with Microsoft Virtual Academy as well.

In January I'll start diving into UI testing for mobile–should be fun!

Microsoft's Developer Division just hosted its second Connect(); event, which I suspect many of you have been following on http://www.visualstudio.com/connect2015.

I got to be in the heart of things this year. I've been temporarily managing the Visual Studio Blog while Radhika Tadinada, the PM who owns it, is out on maternity leave until about March enjoying her adorable little baby girl. For Connect();, this meant two things. First was managing the content for the VS blog itself, which included working closely with John Montgomery on posts like his news/announcement rollup. Second was that I coordinated the efforts of all the other blogs that are represented on the header menu on the blog site…and that was quite a few of them!

Anyway, I compiled a list of all the blogs that went out yesterday for Connect(); and wanted to share that here.

Announcing .NET Core and ASP.NET 5 RC
Entity Framework 7 RC1 Available

App Insights and HockeyApp
Introducing Mobile DevOps with Visual Studio Team Services and HockeyApp
Deep Diagnostics for Web Apps with Application Insights
Azure Diagnostics Integration with Application Insights

Apps for Windows
Vungle SDK for Windows 10 Released
November improvements in Dev Center: submission, promotion and developer agreement
Windows Bridge for iOS: Where we are and where we are headed

Azure and Azure SDK
Azure: The cloud for any app and every developer
Public preview of Azure Service Fabric
Public preview of Azure DevTest Labs
Announcing the Azure SDK 2.8 for .NET

Brian Harry
News from Connect(); 2015

Announcing the VS GDB Debugger extension

Introducing the Microsoft Graph

Visual Studio
News and Announcements at Connect(); //2015
Node.js Tools 1.1 for Visual Studio Released
Announcing the Intune App SDK

Visual Studio Code
Announcing Visual Studio Code Beta

Web Development
Announcing ASP.NET 5 Release Candidate 1

Visual Studio ALM
Getting Started with DevTest Lab for Azure
MacinCloud Visual Studio Team Services Build and Improvements to iOS Build Support
Announcing Public Preview for Visual Studio Team Services Code Search
Announcing the new Release Management service in Visual Studio Team Services
Subversion integration with Visual Studio Team Services
Announcing Public Preview of Visual Studio Marketplace
Announcing easy to use browser-based exploratory testing for Visual Studio Team Services
Git Credential Manager for Mac and Linux
Test Results in Build

Xamarin (I didn't have anything to do with this one, but it's referenced from the VS blog, so I’m including here)
Introducing Xamarin 4

Update: with Eric’s comment, we’ve worked out how to make SQLite work properly with Xamarin without playing versioning games. The instructions can be found on http://developer.xamarin.com/guides/cross-platform/xamarin-forms/windows/samples/#sqlite, with thanks to Craig Dunn. The short of it is that you want to add SQLite.net-PCL from NuGet, then separately add a reference to Microsoft Visual C++ 2013 Runtime.

We return you now to the original post…


The last few weeks I’ve been making significant revisions to a Xamarin project based on code review feedback. This project is part of a larger effort that we’ll be presenting in a couple MSDN Magazine articles starting in August.

One big chunk of work was cleaning up all my usage of async APIs, and properly structuring tasks+await to do background synchronization between the app’s backend and its local cache for offline use. The caching story will be a main section in Part 2 of the article, but the story of cleaning up the code is something I’ll write about here in a couple of posts.

The first bit of that story is my experience–or struggle–to find the right variant of SQLite to use in the app. As you might have experienced yourself, quite a few SQLite offerings show up when you do a search in Visual Studio’s NuGet package manager. In our project, I started with SQLite.Net-PCL, which looked pretty solid and is what one of the Xamarin samples itself used.

However, I ran into some difficulties (I don’t remember what, exactly) when I started trying to use the async SQLite APIs.
On Xamarin’s recommendation I switched to the most “official” variant, sqlite-net-pcl, which also pulls in SQLitePCL.raw_basic.0.7.1. Keep this version number in mind because it’s important here in a minute.

This combination worked just fine for Android and iOS projects, but generated a warning for Windows Phone: Some NuGet packages were installed using a target framework different from the current target framework and may need to be reinstalled. Packages affected: SQLitePCL.raw_basic.

This is because SQLitePCL.raw.basic is marked for Windows Phone 8.0 but not 8.1, which is what my Windows Phone project in the solution was targeting.

OK, fine, so I went to the NuGet package manager, saw an update for the 0.8 version of SQLitePCL.raw.basic, and installed that. No more warning but…damn…the app no longer ran on Windows Phone at all! Instead, the first attempt to access the database threw a System.TypeInitializationException, saying “The type initializer for ‘SQLitePCL.raw’ threw an exception.” The inner exception, System.IO.FileNotFoundException, had the message, “The specified module could not be found. (Exception from HRESULT: 0x8007007E).”

What’s confusing in this situation is that SQLitePCL.raw does not appear in the Windows Phone project’s references alongside sqlite-net, as it does in the Android and iOS projects. This is, from what I can see, because the Windows Phone version of sqlite-net does some auto-gen or the raw DLL or has pre-built versions in its own package, so a separate reference isn’t necessary. (If you know better, please comment.)

Still, those DLLs were right there in the package and I couldn’t for the life of me figure out why it couldn’t find them, so I resorted to the tried and true method of trying to repro the failure from scratch with a new project, where the default Windows Phone project targeted 8.0. I then added “SQLite-net PCL” to all the projects in the solution, which brought in the raw 0.7.1 dependency, tossed in a couple APIs calls to create and access the database, and gave it an F5. Cool, everything worked.

Next, I retargeted the Windows Phone project to 8.1 and F5’d again. Everything still worked, but I got the warning about SQLitePCL.raw.basic once again. Apparently it’s OK to ignore that one.

I then updated SQLitePCL.raw to the 0.8 version and boom–got the exception again, so clearly there’s an incompatibility or bug in the 0.8 version with Windows Phone 8.1.

Clearly, then, the solution is to altogether avoid using the 0.8 version with a WP8.1 target, and if you want to suppress the warning, open packages.config in the Windows Phone project and have the SQLitePCL.raw_basic line read as follows:

<package id=”SQLitePCL.raw_basic” version=”0.7.1″ targetFramework=”wp80″ requireReinstallation=”False” />

Many of you have probably seen this already–an article that I wrote (with contributions from my teammate, Mike Jones), for MSDN Magazine.


I expect to be writing for MSDN more because my larger team at Microsoft owns the content calendar now!


I've been banging my head into my desk quite a bit with this one, and finally found the answer (and of course, it was after all of this that I found Xamarin's page on Configuring TFS!). I set up a TFS build server to test continuous integration features of Visual Studio and Team Foundation Server (TFS) with Xamarin projects. On the server I installed TFS 2013 Express along with Visual Studio Ultimate 2013 Update 4 and the Xamarin tools. I confirmed that I was able to build the Xamarin project on that machine directly. So far so good.

I then connected to the team project from another machine and set up a build definition to the server. I had a couple of issues there that took some wrangling that I'll come back to shortly. The biggest headache was that I got this error from the builds:

C:Program Files (x86)MSBuildXamarinAndroidXamarin.Android.Common.targets (379): The Android SDK Directory could not be found. Please set via /p:AndroidSdkDirectory.

This turns out to the be the right option if you're just building locally, but there's a little more to it. First, if you're building locally and get this error, make sure that you have the appropriate API level of the Android SDK installed, because it could be that MSBuild is finding the SDK folder but not the right version.

Second, you add this switch in the build definition under Process > Build > Advanced > MSBuild arguments. The text for that field appears like the following:


Third, with TFS there's another catch: the directory must be accessible by the build agent account and not just your user account. This bit me because I'd installed Xamarin under my user account, which ended up putting the Android SDK and NDKs underneath my c:users<username>AppData and Documents folders, respectively, which were not accessible by the build agent. In other words, the TFS build failed because of an account issue, not because the SDK wasn't there.

The solution, then, was to move the SDK and NDK into folders off the c: root. In doing so, be sure to patch up the ADT_HOME, ANDROID_NDK_PATH, and PATH environment variables to point to those new locations. I verified that a local build worked on the server after this, and then was able to successfully run the TFS build and set up continuous integration (build on check-in).

It's also possible from the Team Foundation Server Administration Console > Build Configuration section to change the account for the service. This page will identify the account under which the service will run (NT AUTHORITYNETWORK SERVICE by default). I could have set this to my own account, but that wouldn't be a workable solution in a real team environment unless you created a specific build account for this purpose.

Side Note: if you're wondering whether you can do Xamarin builds with Visual Studio Online's hosted build controller, the answer is presently no. According to the Hosted Build Controller page (visualstudio.com) and the more detailed hosted build server software list, Xamarin is not included (nor is Cordova for that matter). I imagine this will change at some point, so check those pages again to be sure. For the time being, you'll need an on-premise build server like the one I'm working with. Apparently you can also connect the on-premise server to VSO, but I haven't worked that out yet.


Back to the build definition. When I first set this up, I had a couple of issues:

  1. The default settings for the build definition gives a warning in the Source Settings section that reads: "The build definition workspace mapping contains potential problems. This build wastes time and computer resources because your working folders include the team projects, which include a Drops folder. You chould cloak the Drops folders." After several hours of "WTF?" reactions, and having no clue about a Drops folder and cloaking which answers on StackOverflow assumed, I figured it out. In Source Settings, just add another working folder with Source Control Folder set to $/<project>/Drops, and in the leftmost Status column, select Cloaked (this was not at all discoverable!).
  2. Under Build Defaults, there are options for where to place the build drops. I suggest when you're first working with TFS builds to use the "Copy build output to the server" option for simplicity. In this case, builds will go into the folder you have set up in the TFS Admin Console > Build Configuration > <server> – Agent > Properties. By default this is set to $(SystemDrive)Builds$(BuildAgentId)$(BuildDefinitionPath).
  3. If you want to place the builds on a different server/share (e.g. for distribution to testers who side-load the app), then make sure the build machine has full access/control for that share, otherwise you'll see "Access to the path is denied" errors. On the other server, right-click the shared folder, select Properties > Sharing > Advanced Sharing > Permissions. In that dialog, click Add…, and in that dialog click Object Types then check Computers. This way you can enter your <domain><build machine name>, and have it recognized. You have to do it by machine name because the NETWORK SERVICE applies only locally. (See this question on ServerFault.)

There you have it–my learnings from the past few days. I hope this helps some of you avoid similar headaches!

With my new role as a Content Developer in Microsoft's Developer Division, I'm working now with cross-platform tools like Apache Cordova and Xamarin, and dabbling a little in Unity, and also looking at the Visual Studio ALM tools and how they apply to these project types.

To help myself ramp up on Cordova, I'm in the process of migrating Here My Am!, the app that I build throughout the pages of Programming Windows Store Apps with HTML, CSS, and JavaScript, 2nd Edition, to Cordova. I can already see there will be numerous challenges to overcome, which I'll try to write about as I work through them (preview: the first post or two will be about CSS). 

For all this I'm using the Multi-Device Hybrid Apps Extension (Preview) for Visual Studio 2013 Update 3 (how's that for a name!). One thing that's immediately clear about the extension is that it saves a whole lot of trouble in getting a Cordova environment set up. Normally you have to go get a bunch of downloads from nine different places, some of which have installers and some of which are just ZIP files, and then you have to install them in the right order figure out how to configure each one with the right environment variables. The extension does that for you.

The documentation for the extension is found on http://msdn.microsoft.com/en-us/library/dn771545.aspx; the installer page specifically describes what pieces it downloads and how to do the configuration, manually. My team is, in fact, the one that produces this documentation–more to come!

In a bit of departure from my usual subject matter, I wanted to share a writeup I did for my team in regards to an Android device I acquired for the purposes of doing some dev work with Xamarin and Cordova in Visual Studio on Windows.

The Short Story:

If you are looking for an Android tablet for dev work (like for the purposes of doing Cordova and Xamarin), the most important thing is that you can find a Windows USB driver for the thing. This is what will allow you to debug from Visual Studio, Xamarin Studio, Eclipse, and so on, or, to be specific, to run the first Xamarin tutorial project through which you get to order a free (and real) C# T-shirt.

[I was aksed why I thought I needed a real device when there are emulators. Emulators only go so far and fall short of where a device actually touches the physical world, e.g. sensors, NFC, attaching via USB, using touch for real, seeing real-world performance on target devices, and just understanding how something works when you’re holding it in your hand. Also, an emulator will never give you the full end to end experience of a consumer, e.g. switching between apps, multitasking, acquiring apps from a store, etc. I wouldn't ever ship an app without at least one real device test. In my work, specifically, the people I'm writing for are using real devices and having one myself, and immediately hitting a significant challenge, gave me a much better understanding of issues that we can help those customers solve.]

Anyway, if you have any particular device in mind, check the list on http://developer.android.com/tools/extras/oem-usb.html, and follow the links to the manufacturer pages to verify the existence of an easy-to-acquire driver. If you don’t find one, look for a different device that has one, or you can enjoy the process I describe below to essentially hack one.

And when you have a device, http://developer.android.com/tools/device.html is where you find info on how to unlock a device for dev work—has the great UI of going to a specific setting and tapping it seven times!


Sidebar: Getting the Device to Show Up in the Tools

Before going into the details of hacking a driver, a little aside on running apps on an Android device from Visual Studio. Tools talk to an Android device through the Android Debug Bridge, or abd, which is managed through the command line (see http://developer.android.com/tools/help/adb.html). You can easily get to a suitable command prompt through a button that shows up in Visual Studio if you’ve installed the multi-platform hybrid app tools or the Xamarin SDK (circled below):

Android devices in VS

If the adb isn’t seeing your device (which you can check on the command line with adb devices -l), it won’t show up in the drop-down list of debug targets. If this happens, here are steps you can try:

  1. Unplug the USB cable and reattach. This might be sufficient.
  2. It might be necessary to restart Visual Studio. I’ve found that VS will refresh itself when you attached/detach a device, but if it doesn’t, there’s always a restart.
  3. Open the command prompt and do adb kill-server and then adb start-server. You might need to restart VS again.

When VS sees the device, you can then enjoy all the usual capabilities of VS. Otherwise you get stuck with emulators that you probably won’t enjoy, especially when it comes to figuring out which one has which API level support to match your code project.


The Long Story: Hacking a USB Driver

When looking for a tablet, I shopped around on Amazon to find a middle-of-the-road, reasonably-priced, name-brand tablet. In the end I chose the Asus MemoPad 7, which looked much more reliable than the really cheap tablets, but not so expensive as the mainline Google or Samsung models.

Knowing what I now know, I probably would have chosen differently, because once I figured out how to unlock the tablet as a dev device, I found that ASUS didn’t have an appropriate USB driver on its site. This also meant that plugging the device into my system for the first time didn’t manage to find a driver, thus resulting in the undesirable  !  in Device Manager.

Turning to a full web search, I found some other possibilities, and pointed Device Manager to the place where I’d downloaded the driver package. However, each one I tried gave me that annoying message, “Windows could not find a driver for your device.”

Let me get a bit technical for a minute. Every USB device is uniquely identified by a Vendor ID or VID, and a Product ID or PID. So USB device people talk of the VID/PID for any given device, which you can always find for any device (driver or not) by viewing its properties in Device Manager, switching to the Details tab, and selecting Hardware Ids from the drop-down:

VID PID in Device Manager

Here you can see that the VID is 0B05 (Asus) and the PID is 5507.

When you see the “Windows could not find a driver for your device” message, it means that the .INF file for the driver that you pointed to does not contain an entry that matches the VID/PID of the device, and Windows will refuse to install the driver. This is true even if you know damn well that the driver will work, and that the silly driver package just hasn’t been updated properly.

Which brings us to the hack, and some learnings along the way.

Now lest you think an .INF file is some kind of magic, it’s not. It’s just a plain text file that describes the VID/PID combinations with which the driver will work. For example, I found a generic Asus ADB Driver package (all tablets really work with the same driver), and it had lots of entries like this:

%CompositeAdbInterface%     = USB_Install, USBVID_0B05&PID_4DEF&MI_01

None matched the 5507 PID, however. OK, so perhaps I could just add an appropriate line in the .INF file for the right VID/PID? (Making sure to enter the line in both the .NTx86 and .NTamd64 sections of the .INF file.)

Rats. No luck. The .INF file is just an easy way to describe the driver’s supported devices, but there’s a second step that goes through a .CAT file. A .CAT file is a “Security Catalog” that, well, provides a security check. So although the .INF file will match, you’ll get a security warning and Windows will refuse the install the driver.

So….the natural question is, how do you make that .CAT file match the .INF file? It’s pretty easy, actually. The Windows Driver Kit (WDK), that’s an extra download from MSDN, has a little tool called inf2cat.exe that does exactly this.

After waiting a while for the rather large WDK to download and install, I ran the tool, produced the right .CAT file, and tried again.

Damn. Windows doesn’t like it when you don’t have a properly signed .CAT file with an appropriate security certificate.

Fortunately, someone has blogged about this exact thing: http://tivadj-tech.blogspot.in/2012/09/certificate-check-error-when-installing.html. Let me summarize:

  • Go to PC Settings > Update and Recovery > Recovery > Advanced Startup and press the Restart Now button.
  • Oh, wait a minute—be sure that you have your Bitlocker key handy because you’ll be required to enter it when the machine reboots!
  • When the machine reboots, and you enter that Bitlocker key, select Troubleshoot > Advanced Options > Startup Settings and tap Restart.
  • When the machine reboots (again, did I mention you’ll need your Bitlocker key?), you’ll have a list of choices for tweaking the boot process. Select the one that says “Disable driver signature enforcement.”

Bwah-ha-ha! Now you have power. Well, at least you have the power to install a hacked driver, meaning that Windows will allow you (with another dire warning that you get the perverse pleasure of ignoring), to install a driver using.INF and .CAT files that you rebuilt yourself.

Once I did this, Windows was happy with the Asus Memo Pad 7, and so was ADB and Visual Studio. This allowed me to finally run that first Xamarin project on my device, and order the T-shirt that was, of course, the whole point of all this!


Postscript: the Universal ADB Driver

To be honest, I didn’t end up using the ASUS driver package itself. In the course of my investigations I came across a Universal ADB Driver that works for a whole host of devices, meaning you can use this one driver for any variety of Android  devices because all those devices are basically talking to the ADB daemon running on the device once you do that seven-tappy thingy to unlock it.

The source for the driver—which really amounts to an .INF file plus copies of the generic USB driver from the Windows Driver Kit, is on GitHub: https://github.com/koush/UniversalAdbDriver. This makes it easy, and less of a hack, to modify the .INF file, rebuild the .CAT, and sign it properly. This is what I have installed now.

To be honest again, I didn’t actually get the signing certificate in the project to work, so I used advanced boot and installed the unsigned driver. Maybe someday I’ll understand this business with certificates (and I'm happy to be educated through comments–send me some links!), but I was eager to get my T-shirt.