Category Archives: visual studio

C# and .NET: good news and bad as Python rises

Two pieces of .NET news recently:

Microsoft has published a .NET Core 2.1 roadmap and says:

We intend to start shipping .NET Core 2.1 previews on a monthly basis starting this month, leading to a final release in the first half of 2018.

.NET Core is the cross-platform, open source implementation of the .NET Framework. It provides a future for C# and .NET even if Windows declines.

Then again, StackOverflow has just published a report on the most sought-after programming languages in the UK and Ireland, based on the tags on job advertisements on its site. C# has declined to fourth place, now below Python, and half the demand for JavaScript:


To be fair, this is more about increased demand for Python, probably driven by interest in AI, rather than decline in C#. If you look at traffic on the StackOverflow site C# is steady, but Python is growing fast:


The point that interest me though is the extent to which Microsoft can establish .NET Core beyond the Microsoft-platform community. Personally I like C# and would like to see it have a strong future.

There is plenty of goodness in .NET Core. Performance seems to be better in many cases, and cross-platforms is a big advantage.

That said, there is plenty of confusion too. Microsoft has three major implementations of .NET: the .NET Framework for Windows, Xamarin/Mono for cross-platform, and .NET Core for, umm, cross-platform. If you want cross-platform ASP.NET you will use .NET Core. If you want cross-platform Windows/iOS/macOS/Android, then it’s Xamarin/Mono.

The official line is that by targeting a specification (a version of .NET Standard), you can get cross-platform irrespective of the implementation. It’s still rather opaque:

The specification is not singular, but an incrementally growing and linearly versioned set of APIs. The first version of the standard establishes a baseline set of APIs. Subsequent versions add APIs and inherit APIs defined by previous versions. There is no established provision for removing APIs from the standard.

.NET Standard is not specific to any one .NET implementation, nor does it match the versioning scheme of any of those runtimes.

APIs added to any of the implementations (such as, .NET Framework, .NET Core and Mono) can be considered as candidates to add to the specification, particularly if they are thought to be fundamental in nature.

Microsoft also says that plenty of code is shared between the various implementations. True, but it still strikes me that having both Xamarin/Mono and .NET Core is one cross-platform implementation too many.

Microsoft updates the .NET stack with .NET Core 2.0 and updated Visual Studio. Should you use it?

Microsoft has released .NET Core 2.0, a major update to its open source, cross-platform version of the .NET runtime and C# language.

New features include implementation of .NET Standard 2.0 (a way of targeting code to run under multiple .NET platforms), new platform support including Debian Stretch, macOS High Sierra and Suse Linux Enterprise Server 12 SP2. There is preview support for both Linux and Windows on ARM32.

.NET Core 2.0 now supports Visual Basic as well as C# and F#. The version of C# has been bumped to 7.1, including async Main method support, inferred tuple names and default expressions.

Microsoft has also released Visual Studio 2017 15.3, which is required if you want to use .NET Core 2.0. New Visual Studio features include Azure Stack support, C’# 7.1 support, .NET Framework 4.7 support, and other new features and fixes.

I updated Visual Studio and downloaded the new .NET Core 2.0 SDK and was soon up and running.


Note the statement about “This product collects usage data” of which more below.


The sample ASP.NET MVC application worked first time.


How is .NET Core doing? The whole .NET picture is desperately confusing and I get the impression that most .NET developers, while they may have paid some attention to what is happening, have concluded that the safe path is to continue with the Window-only .NET Framework.

At the same time, .NET Core is strategically important to Microsoft. Cross-platform support means that C# has a life on the Mac and on Linux, which is vital to its health considering the popularity of the Mac amongst developers, and of Linux as a deployment platform for web applications. Visual Studio for Mac has also been updated and supports .NET Core 2.0 in the new version.

Another key piece is the container trend. .NET Core is ideal for container deployment, and the only version of .NET supported in Windows Nano Server. If you want to embrace microservices running in containers, while still developing with C#, .NET Core and Nano Server is the optimum solution.

Why not use .NET Core, especially since it is faster than ASP.NET? In these comparisons, .NET Core comes out as substantially faster than .NET Framework for various algorithms – 600 times faster in one case.

The main issue is compatibility. .NET Core is a subset of the .NET Framework, and being a relative newcomer, it lacks the same level of third-party support.

Another factor is that there is no support for desktop applications, though some solutions have been devised. Microsoft does have a cross-platform GUI story, in Xamarin Forms, which is now in preview for macOS alongside iOS, Android, Windows and Tizen. If Xamarin used .NET Core that would be a great solution, but it does not (though it does support .NET Standard 2.0).

One of the pieces that most concerns developers is data access. If you use .NET Core you are strongly guided towards Entity Framework Core, a fork of Microsoft’s ORM (Object-Relational Mapping) framework. Someone asked on this page, is EF Core usable? Here’s an answer from one user (11 days ago):

Answering 4 months later but people should know: Definitely not, it is still not usable unless you are doing something very trivial and/or have very small DB.
I don’t understand how it is possible for MS to ship it, act like it’s OK and sparsely here and there provide shallow information about its limitations like in this article without warning clearly and explicitly about the serious issues this “v1 product” has.

Someone may jump in and say no, it is fine; but there are undoubtedly missing pieces and I would suggest caution.

You can also access data using the Connection/Command/DataReader approach which avoids EF, and although this is more work, this is what I would be inclined to do personally since you get the best performance and flexibility. Here is an example for SQL Server.

Who is using .NET Core? Controversially, Microsoft gathers telemetry from your use of the command-line tools though you can opt out by setting an environment variable. This means we have some data on .NET Core usage, though unfortunately it excludes Visual Studio usage. I downloaded the most recent dataset and imported it into a database. Here are the figures for OS family:

Total rows 5,036,981
Windows 3,841,922 (76.27%)
Linux 887,750 (17.62%)
Mac 307,309 (6.1%)


Given that this excludes Visual Studio users, who are also on Windows, we can conclude that the great majority of .NET Core developers use Windows, and only a tiny minority Mac (I do not know if Visual Studio for Mac usage is included). This is evidence that .NET Core has so far failed in its goal of persuading Mac-using developers to adopt .NET. It does show interest in deploying .NET applications to Linux, which is an obvious win in licensing costs as well as performance.

I would be interested in comments from developers on whether or not they use .NET Core and why.

Xamarin Challenge shows bumps in Microsoft’s path to cross-platform mobile

Microsoft ran a Xamarin Challenge over on Paul Thurrott’s site. The idea was to demo how to build a cross-platform mobile app with Microsoft’s cross-platform mobile toolkit.

The challenge was in three steps. You build a weather app, complete with crash analytics on the Visual Studio Mobile Center.


Someone did a lot of work on this, and the app looks pretty and works nicely once you get it running.

Despite this, I am not sure that the challenge was altogether successful. It is a step-by-step which in theory involves no developer expertise as you simply copy and paste code into your project. I am not sure that is the best way to learn, but that is by the by. I doubt that learning how to code for Xamarin was the primary goal of the challenge. I’d guess it was more about showing how easily you can build a cross-platform app (Android, iOS and Windows UWP) using Xamarin, C# and Visual Studio 2017.

Well, in fact a little bit of developer expertise was required to complete the challenge, because the step by step instructions did not quite work (in my experience). I did not make a note of all the times I had to do something not in the given steps, but there were many occasions, the main issues being around using the Visual Studio Android emulator, NuGet package management, and a few small tweaks to the code itself. The code as given made no allowance for the cloud services it called being offline, or the connection to the internet not being available, but would simply crash in this case.

The challenge could be an excellent resource for Microsoft and Xamarin if the company drills down into the problems developers experienced trying to complete the challenge, recorded in this forum thread. Here are a few examples:

Myself and 5 other developers in our office attempted the challenge and none of us have been able to get past the first challenge. We are not Microsoft Visual Studio experts so we had hoped following the provided instructions would be sufficient.

The upload was failing on a discrepancy between 2 different versions of the Json package, which somehow had crept into the project. Installing over 40 updates in Nuget resolved this.

Many thanks for running this challenge –this was very useful and worthwhile. I just wish modern development did not feel like trying to dance on a mile high stack of chairs with a leg missing on the bottommost one!

I got a late start on the challenge and was able to complete part 1 pretty quickly but was only able to run the UWP locally. I cannot seem to get either the Windows mobile emulator or Android emulators to run successfully. I can’t deploy to the Window Mobile emulator, it returns an error indicating the emulator failed to start. As for the Android emulator, it launches, but the emulator does not have a connection to the network, so the application encounters an exception.

Note that those posting to the forum were more likely to be the ones with problems; there could in theory be many others who breezed through without any issues. But as one participant writes, “I’d be interested in what percentage of participants actually got to the end of the challenge with no problems.”

I like Xamarin; it does an amazing job in enabling cross-platform development with C# and it would be my tool of choice for cross-platform mobile development. It is not always straightforward though, and the kinds of issues experienced by the challenge participants illustrate what can go wrong.

If you just use the native toolkits, such as Android Studio and Xcode, you will have a smoother experience, but of course miss out on the productivity benefit of cross-platform code. That is the trade-off you make.

Adapting a native code DLL to be called from a Store or Universal Windows app

I am writing a Bridge game in C# – yes, I have been doing this for some time, it does run now but it is not ready for public unveiling.

It is good fun though and a learning experience, as I am writing it as a Windows 8 Store app. This means it can also be a Universal Windows Platform app but I have kept it compatible with Window 8.1 as I don’t want to lose that large market of Windows 8 users who have not upgraded to 10. Hmm.

Bridge is a card game in which a pack of 52 cards is dealt into 4 hands of 13 cards. Each hand is played as a sequence of 13 4-card “tricks”, and each trick is won one of two opposing pairs of players according to the cards played. Each pair of course tries to win as many tricks as possible, so one of the points of interests is how many tricks can be won if you play perfectly (ie with full knowledge of all four hands). Another point of interest is how each card played affects the potential number of tricks you can win with best play. For example, leading a King might cost you a trick (or more) if your opponents hold both the Ace and the Queen of that suit.

This is called “double dummy” analysis and smart people have written algorithms to calculate the answers. A double dummy analysis is useful in a bridge game for two reasons. One is that users may like to know, after playing a hand, what their best score could have been, or even to analyse the hand and see how if they played this card rather than that card at trick such-and-such the outcome would have varied. The other is that you can use it to assist the software in finding the best play. Of course it is important that the software plays fair by not using knowledge of all four hands beyond what would be known by human players; but it is legitimate to try out various possible hands that match what is currently known and use double dummy analysis on these hands.

One such smart person is Bo Haglund who wrote a C++ Windows library for double dummy analysis, called Double Dummy Solver (DDS) and released it as open source under the Apache 2 license. It works very well and is widely used in the Bridge software community, and has now been ported to Mac and Linux; you can find the latest code on Github.

Modifying a native code DLL to use with a Store app

I wanted to use the library in my own Bridge game but faced a compatibility problem. Windows Store apps can only call into DLLs that meet certain requirements, such as using only a subset of the Windows API, and DDS did not meet those requirements. My choice was either to port the DLL to C#, or to modify the code so that it would work as a Windows Runtime native DLL.

I have no doubt that the code could be ported to C# but it looks like rather a long job that would result in a library with slower performance (please feel free to prove me wrong). I thought it would be more realistic to modify the code, so I created a new Windows 8.1 DLL project in Visual Studio 2013 (I am now using Visual Studio 2015 but it is the same for this) and set about modifying the code so that it would compile.

In no particular order, here are some notes on what I learned.

I was able to get the DLL to compile after disabling the multi-threading support (more on this later), and commenting out some functions that I don’t yet need.

Another issue I hit was that Visual C++ by default performs “Security Development Lifecycle” checks (compile with /sdl). This means that that common functions like strcpy, strcat, sprintf and others will not compile. You have to use “secure” versions of those functions, strcpy_s, strcat_s, sprintf_s and so on. These are specific to Microsoft’s libraries though. Of course you can just not compile with /sdl, or define _CRT_SECURE_NO_WARNINGS, but I chose to fix all of these. Now the library compiled.

But did it work? No. I had introduced a stupid bug which took me a while to fix. Did it then work? Yes, but it took me some time to get it working from C#.

Next, I kept getting DLLNotFound exceptions. OK, so you have to add the DLL as content in your C# project, and make sure it is set to copy to your output. I still got DLLNotFound exceptions. It turns out that you get this exception even when the DLL is present, if there is a dependency in the DLL which is not found. What dependency was not found? I downloaded the Sysinternals Process Monitor utility and set the filter to monitor my C# game. I excluded SUCCESS results. Then I tried to load the DLL. This told me that it was looking for the file msvcr120_app.dll (the Windows Runtime version of the Visual C++ runtime library). My first thought was to add runtime libraries from the appx deployment packages, in:

C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1\ExtensionSDKs\Microsoft.VCLibs\12.0


Then I discovered that all you need to do is to add a reference to the Visual C++ runtime packages, much easier. That fixed DLLNotFound.

Next, I had some problems calling the 64-bit DLL with Platform Invoke (PInvoke) from C#. I found it easier to compile both my C# app and the DLL itself as 32-bit code. I may go back to the 64-bit option later.

Concurrency issues

Now I had everything working; except that my DDS port was far inferior to the standard one because it was single-threaded. The original used QueueUserWorkItem which is not available in a Windows Runtime DLL. I searched for what to do, and came across this MSDN article which recommends using RunAsync, WorkItemHandler and IAsyncAction. However my DLL was not currently compiled using /ZW for “Consume Windows Runtime Extension”. I could add that of course; but then my DLL would have a dependency on the Windows Runtime and if I wanted to use the code for, say, Windows 7, it would not work. or not without yet more #ifdef blocks. No big deal perhaps; but my preference was to avoid this dependency.

There may be other solutions, but the one that I found was to use the Concurrency Runtime. Previously, QueueUserWorkItem was called in a for loop. I simply modified this to use a parallel_for loop instead, using the example here for guidance. I also added:

#include <ppltasks.h>

using namespace concurrency;

to the top of the code. It works well, speeding performance by about three times on my quad-core desktop. Of course I was greatly helped by the fact that the code was already written with concurrency in mind.


The effect is spoiled by the time it takes to load the DLL but fortunately you can get DDS to solve multiple boards in one call though I have yet to experiment with this.

Microsoft completes Visual Studio 2015

Microsoft has completed Visual Studio 2015, the latest version of its all-encompassing development tool. You can download it here. Today is also the release day for TypeScript 1.5 (a language which compiles to JavaScript)


Windows 10 is released in just 9 days, so all eyes will be on this and its new/old app platform – the Universal Windows Platform, based on the Windows Runtime, as found in Windows 8, but considerably revised so that developers can in theory write one app and run it on any Windows 10 device, from PC to tablet to phone to Xbox to HoloLens, and sell or distribute it from a unified Windows Store.

Microsoft CEO Satya Nadella recently confirmed that the Windows Store is a key part of the Windows 10 strategy:

Why then make all these changes to the Start Menu with Windows 10? It’s not because I just want to bring back the old. It’s because that’s the best way to improve the liquidity [of] our store. Windows 8 was great except that nobody discovered the store. In Windows 10, the store is right there and done in a tasteful way.

The Store is more visible in Windows 10 than in 8 because in Windows 10 there are no longer two separate environments (Metro and desktop), but only one (desktop). Windows Runtime apps run in desktop windows. This makes the experience a little worse for tablet users, but the advantage is that now desktop users are more likely to interact with the Store, and more likely to use the apps they install, since they run in a familiar environment.

Another key change is “Project Centennial”, which I wrote up for the Register here. This lets developers package desktop apps for delivery from the Store, using app virtualisation (based on an Enterprise product called App-V). If Microsoft gets this right, Project Centennial will be the preferred way to deliver most desktop apps, since it is both easier and safer for the user.

If the Store does take off (and if it does not, Windows 10 will in part have failed), then Visual Studio will be the key tool for created or repackaging apps for Windows.

Windows 10 is important, but so too is Azure, Microsoft’s cloud platform. Visual Studio has a key role here, too. Microsoft has an entire stack, including Windows as both operating system and development environment, Visual Studio for coding and testing, and Azure for hosting cloud applications. Since the early days of Azure, the development experience has improved, so that with a modest understanding of the ASP.NET MVC framework you can go from an idea to a working demo, hosted on Azure, that you can show customers, in a short space of time.

There is also a new Cloud Explorer in Visual Studio which lets you view Azure resources from the IDE.


Mobile is Microsoft’s weak point, but the the company has made efforts to support Android and iOS both through mobile service back-ends hosted on Azure, and by supporting various approaches to building cross-platform apps. Visual Studio 2015 includes Xamarin project types, though out of the box these just tell you to go and install Xamarin, which lets you build Android and iOS apps with C#, subject to a separate Xamarin subscription.

Another option is to use Microsoft’s new iOS tools to code in Visual Studio while targeting Apple’s mobile platform, though this does require a Mac running a remote agent.

There is also Visual Studio Tools for Apache Cordova, where you code in JavaScript and wrap the results as native apps for both Windows and mobile platforms.

Visual Studio comes with an Android emulator, based on Hyper-V, for debugging either Xamarin or Cordova apps. Xamarin also offers its own emulator and I am not sure how these compare.

In addition to the above, Visual Studio 2015 introduces C# 6.0, Visual Basic 12, the Roslyn compiler platform which enables new IDE features, and .NET Core which is an open source, cross-platform fork of the .NET Framework. Thanks to .NET Core, the latest version of ASP.NET runs on Mac and Linux as well as Windows.

Despite Microsoft’s new cross-platform focus, Visual Studio itself runs only on Windows. In a world of Mac-wielding developers that is a problem, so the company has come up with Visual Studio code, an editor with some IDE features that runs on Window, Mac and Linux. Other options for non-Windows developers are to run Windows in an emulator such as Parallels, or on a virtual machine hosted in the code (Azure has suitable pre-baked images with Visual Studio), or to use third-party tools.

Visual Studio is a critical product then, but is it really done? Although you can download the final product today, many parts are not available (Project Centennial) or still in beta (ASP.NET 5 is beta 5). This is a milestone though, and credit to the team for bringing it out in advance of Windows 10 (I recall some Windows releases where Visual Studio was still in preview on release day).

Windows 10 at Mobile World Congress 2015: a quick reflection

I attended Mobile World Congress in Barcelona last week – with 93,000 attendees and 2,100 exhibitors according to the latest figures.

It was a big event for Microsoft’s new Windows. It started for me on the Saturday before, when Acer unveiled a low-end Windows Phone (write-up on the Reg). Next was Microsoft’s press conference; Stephen Elop was on stage, presenting two new mid-range Lumias as if nothing had changed since last year when he announced the now-defunct Nokia X:


The Lumia 640 looks good value, especially in its XL guise: 5.7” 1280 x 720 display, 8GB storage plus microSD slot, 13MP camera, 4G LTE, quad-core 1.2GHz CPU, €189 ex VAT. The smaller Lumia 640 is now on presale at £169.99; we were told €139 ex VAT at MWC, so I guess the real price of the 640XL may be something like £230, though there will be deals.

These phones will ship with Windows Phone 8.1 but get Windows 10 when available.

The big Windows 10 event was elsewhere though, and not mentioned at the press conference. This was the developer event, where General Manager Todd Brix, Director of Program Management Kevin Gallo and others presented the developer story behind the new Universal App Platform (not the same as the old Universal App Platform, as I explain here).


This was the real deal, with lots of code. There was even a hands-on session where we built our own Universal Apps in Visual Studio 2015. Note that the Visual Studio build we used featured an additional application type for Windows 10; this is not the same as a Store app in Windows 8, though both use the Windows Runtime.

As someone with hands-on experience of developing a Store app, I am optimistic that the new platform will achieve more success. It is a second attempt with a bit more maturity, and much greater effort to integrate with the Windows desktop, whereas the first iteration went out of its way not to integrate.

Much of the focus was on the Adaptive UX, creating layouts that resize intelligently on different devices. The cross-platform UI concept is controversial, with strong arguments that you only get an excellent UI if you design specifically for a device, rather than trying to make one that runs everywhere. The Universal App Platform is a bit different though, since it is all Windows Runtime. Microsoft’s pitch is that by writing to the UAP you can target desktop, Windows Phone, tablet and Xbox One, with a single code base; and without a cross-device UI this pitch would lose much of its force. Windows 7 legacy is a problem of course; but if we see Windows 10 adopted as rapidly as Windows 7 (following the Vista hiccup) this may not be a deal-breaker.

The official account of the MWC event is in Gallo’s blog post which went out on the same day. There was much more detail at the event, but Microsoft is holding this back, perhaps for its Build conference at the end of April. So in this case you had to be there.


Aside: if you look at the publicity Microsoft got from MWC, you will note that it is mostly based on the press conference and the launch of two mid-range Lumias, hardly ground-breaking. The fact that a ton of new stuff got presented at the developer event got far less attention, though of course sharp eyes like those of Mary Jo Foley was onto it. I have a bias towards developer content; but even so, it strikes me that a session of new content that is critical to the future of Windows counts for more than a couple of new Lumias. This demonstrates the extent to which the big vendors control the news that is written about them – most of the time.

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.

VLC is coming to Windows Phone

The popular media playback app VLC is coming to Windows Phone as well as Windows tablets, according to an email sent to supporters of its Kickstarter project for VLC for WinRT (Windows Runtime).

A new preview release has been made available on the Windows Store, with the following changes:

  • using libVLC 2.2.0 core,
  • redesign of the interface,
  • huge performance improvements,
  • use of Winsock for networking instead of WinRTsock,
  • use of Windows 8.1 widgets,
  • move the interface code to Universal to prepare Windows Phone 8.1 port.

The app is currently x86 only, and this will have to change before a Windows Phone version is possible, since Windows Phone currently runs only on ARM chipsets. The VLC developers say:

While this release is still x86-only, we’ve made great advances on the ARM port. More news soon.

The progress of apps like VLC will be interesting to watch following the release of Windows 10 next year, which (from the user’s perspective) blurs the distinction between desktop apps (like the old version of VLC) and Store apps (like this new one). Can the Store app be good enough that users will not feel the need to have the desktop version installed? Even if it is, of course, the desktop version will remain the only choice for those on Windows 7 and earlier. In fact, make that Windows 8.0 and earlier, since the new version requires Windows 8.1.


Book review: Professional ASP.NET MVC 5. Is this the way to learn ASP.NET MVC?

This book caught my eye because while I like ASP.NET MVC, Microsoft’s modern web application framework, it seems to be badly documented. Even the word “badly” is not quite right; there is lots of documentation, some of high quality, but finding your way around it is challenging, thanks to the many different pieces involved. When I completed an ASP.NET MVC project recently, I found it frustrating thanks to over-reliance on sample projects (hey, here is a an application we did that works, see if you can figure out how we did it), many out of date articles relating to old versions; and the opposite, posts and samples which include preview software that does not seem wise to use in production.


In my experience ASP.NET MVC is both cleaner and faster than ASP.NET Web Forms, the older .NET web framework, but there is more to learn before you can go ahead and write an application.

Professional ASP.NET MVC 5 gives you nearly 600 pages on the subject. It is aimed at a broad readership: the introduction states:

Professional ASP.NET MVC 5 is designed to teach ASP.NET MVC, from a beginner level through advanced topics.

Perhaps that is too broad, though the idea is that the first six chapters (about 150 pages) cover the basics, and that the later chapters are more advanced, so if you are not a beginner you can start at chapter 7.

The main author is Jon Galloway who is a Technical Evangelist at Microsoft. The other authors are Brad Wilson, formerly at Microsoft and now at CenturyLink Cloud; K Scott Allen at OdeToCode, David Matson who is on the ASP.NET MVC team at Microsoft, and Phil Haack formerly at Microsoft and now at GitHub. I get the impression that Haack wrote several chapters in an earlier edition of the book, but did not work directly on this one; Galloway brought his chapters up to date.

Be in no doubt: there are plenty of well-informed ASP.NET MVC people on this team.

The earlier part of the book uses a sample Music Store application, a version of which is publicly available here. You can also download a tutorial, based on the sample, written by Galloway. The public tutorial however dates from 2011 and is based on ASP.NET MVC 3 and Visual Studio 2010. The book uses Visual Studio 2013.

Chapters 1 to 6, the beginner section, do a decent job of talking you through how to build a first application. There are chapters on Controllers, Views, Models, Forms and HTML Helpers, and finally Data Annotations and Validation. It’s a good basic introduction but if you are like me you will come out with many questions, like what is an ActionResult (the type of most Controller methods)? You have to wait until chapter 16 for a full description.

Chapter 7 is on Membership, Authorization and Security. That is too much for one chapter. It is mostly on security, and inadequate on membership. One of my disappointments with this book is that Azure Active Directory hardly gets a mention; yet to my mind integration of web applications with Office 365 (which uses Azure AD) is a huge feature for Microsoft.

On security though, this is a useful chapter, with handy coverage of Cross-Site Request Forgery and other common vulnerabilities.

Next comes a chapter on AJAX with a little bit on JQuery, client-side validation, and Ajax ActionLinks. Here is the dilemma though. Does it make sense to cover JQuery in detail, when this very popular open source library is widely documented elsewhere? On the other hand, does it make sense not to cover JQuery in detail, when it is usually a vital part of your ASP.NET MVC application?

I would add that this title is poor on design aspects of a web application. That said, I was not expecting much on the design side; but what would help would be coverage of how to work with designers: what is safe to hand over to designers, and how does a typical designer/developer workflow play out with ASP.NET MVC?

I would also like to see more coverage of how to work with Bootstrap, the CSS framework which is integrated with ASP.NET MVC 5 in Visual Studio. I found it a challenge, for example, to discover the best way to change the default fonts and colours used, which is rather basic.

Chapter 9 is on routing, dry but essential background. Chapter 10 on NuGet, the Visual Studio package manager, and a good chapter given how important NuGet now is for most Visual Studio work.

Incidentally, many of the samples for the book can be installed via NuGet. It’s not completely obvious how to do this. I found the best way is to go to and search for Wrox.ProMvc5 – here is the link to the search results. This lists all the packages available; note the package names. Then open the Nuget package manager console and type:

install-package [packagename]

to get the sample.

Chapter 11 is a too-brief chapter on the Web API. I would like to see more on this, maybe even walking through a complete application with clients for say, Windows Phone and a web application – though the following chapter does present a client example using AngularJS.

Chapter 13 is a somewhat theoretical look at dependency injection and inversion of control; handy as Microsoft developers talk a lot about this.

Next comes a very brief introduction to unit testing, intended I think only as a starting point.

For me, the the next two chapters are the most valuable. Chapter 15 concerns extending MVC: you learn about extending models with value providers and model binders; validating models; writing HTML helpers and Razor (the view engine in ASP.NET MVC) helpers; authentication filters and authorization filters. Chapter 16 on advanced topics looks in more detail at Razor, routing, templates, ActionResult and a few other things.

Finally, we get a look at how the application was put together, and an appendix covering some miscellaneous details like what is new in ASP.NET MVC 5.1.


I find this one hard to summarise. There is too much missing to give this an unreserved recommendation. I would like more on topics including ASP.NET Identity, Azure AD integration, Entity Framework, Bootstrap, and more. Trying to cover every developer from beginner to advanced is too much; removing some of the introductory material would have left more room for the more interesting sections. The book is also rather weighted towards theory rather than hands-on coding. At some points it felt more like an explanation from the ASP.NET MVC team on “why we did it this way”, than a developer tutorial.

That said, having those insights from the team is valuable in itself. As someone who has only recently engaged with ASP.NET MVC in a real application, I did find the book useful and will come back to some of those explanations in future.

Looking at what else is available, it seems to me that there is a shortage of books on this subject and that a “what you need to know” title aimed at professional developers would be widely welcomed. It would pay Microsoft to sponsor it, since my sense is that some developers stick with ASP.NET Web Forms not because it is better, but because it is more approachable.