Category Archives: professional

Installing Windows 10 on Surface 3 with Windows To Go

I am working on a review of Surface 3, Microsoft’s recently released Atom-based tablet, and wanted to try Windows 10 on the device. How to do this though without endangering the correct functioning of my loan unit?

The ideal answer seemed to be Windows To Go (WTG), which les you run Windows from a USB drive without touching what is already installed – well, apart from a setting in control panel that enables boot from Windows to Go.


Luckily I have an approved Windows to Go USB drive, a 32GB Kingston DataTraveler Workspace. I downloaded the Windows 10 iso (64-bit, build 10074) and used the Control Panel applet on my Windows 8 desktop (which runs the Enterprise edition) to create a WTG installation.

(There are unofficial ways to get around both the requirement for Enterprise edition, and the need for an approved USB device, but I did not have to go there).

Next, I plugged the drive into the Surface 3 and restarted. Windows 10 came up immediately. An interesting feature was that I was prompted to sign into Office 365, rather than with a Microsoft account. It all seemed to work, though Device Manager showed many missing drivers.


The wifi driver must have been one of them, since I had no network.

I had anticipated this problem by downloaded the surface 3 drivers from here. These were inaccessible though, since a WTG installation by default has no access to the hard drive on the host PC. I could not plug in a second USB device with the drivers on it either, since there is only one USB port on the Surface 3.

No matter, you can mount the local drives using the Windows Disk Management utility. I did that, and ran the Surface 3 Platform Installer which I had downloaded earlier. It seemed to install lots of drivers, and I was then prompted to restart.

Bad news. When trying to restart, boot failed with an “inaccessible boot device” error.

Fool that I am, I tried this operation again with a small variation. I rebuilt the WTG drive, and instead of mounting the drives on the host, I used it first on another PC, where the wifi worked straight away. I copied the Surface 3 files to the WTG drive C, then booted it on the Surface 3. Ran the Surface 3 Platform Installer, restarted, same problem “Inaccessible boot device”.

The third time, I did not run the Surface 3 Platform Installer. Instead, I installed the drivers one by one by right-clicking on the Unknown Devices in Device Manager and navigating to the Surface 3 drivers files I had downloaded using another PC. That looks better.


I restarted, and everything still worked. I have wifi, Bluetooth, audio, cameras and everything. So something the Platform Installer tries to do breaks WTG on my device.

The next question is whether the system will update OK when set to Fast for the Windows 10 bleeding edge. So far though, so good.

Note: there is an issue with power management. If the Surface 3 sleeps, then it seems to wake up back in Windows 8 if you leave it long enough. Not too much harm done though; restart and you are back in Windows 10.

Note 2: new builds will not install on WTG, they complain about an unsupported UEFI layout

Running ASP.NET 5.0 on Nano Server preview

I have been trying out Microsoft’s Nano Server Preview and wrote up initial experiences for the Register. One of the things I mentioned is that I could not get an ASP.NET app successfully deployed. After a bit more effort, and help from a member of the team, I am glad to say that I have been successful.


What was the problem? First, a bit of background. Nano Server does not run the .NET Framework, presumably because it has too many dependencies on pieces of Windows which Microsoft wanted to omit from this cut-down deployment. Nano Server does support .NET Core, also known as Core CLR, which is the open source fork of the .NET Framework. This enables it to run PowerShell, although with a limited range of cmdlets, and my main two ways of interacting with Nano Server are with PowerShell remoting, and Windows file sharing for copying files across.

On your development machine, you need several pieces in order to code for ASP.NET 5.0. Just installing Visual Studio 2015 RC will do, except that there is currently an incompatibility between the version of the ASP.NET 5.0 .NET Core runtime shipped with Visual Studio, and what works on Nano Server. This meant that my first effort, which was to build an empty ASP.NET 5.0 template app and publish it to the file system, failed on Nano Server with a NativeCommandError.

This meant I had to dig a bit more deeply into ASP.NET 5.0 running on .NET Core. Note that when you deploy one of these apps, you can include all the dependencies in the app directory. In other words, apps are self-hosting. The binary that enables this bit of magic is called DNX (.NET Execution Environment); it was formerly known as the K runtime.

Developers need to install the DNX SDK on their machines (Windows, Mac or Linux). There is currently a getting started guide here, though note that many of the topics in this promising documentation are as yet unwritten.


However, after installation you will be able to use several handy commands:

dnvm This is the .NET Version manager. You can have several versions of the DNX runtime installed and this utility lets you list them, set aliases to save typing full paths, and manage defaults.


dnu This is the .NET Development Utility (formerly kpm) that builds and publishes .NET Core projects. The two commands I found myself using regularly are dnu restore which downloads Nuget (.NET repository) packages and dnu publish which packages an app for deployment. Once published, you will find .cmd files in the output which you use to start the app.

dnx This is the binary which you call to run an app. On the development machine, you can use dnx . run to run the console app in the current directory and dnx . web to run the web app in the current directory.

Now, back to my deployment issues. The Visual Studio templates are all hooked to DNX beta 4, and I was informed that I needed DNX beta 5 for Nano Server. I played around with trying to get Visual Studio to target the updated DNX but ran into problems so decided to ignore Visual Studio and do everything from the command line. This should mean that it would all work on Mac and Linux as well.

I had a bit of trouble persuading DNX to update itself to the latest unstable builds; the main issue I recall is targeting the correct repository. You NuGet sources must include (currently)

Since I was not using Visual Studio, I based my samples on these, Hello World Console, MVC and Web apps that you can use for testing that everything works. My technique was to test on the development machine using dnx . web, then to use dnu publish and copy the output to Nano Server where I could run ./web.cmd in a remote PowerShell session.

Note that I found it necessary to specify the CoreClr 64-bit runtime in order to get dnu to publish the correct files. I tried to make this the default but for some reason* it reverted itself to x86:

dnu publish –runtime "c:\users\[USERNAME]\.dnx\runtime\dnx-coreclr-win-x64.1.0.0-beta5-11701"

Of course the exact runtime version to use will change soon.

If you run this command and look in the /bin/output folder you will find web.cmd, and running this should start the app. The port on which the app listens is set in project.json in the top level directory of the project source. I set this to 5001, opened that port in the Windows Firewall on the Nano Server, and got a started message on the command line. However I still could not browse to the app running on Nano Server; I got a 400 error. Even on the development machine it did not work; the browser just timed out.

It turned out that there were several issues here. On the development machine, which is running Windows 10 build 10074, I discovered to my annoyance that the web app worked fine with Internet Explorer, but not in Project Spartan, sorry Edge. I do not know why.

Support also gave me some tips to get this working on Nano Server. In order for the app to work across the network, you have to edit project.json so that localhost is replaced either with the IP number of the server, or with a *. I was also advised to add dnx.exe to the allowed apps in the firewall, but I do not think this is necessary if the port is open (it is a nuisance, since the location of dnx.exe changes for every app).

Finally I was successful.

Final observations

It seems to me that ASP.NET vNext running on .NET Core has the characteristic of many open source projects, a few dedicated people who have little time for documentation and are so close to the project that their public communications assume a fair amount of pre-knowledge. The site I referenced above does have helpful documentation though, for the few topics that are complete. Some other posts I found helpful are this series by Steve Perkins, and the troubleshooting suggestions here especially David Fowler’s post.

I like The .NET Core initiative overall since I like C# and ASP.NET MVC and now it is becoming a true cross-platform framework. That said, the code does seem to be in rapid flux and I doubt it will really be ready when Visual Studio 2015 ships. The danger I suppose is that developers will try it in the first release, find lots of problems, and never go back.

I also like the idea of running apps in Nano Server, a low-maintenance environment where you can get the isolation of a dedicated server for your app at low cost in terms of resources.

No doubt though, the lack of pieces that you expect to find on Windows Server will be an issue and I am not sure that the mainstream Microsoft developer ecosystem will take to it. Aidan Finn is not convinced, for example:

Am I really expected to deploy a headless OS onto hardware where the HCL certification has the value of a bucket with a hole in it? If I was to deploy Nano, even in cloud-scale installations, then I would need a super-HCL that stress tests all of the hardware enhancements. And I would want ALL of those hardware offloads turned OFF by default so that I can verify functionality for myself, because clearly, neither Microsoft’s HCL testers nor the OEMs are capable of even the most basic test right now.

Finn’s point is that if your headless server is having networking issues it is hard to troubleshoot, since of course remote tools will not work reliably. That said, I have personally run Hyper-V Server (which is essentially Server Core with just the Hyper-V role) with great success for several years; I started keeping notes on how to troubleshoot from the command line and found solutions to common problems. If networking fails with Nano Server then yes, you have a problem, but there is always something you can do, even if it means mounting the Nano Server VHD or VHDX on another VM. Windows Server admins have become accustomed to a local GUI though and adjusting even to Server Core has not been easy.

*the reason was that I did not use the –p argument with dnvm use which would have made it persistent

Compile Android Java, iOS Objective C apps for Windows 10 with Visual Studio: a game changer?

Microsoft has announced the ability to compile Windows 10 apps written in Java or C++ for Android, or in Objective C for iOS, at its Build developer conference here in San Francisco.

Objective C code in Visual Studio

The Android compatibility had been widely rumoured, but the Objective C support not so much.

This is big news, but oddly the Build attendees were more excited by the HoloLens section of the keynote (3D virtual reality) than by the iOS/Android compatibility. That is partly because this is the wrong crown; these are the Windows faithful who would rather code in C#.

Another factor is that those who want Microsoft’s platform to succeed will have mixed feelings. Is the company now removing any incentive to code dedicated Windows apps that will make the most of the platform?

Details of the new capabilities are scant though we will no doubt get more details as the event progresses. A few observations though.

Microsoft is trying to fix the “app gap”, the fact that both Windows Store and Windows Phone Store (which are merging) have a poor selection of apps compared to iOS or Android. Worse, many simply ignore the platforms as too small to bother with. Lack of apps make the platforms less attractive so the situation does not improve.

The goal then is to make it easier for developers to port their code, and also perhaps to raise the quality of Windows mobile apps by enabling code sharing with the more important platforms.

There are apparently ways to add Windows-specific features if you want your ported app to work properly with the platform.

Will it work? The Amazon Fire and the Blackberry 10 precedents are not encouraging. Both platforms make it easy to port Android apps (Amazon Fire is actually a version of Android), yet the apps available in the respective app stores are still far short of what you can get for Google Android.

The reasons are various, but I would guess part of the problem is that ease of porting code does not make an unimportant platform important. Another factor is that supporting an additional platform never comes for free; there is admin and support to consider.

The strategy could help though, if Microsoft through other means makes the platform an attractive target. The primary way to do this of course is to have lots of users. VP Terry Myerson told us that Microsoft is aiming for 1 billion devices running Windows 10 within 2-3 years. If it gets there, the platform will form a strong app market and that in turn will attract developers, some of whom will be glad to be able to port their existing code.

The announcement though is not transformative on its own. Microsoft still has to drive lots of Windows 10 upgrades and sell more phones.

Visual Studio Code: an official Microsoft IDE for Mac, Windows, Linux

Microsoft has announced Visual Studio Code, a cross-platform, code-oriented IDE for Windows, Mac and Linux, at its Build developer conference here in San Francisco.


Visual Studio Code is partly based on the open source projects Omnisharp. It supports Intellisense code completion, GIT source code management, and debugging with break points and call stack.

I have been in San Francisco for the last few days and the dominance of the Mac is obvious. Sitting in a cafe in the Mission district I could see 10 Macs and no PCs other than my own Surface Pro. Some folk were coding too.

It follows that if Microsoft wants to make a go of cross-platform C#, and development of ASP.NET MVC web applications beyond the Windows developer community, then tooling for the Mac is important.


Visual Studio Code is free and is available for download here.

The IDE will lack the rich features and templates of the full Visual Studio, but if it is fast and clean, some Visual Studio developers may be keen to give it a try as well.

Microsoft takes its .NET runtime open source and cross-platform, announces new C++ compilers for iOS and Android: unpacking today’s news

Microsoft announced today that the .NET runtime will be open source and cross-platform for Linux and Mac. There are a several announcements and it is potentially confusing, so here is a quick summary.

The .NET runtime, also known as the CLR (Common Language Runtime) is the virtual machine that runs Microsoft’s C#, F# and Visual Basic .NET languages, performing just –in-time compilation to native code and providing interop between the application code and the operating system APIs. It is distinct from the .NET Framework, which is the library of mostly C# code that underlies application platforms like ASP.NET, Windows Presentation Foundation (WPF), Windows Forms, Windows Communication Foundation and more.

There is is already a cross-platform version of .NET, an open source project called Mono founded by Miguel de Icaza in 2001, not long after the first preview release of C# in 2000. Mono runs on Linux, Mac and Windows. In addition, de Icaza is co-founder of Xamarin, which uses Mono together with its own technology to compile C# for iOS, Android and Mac OS X.

Further, some of .NET is already open source. At Microsoft’s Build conference earlier this year, Anders Hejlsberg made the Roslyn project, the compiler for the next generation of the .NET Runtime, open source under the Apache 2.0 license. I spoke to Hejlsberg about the announcement and wrote it up on the Register here. Note the key point:

Since Roslyn is the compiler for the forthcoming C# 6.0, does that mean C# itself is now an open source language? “Yes, absolutely,” says Hejlsberg.

What then is today’s news? Blow by blow, here are what seems to me the main pieces:

  • The CLR itself will be open source. This is the C++ code from which the CLR is compiled.
  • Microsoft will provide a full open source server stack for Mac and Linux including the CLR. This will not include the frameworks for client applications; no Windows Forms or WPF. Rather, it is the “.NET Core Runtime” and “.NET Core Framework”. However Microsoft is working with the Mono team which does support client applications so there could be some interesting permutations (bear in mind that Mono also has its own runtime). However Microsoft is focused on the server stack.
  • Microsoft will release C++ frameworks and compilers for iOS and Android, using the open source Clang (C and C++ compiler front-end) and LVVM (code generation back end), but with Visual Studio as the IDE. If you are targeting iOS you will need a Mac with a build agent, or you can use a cloud build service (see below). The Android compiler is available now in preview, the iOS compiler is coming soon. “You can edit and debug a single set of C++ source code, and build it for iOS, Android and Windows,” says Microsoft’s Soma Somasegar, corporate VP of the developer division.
  • Microsoft has a new Android emulator for Windows based on Hyper-V. This will assist with Android development using Cordova (the HTML and JavaScript approach also used by PhoneGap) as well as the new C++ option.


  • The next Visual Studio will be called Visual Studio 2015 and is now available in preview; download it here.
  • There will be a thing called Connected Services to make it easier to code against Office 365, Salesforce and Azure
  • A new edition of Visual Studio 2013, called the Community Edition, is now available for free, download it here. The big difference between this and the current Express editions is first that the Community Edition supports multiple target types, whereas you needed a different Express edition for Web applications, Windows Store and Phone apps, and Windows desktop apps.  Second, the Community Edition is extensible so that third parties can create plug-ins; today Xamarin was among the first to announce support. There may be some license restrictions; I am clarifying and will update later.
  • New Cloud Deployment Projects for Azure enable the cloud infrastructure associated with a project to be captured as code.
  • Release Management is being added to Visual Studio Online, Microsoft’s cloud-hosted Team Foundation Server.
  • Enhancements to the Visual Studio Online build service will support builds for iOS and OS X
  • Visual Studio 2013 Update 4 is complete. This is not a big update but adds fixes for TFS and Visual C++ as well as some new features in TFS and in GPU performance diagnostics.

The process by which these new .NET projects will interact with the open source community will be handled by the .NET Foundation.

What is Microsoft up to?

Today’s announcements are extensive, but with two overall themes.

The first is about open sourcing .NET,  a process that was already under way, and the second is about cross-platform.

It is the cross-platform announcements that are more notable, though they go hand in hand with the open source process, partly because of Microsoft’s increasingly close relationship with Mono and Xamarin. Note that Microsoft is doing its own C++ compilers for iOS and Android, but leaving the mobile C# and .NET space open for Xamarin.

By adding native code iOS and Android mobile into Visual Studio, Microsoft is signalling real commitment to these platforms. You could interpret this as an admission that Windows Phone and Windows tablets will never reach parity with their rivals, but it is more a consequence of the company’s focus on cloud, and in particular Office 365 and Azure. The company is prioritising the promotion of its cloud services by providing strong tooling for all major client platforms.

The provision of new Microsoft server-side .NET runtimes for Mac and Linux is a surprise to me. The Mac is not much used as a server but very widely used for development. Linux is an increasingly important operating system within the Azure cloud platform.

A side effect of all this is that the .NET Framework may finally fulfil its cross-platform promise, something Microsoft suppressed for years by only supporting it on Windows. That is good news for those who like programming in C#.

The .NET Framework is changing substantially in its next version. This is partly because of the Roslyn compiler, which is itself written in C# and opens up new possibilities for rich refactoring and code transformation; and partly because of .NET Core and major changes in the forthcoming version of ASP.NET.

Is Microsoft concerned that by supporting Linux it might reduce the usage of Windows Server? “In Azure, Windows and Linux are a core part of our platform,” Somesegar told me. “Helping developers by providing a good set of tools and letting them decide what server they run on, we feel is all goodness. If you want a complete open source platform, we have the tools for them.”

How big are these announcements? “I would say huge,”  Somasegar told me, “What is shows is that we are not being constrained by any one platform. We are doing more open source, more cross-platform, delivering Visual Studio free to a broader set of people. It’s all about having a great developer offering irrespective of what platform they are targeting or what kind of app they are building.”

That’s Microsoft’s perspective then. In the end, whether you interpret these moves as a sign of strength or weakness for Microsoft, developers will gain from these enhancements to Visual Studio and the .NET platform.

Coding Office for cross platform: Microsoft explains its approach

At last month’s @Scale conference in San Francisco, developers from a number of well-known companies (Google, Facebook, Twitter, Dropbox and others) spoke about the challenge of scaling applications and services to millions or even billions of users.

Among the speakers was Igor Zaika, Distinguished Engineer in the Microsoft Office team, and the video (embedded below) is illuminating not only as an example of how to code across multiple platforms, but also as an insight into where the company is taking Office.

Zaika gives a brief résumé of the history of Office, mentioning how the team has experienced the highs and lows of cross-platform code. Word 6.0 (1993) was great on Windows but a disaster on the Mac. The team built an entire Win32 emulation layer for the Mac, enabling a high level of code reuse, but resulting in a poor user experience and lots of platform-specific bugs and performance issues in the Mac version.

Next came Word 98 for the Mac, which took the opposite approach, forking the code to create an optimized Mac-specific version. It was well received and great for user experience, but “it was only fun for the first couple of years,” says Zaika. As the Windows version evolved, merging code from the main trunk into the Mac version became increasingly difficult.

Today Microsoft is committed not only to Mac and Windows versions of Word, but to all the major platforms, by which Zaika means Apple (including iOS), Android, Windows (desktop and WinRT) and Web. “If we don’t, we are not going to have a sustainable business,” he says.

WinRT is short for the Windows Runtime, also known as Metro, or as the Store App platform. Zaika says that the relationship between WinRT and Win32 (desktop Windows) is similar to that between Apple’s OS X and iOS.

Time for a brief digression of my own: some observers have said that Microsoft should have made a dedicated version of Windows for touch/mobile rather than attempting to do both at once in Windows 8. The truth is that it did, but Microsoft chose to bundle both into one operating system in Windows 8. Windows RT (the ARM version used in Surface RT) is a close parallel to the iPad, since only WinRT apps can be installed. What seems to be happening now is that Windows Phone and Windows RT will be merged, so that the equivalence of WinRT and iOS will be closer and more obvious.

Microsoft’s goal with Office is to achieve high content fidelity and consistency of functionality across all platforms, but to use native UX/UI frameworks so that each version integrates properly with the operating system on which it runs. The company also wants to achieve a faster shipping cycle; the traditional two-year cycle is not fast enough, says Zaika.

What then is Microsoft’s technical strategy for cross-platform Office now? The starting point, Zaika explains, is a shared core of C++ code. Office has always been written in C/C++, and “that has worked out well for us,” he says, since it is the only language that compiles to native code across all the platforms (web is an exception, and one that Zaika did not talk much about, except to note the importance of “shared service code,” cloud-based code that is used for features that do not need to work offline).

In order for the shared non-visual code to work correctly cross-platform, Microsoft has a number of platform abstraction layers (PALs). No #ifdefs (to handle platform differences) are allowed in the shared code itself. However, rather than a monolithic Win32 emulation as used in Word 6.0 for the Mac, Microsoft now has numerous mini-PALs. There is also a willingness to compromise, abandoning shared code if it is necessary for a good platform experience.


How do you ensure cross-platform fidelity in places where you cannot share code? The alternative is unit testing, says Zaika, and there is a strong reliance on this in Office development.

There is also an abstraction layer for document rendering. Office requires composition, animation and touch APIs on each platform. Microsoft uses DirectX on Win32, a thin layer over Apple’s CoreAnimation API on Mac and iOS, a thin layer over XAML on WinRT, and a thinnish layer over Java on Android.

The outcome of Microsoft’s architectural work is a high level of code sharing, despite the commitment to native frameworks for UX. Zaika showed a slide revealing code sharing of over 95% for PowerPoint on WinRT and Android.


What can Microsoft-watchers infer from this about the future of Office? While there are no revelations here, it does seem that work on Office for WinRT and for Android is well advanced.

Office for WinRT has implications for future Windows tablets. If a version of Office with at least the functionality of Office for iPad runs on WinRT, there is no longer any need to include the Windows desktop on future Windows tablets – by which I mean not laptop replacements like Surface 3.0, but smaller tablets. That will make such devices less perplexing for users than Surface RT, though with equivalent versions of Office on both Android and iOS tablets, the unique advantages of Windows tablets will be harder to identify.

Thanks to WalkingCat on Twitter for alerting me to this video.

Xamarin Evolve: developers enjoy the buzz around cross-platform coding with C#

“It’s like a Microsoft developer event back when they were good,” one exhibitor here at Xamarin Evolve in Atlanta told me, and I do see what he means. There is plenty of buzz, since Xamarin is just three years old as a company and growing fast; there is the sense of an emerging technology, and that developers are actually enjoying their exploration of what they can do on today’s mobile devices.

Microsoft is an engineering-led company and was more so in its early days. The same is true of Xamarin. It also also still small enough that everyone is approachable, including co-founders Miguel de Icaza and Nat Friedman. The session on what’s new in Xamarin.Mac and Xamarin.iOS was presented by de Icaza, and it is obvious that he is still hands-on with the technology and knows it inside out. Developers warm to this because they feel that the company will be responsive to their needs.


Approachability is important, because this is a company that is delivering code at breakneck speed and bugs or known issues are not uncommon. A typical conversation with an attendee here goes like this:

“How do you find the tools?” “Oh, we like them, they are working well for us. Well, we did find some bugs, but we talked to Xamarin about them and they were fixed quickly.”

Xamarin’s tools let you write C# code and compile it for iOS, Android and Mac. If you are building for Windows Phone or Windows, you will probably use Microsoft’s tools and share non-visual C# code, though the recently introduced Xamarin Forms, a cross-platform XML language for defining a user interface, builds for Windows Phone as well as iOS and Android.

The relationship with Microsoft runs deep. The main appeal of the tools is to Microsoft platform developers who either want to use their existing C# (or now F#) skills to respond to the inevitable demand for iOS and Android clients, or to port existing C# code, or to make use of existing C# libraries to integrate with Windows applications on the server.

That said, Xamarin is beginning to appeal to developers from outside the Microsoft ecosystem and I was told that there is now demand for Xamarin to run introductory C# classes. Key to its appeal is that you get deep native integration on each platform. The word “native” is abused by cross-platform tool vendors, all of whom claim to have it. In Xamarin’s case what it means is that the user interface is rendered using native controls on each platform. There are also extensive language bindings so that, for example, you can call the iOS API seamlessly from C# code. Of course this code is not cross-platform, so developers need to work out how to structure their solutions to isolate the platform-specific code so that the app builds correctly for each target. The developers of Wordament, a casual game which started out as a Windows Phone app, gave a nice session on this here at Evolve.

Wordament has an interesting history. It started out using Silverlight for Windows Phone and Google App Engine on the server. Following outages with Google App Engine, the server parts were moved to Azure. Then for Windows 8 the team ported the app to HTML and JavaScript. Then they did a port to Objective C for iOS and Java for Android. Then they found that managing all these codebases made it near-impossible to add features. Wordament is a network game where you compete simultaneously with players on all platforms, so all versions need to keep tightly in step. So they ported to Xamarin and now it is C# on all platforms.. 

I digress. The attendees here are mostly from a Microsoft platform background, and they like the fact that Xamarin works with Visual Studio. This also means that there are plenty of Microsoft partner companies here, such as the component vendors DevExpress, Syncfusion, Infragistics and ComponentOne. It is curious: according to one of the component companies I spoke to, Microsoft platform developers get the value of this approach where others do not. They have had only limited success with products for native iOS or Android development, but now that Xamarin Forms has come along, interest is high.

Another Microsoft connection is Charles Petzold – yes, the guy who wrote Programming Windows – who is here presenting on Xamarin Forms and signing preview copies of his book on the subject. Petzold now works for Xamarin; I interviewed him here and hope to post this soon. Microsoft itself is here as well; it is the biggest sponsor and promoting Microsoft Azure along with Visual Studio.

Xamarin is not Microsoft though, and that is also important. IBM is also a big sponsor, and announced a partnership with Xamarin, offering libraries and IDE add-ins to integrate with its Worklight mobile-oriented middleware. Amazon is here, promoting both its app platform and its cloud services. Google is a sponsor though not all that visible here; Peter Friese from the company gave a session on using Google Play Services, and Jon Skeet also from Google presented a session, but it was pure C# and not Google-specific. Salesforce is a sponsor because it wants developers to hook into its cloud services no matter what tool they use; so too is Dropbox.


Most of the Xamarin folk use Macs, and either use Xamarin Studio (a customised version of the open source MonoDevelop IDE), or Visual Studio running in a virtual machine (given that the team mostly use Macs, this seems to me the preferred platform for Xamarin development, though Visual Studio is a more advanced IDE so you will probably end up dipping in and out of Windows/Mac however you approach it).

Xamarin announced several new products here at Evolve; I gave a quick summary in a Register post. To be specific:

  • A new fast Android emulator based on Virtual Box
  • Xamarin Sketches for trying out code with immediate analysis and execution
  • Xamarin Profiler
  • Xamarin Insights: analytics and troubleshooting for deployed apps

Of these, Sketches is the most interesting. You write snippets of code and the tool not only executes it but does magic like generating a graph from sequences of data. You can use it for UI code too, trying out different fonts, colours and shapes until you get something you like. It is great fun and would be good for teaching as well; maybe Xamarin could do a version for education at a modest price (or free)?


I am looking forward to trying out Sketches though I have heard grumbles about the preview being hard to get working so it may have to wait until next week.


Microsoft releases WinJS cross-browser JavaScript library but why?

Microsoft has announced WinJS 3.0:

The Windows Library for JavaScript (WinJS) project is pleased to announce the general availability of its first release – WinJS 3.0 – since the open source project began at //BUILD 2014.

Much of WinJS will run on any modern browser but the browser support matrix has a number of gaps:


You can also see what runs where from this status table.

But what is WinJS? Note that it comes from the Windows apps team, not the web development team at Microsoft. WinJS was designed to enable app development for Windows 8 “Metro” (also known as the Windows Runtime) using JavaScript, CSS and HTML. Back in 2010, when Microsoft signalled the end of Silverlight and the rise of HTML 5 for browser-based applications, early versions of WinJS would already have been in preparation. Using WinJS you can share code across a Windows 8 app, web apps, and via an app packager like Apache Cordova, in apps for Android and iOS as well.

Note that Cordova is now integrated into Visual Studio, using the catchy name Multi-Device Hybrid App:


If you want to know what kind of controls and components are on offer in WinJS, you can find out using the excellent demo site here. This is Firefox:


Quick summary then: WinJS lets you build apps that look like Windows 8 Store apps, but which run cross-browser and cross-platform. But who wants to do that?

Maybe Microsoft does. The messaging from the company, especially since CEO Satya Nadella took over from Windows guy Steve Ballmer, is “any device”, provided of course that they hook up to Microsoft’s services. That messaging is intended for developers outside the company too. Check out the current campaign for Microsoft Azure, which says “consume on any device”.


This could be a web application, or it could be a client app using Azure Mobile Services or an ASP.NET Web API application to connect to cloud data.

You do not have to use WinJS to consume Microsoft’s services of course. Why would developers want to use the look and feel of a rather unloved app platform, rather than the native look and feel of Android or iOS? That is an excellent question, and in most cases they will not. There could be cases though, for example for internal business apps where users care most about functionality. What is the current stock? What is the lead time? Show me this customer’s order history. A WinJS app might not look right for the platform, but the UI will be touch-friendly, and ease of rollout across the major mobile platforms could trump Apple’s design guidelines.

If you are writing a pure web application, users expectations concerning native look and feel are not so high. The touch-oriented design of WinJS is its main appeal, though other web frameworks like JQuery Mobile also offer this. The “Metro” design language is distinctive, and Microsoft will be making a renewed push for Windows Store apps, or Universal Apps, as part of the new wave of Windows called Windows 9 or “Threshold”. WinJS is the way to build apps for that platform using JavaScript and HTML, with the added bonus of easy porting to a broad range of devices.

This is a hard sell though. I am impressed by the effort Microsoft has put into making WinJS work cross-platform, but will be surprised to see much usage outside Windows Store apps (including Windows Phone). On the other hand, it does help to keep the code honest: this really is HTML and JavaScript, not just a wrapper for Windows Runtime APIs.

Lifetime registration as a Windows Store developer, now from £12

Microsoft has removed some friction from developing for the Windows Store (whether phone or Windows 8) by removing the requirement to pay an annual subscription:

As we continue to execute on the vision to integrate the Windows and Windows Phone developer experiences, we have taken another step by moving to a one-time lifelong Dev Center registration fee.

says Microsoft’s Todd Brix in a post today. He adds that the 600,000 developers already registered are covered, with no additional fee required.

How much is the fee? Brix does not say, and I could not find it quickly, so I started the signup process. I was offered individual registration for just £12.00. A company registration is £65.00.


Both fees are of course negligible for a developer, compared to the cost of developing an app that is worth installing. Considering that Microsoft has had problems with junk apps filling its store, you could argue that fees are justifiable as a means of restraining the flow of meaningless or malicious apps.

The counter-argument is that fees deter developers from getting started, and that today’s hobbyist may come up with the next Minecraft. It is better to control quality with a robust checking process before apps are admitted into the store.

I had a quick glance today, and have the impression that Microsoft has made progress in removing the worst offenders, following some agitation at the end of last month.

Microsoft is laying the foundation for another go at its app platform with the launch of Windows 9, about which we will hear more in a couple of weeks time.

Microsoft integrates Azure websites with hybrid cloud

Microsoft has announced the integration of Azure websites with Azure virtual networks, including access to on-premise resources if you have a site-to-site VPN.

The Virtual Network feature grants your website access to resources running your VNET that includes being able to access web services or databases running on your Azure Virtual Machines. If your VNET is connected to your on premise network with Site to Site VPN, then your Azure Website will now be able to access on premise systems through the Azure Websites Virtual Network feature.

Azure websites let you deploy web applications running on IIS (Microsoft’s web server) hosted in Microsoft’s cloud. The application platform can be framework can be ASP.NET, Java, PHP, Node.js or Python. There are Free, Shared and Basic tiers which are mainly for prototyping, and a Standard tier which has auto-scaling features, managed through Microsoft’s web portal:


The development tool is Visual Studio, which now has strong integration with Azure.

Integration with virtual networks is a significant feature. You could now host what is in effect an intranet application on Azure if it is convenient. If it is only used in working hours, say, or mainly used in the first couple of hours in the morning, you could scale it accordingly.

Have a look at that web configuration page above, and compare it with the intricacies of System Center. It is a huge difference and shows that some parts of Microsoft have learned that usability matters, even for systems aimed at IT professionals.