Category Archives: .net

ComponentOne’s TouchToolkit for Windows Forms: another approach to the Windows tablet problem

Software component vendor ComponentOne has released Studio Enterprise 2013 v2.5, the latest in its suite of components, with support for Windows 8.1 and Visual Studio 2013.

The piece that caught my eye is the TouchToolkit for Windows Forms.

image

Here’s the problem. The Windows desktop is poor with touch control, which is why Microsoft created Windows 8 with its alternate, touch-friendly Windows Runtime platform. However users are resistant to the changed user interface, and it does not help with existing desktop apps.

Developers are also faced with a question of simple mathematics. Develop a Windows 8 Store app, get a market of x. Develop a Windows desktop app, get a market of many times x, since Windows 8 can run desktop apps, but Windows 7 cannot run Store apps.

Embarcadero approached this problem with a framework called Metropolis, for Delphi and RAD Studio. It builds apps that mimic the Windows Runtime look and feel, but which are actually desktop apps. Of course they do not run on Windows RT, the ARM version. It is a confusing solution in my opinion, leading users into what Martin Fowler calls the Uncanny Valley, where stuff works almost but not quite how you expect.

I prefer the thinking behind the TouchToolkit. Take your existing Windows Forms apps, or write a new one, using these controls to make them more touch-friendly. They will never be as well suited to touch control as a Store app, but they might be good enough, and of course will run on Windows 7 and earlier versions.

The controls include a magnifier, support for zoom gestures, and a touch event provider that adds gesture support to any control.

Windows Forms, we all know, is not as good as WPF if you want an application that scales nicely and supports modern design. On the other hand, Windows Forms is pragmatic and easy to use framework that remains popular for line of business apps.

Anders Hejlsberg says C# 6.0 to use Roslyn compiler, coming in next Visual Studio after VS 2013

A disappointment at Microsoft’s Build conference last month was lack of news about the next version of C#, version 6.0. C# architect Anders Hejlsberg did present a session, but it was on TypeScript, a language which compiles to JavaScript.

Aside: Hejlsberg talks about the new Xbox music app in Windows 8.1 (and Xbox One) which is written in JavaScript. It is a large app with 500,000  lines of code, and new features are now implemented in TypeScript (30,000 lines so far).

However, Hejlsberg did also talk about C# 6.0 at Build, during this Channel 9 Q&A, though you have to scroll through to reach the C# content (about 34 minutes in).

image

He confirmed that C# in Visual Studio 2013 is the same as before, but there will be new previews of the forthcoming “Roslyn” compiler soon, and that C# 6.0 will be in the “next Visual Studio after” which suggests Visual Studio 2014, presuming Microsoft sticks to its annual release cycle.

“We are at a point where the Roslyn compilers are done,” he said.

Roslyn, Hejlsberg explained, is the new compiler for “C#, and VB, and the language services in the IDE.”

Roslyn performance will be at least as good as the existing native compiler, says Hejlsberg. It is better suited to parallel processing so will take advantage of multi-core machines, “particularly for large projects.”

You can read more about Roslyn here. Microsoft describes it as “opening up the Visual Basic and C# compilers as APIs.” Practical benefits include features like instant porting of VB code to and from C#, and the use of C# and VB as macro languages within a .NET application.

Hejlsberg also says that Roslyn will enable a faster pace of evolution for C# in future.

Another aside: Xamarin, which provides a compiler for C# targeting iOS and Android, gets a nod of approval from Hejlsjberg. “I’m a great fan of their work,” he says.

Blogger (and former Microsoft Excel developer) Wesner Moise provides a transcript of the key points.

Microsoft and mediocrity in programming

A post by Ahmet Alp Balkan on working as a developer at Microsoft has stimulated much discussion. Balkan says he joined Microsoft 8 months ago (or two years ago if you count when he started as an intern) and tells a depressing tale (couched in odd language) of poor programming practice. Specifically:

  • Lack of documentation and communication. “There are certain people, if they got hit by a bus, nobody can pick up their work or code.”
  • Inability to improve the codebase. “Nobody will appreciate you for fixing styling or architectural issues in their core, in fact they may get offended.”
  • Lack of enthusiasm. “Writing better code is not a priority for the most”
  • Lack of productivity. “I spend most of my time trying to figure out how others’ uncommented/undocumented code work, debugging strange things and attending daily meetings.”
  • Lack of contribution to the community. “Everybody loves finding Stack Overflow answers on search results, but nobody contributes those answers.”
  • Lack of awareness of the competition. “No one I met in Windows Azure team heard about Heroku or Rackspace.”
  • Working by the book. “Nobody cares what sort of mess you created. As long as that functionality is ready, it is okay and can always be fixed later.”
  • Clipboard inheritance. “I’ve seen source files copy pasted across projects. As long as it gets shit done (described above) no one cares if you produced unmaintainable code.”
  • Using old tools. “Almost 90% of my colleagues use older versions of Office, Windows, Visual Studio and .NET Framework.”
  • Crippling management hierarchy. “At the end, you are working for your manager’s and their managers’ paychecks.”

There are a couple of points to emphasize. This is one person in one team which is part of a very large corporation, and should not be taken as descriptive of Microsoft programming culture as a whole. Balkan’s team is in “the test org”, he says, and not making product decisions. Further, many commenters observe that they have seen similar at other organisations.

Nevertheless, some of the points chime with other things I have seen. Take this post by Ian Smith, formerly a Microsoft-platform developer, on trying to buy a Surface Pro at Microsoft’s online store. From what he describes, the software behind the store is of dreadful quality. Currently, there is a broken image link on the home page.

image

This is not how you beat the iPad.

Another piece of evidence is in the bundled apps for Windows 8. The more I have reflected on this, the more I feel that supplying poor apps with Windows 8 was one of the worst launch mistakes. Apps like Mail, Calendar and Contacts on the Metro-style side have the look of waterfall development (though I have no inside knowledge of this). They look like what you would get from having a series of meetings about what the apps should do, and handing the specification over to a development team. They just about do the job, but without flair, without the benefit of an iterative cycle of improvements based on real user experience.

When the Mail app was launched, it lacked the ability to see the URL behind a hyperlink before tapping it, making phishing attempts hard to spot. This has since been fixed in an update, but how did that slip through? Details matter.

A lot is known about how to deliver high quality, secure and robust applications. Microsoft itself has contributed excellent insights, in books like Steve McConnell’s Code Complete and Michael Howard’s Writing Secure Code. The Agile movement has shown the importance of iterative development, and strong communication between all project stakeholders. Departing from these principles is almost always a mistake.

The WinRT platform needed a start-up culture. “We’re up against iPad and Android, we have to do something special.” Microsoft can do this; in fact, Windows Phone 7 demonstrated some of that in its refreshing new user interface (though the 2010 launch was botched in other ways).

Another piece of evidence: when I open a Word document from the SkyDrive client and work on it for a while, typing starts to slow down and I have to save the document locally in order to continue. I am not alone in experiencing this bug. Something is broken in the way Office talks to SkyDrive. It has been that way for many months. This is not how you beat Dropbox.

In other words, I do think Microsoft has a problem, though equally I am sure it does not apply everywhere. Look, for example, at Hyper-V and how that team has gone all-out to compete with VMWare and delivered strong releases.

Unfortunately mediocrity, where it is does exist, is a typical side-effect of monopoly profits and complacency. Microsoft (if it ever could) cannot afford for it to continue.

Billion dollar revenue or not, Microsoft Azure is growing fast

Is Microsoft Azure now a billion dollar business? Maybe, maybe not. The milestone was announced by Curt Anderson, CFO for Server and Tools at Microsoft, in this Bloomberg piece:

Microsoft Corp. (MSFT)’s Windows Azure software and related programs have surpassed $1 billion in annual sales for the first time … Microsoft’s $1 billion sales figure includes Azure, as well as software provided to partners to create related Windows cloud services, Anderson said in an interview.

The remarks have prompted discussion of what exactly makes up this billion dollars of sales. In particular, what is this software sold to partners for “related Windows cloud services” and how much is it worth?

Timothy Prickett Morgan on the Register takes the most sceptical line:

It seems likely, however, that the bulk of that revenue figure comes from peddling Windows Server, Systems Center, SQL Server, and any other wares that service providers, telcos, and hosters have bought to build Windows-based clouds.

It’s hard to imagine it being even a 20-80 split for Azure proper versus Azure-alike, and the ratio is probably something on the order of 10-90 if you put a gun to our head and made us guess. And maybe more like 5-95.

He overstates the case though. Context: Server and Tools earned revenue of over $18bn in the Microsoft’s last financial year ending June 30 2012 and is set to exceed that in 2013. As Mary-Jo Foley reports here, System Center (which forms the basis for Microsoft’s “private cloud” offering) was already over $1bn last year, so it seems unlikely that Anderson would now lump System Center revenue in with Azure and call it Azure revenue.

At the same time, the qualification in Anderson’s statement does imply that Azure on its own, without this “software provided to partners” does not quite make it.

It matters little. It is clear to me that Azure is a rapidly growing business for Microsoft, and that the energy put in by Scott Guthrie and his team is paying off. Check his blog for a stream of strong announcements.

Server and Tools boss Brad Anderson told me that Azure is a “massive public cloud that doubles every six months.”

It makes sense too. If your business runs on Microsoft’s platform and you want to scale into the cloud, Azure is a strong contender now that its usability and features are maturing. Azure Virtual Machines, providing infrastructure as a service, are of key importance; note that while they have been available for a while they only came out of preview officially on April 16th, a couple of weeks ago. Azure Active Directory and the possibility of federation with on-premise AD is another critical feature, and so is virtual networking, which became generally available at the same time as the Virtual Machines.

On the other hand, Prickett Morgan’s response and other exclamations of surprise around the web (Say What? says Gigaom) show the extent to which Microsoft botched the Azure launch back in 2008 and 2009, and how far it has to go before it is perceived as a strong cloud platform contender beyond the circles of Microsoft partners.

Amazon Web Services on the other hand won its cloud reputation years ago and shows no sign of letting go of its lead, with energetic development of its platform that at least matches Microsoft’s efforts as well as commodity pricing.

Still, with both Office 365 and Azure now booming, it seems to me that the time when you could laugh off Microsoft’s cloud efforts has passed. Expect an unqualified $1bn revenue for Azure before too long.

No more Delphi for .NET: Prism removed from RAD Studio XE4

Embarcadero is removing Prism from the next version of RAD Studio, XE4, expected later this month.

Prism is actually a third-party product, based on RemObjects Oxygene. Prism and Oxygene let you code in Delphi and compile to .NET or Mono.

Marc Hoffman from RemObjects explains the change here:

Starting with the upcoming release of XE4, Embarcadero Prism will no longer be part of the RAD Studio SKU, and there will be no “XE4″ branded edition of Prism.

But worry not. As you all know, Prism has been nothing more than a re-branded version of our Oxygene for .NET product — and Oxygene will keep going on, stronger than ever.

In fact, Oxygene has long outgrown its Prism-branded edition, first when we introduced full native support for Java and Android to the language over 18 months ago, and of course with our upcoming support for truly native iOS and Mac apps, shipping next month.

The disappearance of Prism is the final chapter in the story of Delphi for .NET. Borland’s Delphi was first released in 1995, and combined a visual interface builder superficially similar to Visual Basic with a native code compiler, enabling full access to the Windows API  as well as better performance than Microsoft’s VB.

Delphi built up a strong following, but in 2002 when Microsoft brought out the .NET Framework Borland worried that Delphi would be left behind. In 2002 it brought out CSharpBuilder, an IDE for C# targeting the .NET Framework, and in 2003 Delphi 8 which also targeted .NET.

Other .NET versions followed, but whereas native code Delphi was a compelling alternative to runtime-based platforms like VB and .NET, the .NET versions of Delphi were less distinctive. Developers coding for .NET preferred Microsoft’s Visual Studio, while Delphi developers preferred to stick with native code.

When Embarcadero acquired the Delphi tools from Borland in 2008, it dropped .NET support from Delphi itself and replaced it with Prism.

I doubt that the disappearance of Prism will cause much consternation. Prism developers will simply switch to Oxygene instead.

Xamarin acquires LessPainful, announces Test Cloud for mobile apps

Xamarin, a company which provides tools for cross-platform development in C#, has announced its acquisition of LessPainful and the creation of cloud-based testing for mobile apps based on LessPainful’s technology and the Calabash scripting language it created.

The Test Cloud will perform automated user-interface tests on real devices, hosted by Xamarin, will provide detailed reports in the event of test failures, and will support Continuous Integration so that bugs are caught as early as possible.

image

“After you’ve conquered the cross-platform mobile development problem, testing is the next large pain point” says Xamarin CEO Nat Friedman. “You can’t just get by with manual testing. There’s a need for the same level of tools and processes in mobile testing that you have in desktop and web testing.”

“Quality is actually more important on mobile than in other places. Mobile sessions are very short. People are really intolerant of low quality on mobile. The release cycles are shorter too. People are revving more frequently, and testing is a bigger challenge.”

Another issue with mobile testing is the number of devices out there, especially if you throw cross-platform into the mix. “You have on Android all these manufacturers who customise the OS in different ways, you have multiple different versions that are in use, and you have multiple different form factors and device capabilities. The testing permutation matrix is huge.”

“Automated UI testing is the only kind of testing that can ensure that the app does what it is supposed to do.”

Friedman says that the Xamarin UI tests are more robust than competing UI test frameworks because they do not depend on UI image recognition. “The right answer is object-based, you identify user interface elements on the screen by object IDs”.”

How does testing on real devices work? If you have 50 developers testing on 27 devices in Xamarin’s cloud, will there be racks and racks of devices to support them?  “That’s what it looks like at our end, racks and racks of devices,” confirmed Friedman. “The service is going to be built based on device/hour usage. We’ll be able to scale up to match what people need.

“We talk to developers who spend $8,000 a month just to get new devices. That’s not counting the labour and everything else they need to do, to set up their own testing infrastructure. It’s a giant pain point.”

Xamarin’s Test Cloud will offer plug-ins for Jenkins, TeamCity, and Microsoft’s Team Foundation Server, to support Continuous Integration.

The scripting language for the Test Cloud is either Calabash , or C# scripting which is under development by Xamarin.

The Test Cloud is not just for applications developed using Xamarin’s C# framework, but also supports other frameworks including those written in native iOS Objective C. However, only iOS and Android are supported.

Availability is set for the third quarter of 2013.

Xamarin’s Evolve conference is currently under way in Austin, Texas, with around 600 developers in attendance. Friedman says the company is growing fast. 1000 developers a day download the tools, there are over 15,000 paid developers, and the company now has 65 employees.

More information on the Xamarin Test Cloud is here.

Internal Windows Runtime apps are prohibitively expensive to deploy, says Microsoft Regional Director

Now we know why Microsoft has been so reluctant to divulge details of how to deploy a business app that uses the Windows Runtime (also known as Metro apps or Windows Store apps; though in this case the Windows Store app designation is particularly silly since these apps are precisely not Store apps).

Presuming Windows MVP and Regional Director Rockford Lhotka is correct, a business that wishes to sideload Windows Runtime apps (in other words, to deploy but not via the Windows Store), a business needs to purchase a $30 sideloading key which, by a stroke of marketing genius, is only available in packs of 100.

image

Note the above screen grab shows a price of more than $30.00. I believe this is because Lhotka’s figures do not allow for any reseller markup, though there could be regional differences as well.

Here is what Microsoft’s Antoine Leblond said back in April 2012:

To enable sideloading of a Metro style app onto a PC:

  • Set Group Policy for “Allow all trusted apps to install”. If you cannot use Group Policy, then you can set this through the following setting: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps = 1
  • Verify that the app is signed by a CA that is trusted on the target machines
  • Activate a special product key by using a script on the target machine to enable sideloading. We’ll go into more detail about how the IT admin will acquire the product keys in an upcoming blog post. The product key only needs to be install and activated once on the PC.

I have not seen the promised upcoming blog post but would be interested in doing so if anyone has a link?

Sideloading keys are only valid on Windows 8 Pro or Windows 8 Enterprise.

As a further disincentive, if you want to avoid running a PowerShell script on each target machine, you will need either System Center or InTune to manage the PCs. InTune is the cheaper option, at $6.00 per device per month. Lhotka calculates:

Let’s assume that your organization has 100 Windows RT or Windows 8 Pro devices, so you buy $3000 worth of side-loading keys. And let’s assume you use InTune. Finally let’s assume your devices have a 3 year life – which is pretty typical for corporate devices where you buy a service agreement from Lenovo or Dell or another vendor.

These 100 devices will cost $3000 for keys, plus $6 per device per month. This means that your org with 100 devices will pay around $23,000 extra to deploy a WinRT app just for this licensing.

and he concludes:

Right now it appears that Microsoft has worked very hard to devise a licensing and deployment scheme for WinRT apps designed specifically to discourage the creation of any WinRT business apps. Whether this is intentional or accidental I can’t say, but it is surely the case that no responsible business or IT manager could look at these scenarios and think that a move to WinRT for business app development makes sense at this time

That said, I am not sure he is being completely fair. I doubt a business will subscript to InTune just to support sideloading, and for those who do not want to subscribe, running a PowerShell script is not that hard. It seems to me that the problem could be mostly fixed by offering the sideloading keys in smaller packs.

I would add that now is probably not the moment to deploy a Windows Runtime app. The platform is not as good as it should be, and there is a case for waiting for the first major update in my opinion.

Still, $3000 for a licence pack is substantial, especially for a small business with fewer than 100 PCs.

The “Modern UI” side of Windows 8 has not taken off as yet, and a rational approach would be to encourage rather than discourage corporate developers to target the platform.

Note: a Microsoft Regional Director does not work directly for Microsoft. Lhotka works for Magenic. A Regional Director is an independent professional who is recognized for their ability to train and evangelise development on Microsoft’s platform.

Cross-platform frameworks ordered by percentage of shared code

Following my piece on different approaches to building the user interface in cross-platform frameworks, twitter user Sam Hogarth pointed me to the PropertyCross project. This implements a non-trivial application in 8 different cross-platform tools, covering Android, iOS and Windows Phone. Note that only four of the frameworks support Windows Phone.

Using the pie charts presented for each framework, I was able to order them by percentage of shared code as follows:

1= Adobe AIR (100%), JQTouch (100%) , RhoMobile (100%), Sencha Touch (100%)

5. Appcelerator Titanium (around 90%)

6. JQuery Mobile (around 80%)

7. Xamarin (around 40%)

8. Native (0%)

A couple of notes. Of the 100% frameworks, three do not support Windows Phone, and the one which does (Rhomobile) seems to be a bit broken on Windows Phone, judging by the screenshots. The Property Details and Favourites pages do not render properly.

You would get more code sharing with Xamarin if you only supported two rather than three platforms. That is logical: since it does not abstract the GUI.

In most cases (not Rhomobile) it is striking how different Windows Phone appears versus iOS and Android, even with jQuery Mobile which uses HTML5.

image

Xamarin vs Titanium vs FireMonkey: should cross-platform tools abstract the GUI?

Cross-platform development is a big deal, and will continue to be so until a day comes when everyone uses the same platform. Android? HTML? WebKit? iOS? Windows? Maybe one day, but for now the world is multi-platform, and unless you can afford to ignore all platforms but one, or to develop independent projects for each platform, some kind of cross-platform approach makes sense, especially in mobile.

Sometimes I hear it said that there are essentially two approaches to cross-platform mobile apps. You can either use an embedded browser control and write a web app wrapped as a native app, as in Adobe PhoneGap/Cordova or the similar approach taken by Sencha, or you can use a cross-platform tool that creates native apps, such as Xamarin Studio, Appcelerator Titanium, or Embarcardero FireMonkey.

Within the second category though, there is diversity. In particular, they vary concerning the extent to which they abstract the user interface.

Here is the trade-off. If you design your cross-platform framework to include user interface widgets, like labels, buttons, grids and menus, then you can have your application work almost the same way on every platform. You can also have tools that build the user interface once for all the platforms. This is a big win in terms of coding effort. If the framework is well implemented, it will still adopt some of the characteristics native to each platform so that it looks more or less native.

Some tools do this by drawing their own controls. Embarcadero FireMonkey is in this category. Another approach is to use native controls where possible (in other words, to call the API that shows a button, rather than drawing the button with the graphics API), but to use custom drawing where necessary, even sometimes implementing a control from one platform on another. The downside is that because those controls are not in fact native, there will be some differences, perhaps obvious, perhaps subtle. Martin Fowler at ThoughtWorks refers to this as the uncanny valley and argues against emulated controls.

Further, if you are sharing the UI design across all platforms, it is hard to make your design feel equally right in all cases. It might be better to take the approach adopted by most games, using a design that is distinctive to your app and make a virtue of its consistency across platforms, even though it does not have the native look and feel on any platform.

Xamarin Studio on the other hand makes no attempt to provide a shared GUI framework:

We don’t try to provide a user interface abstraction layer that works across all the platforms. We think that’s a bad approach that leads to lowest common denominator user interfaces.*

CEO Nat Friedman told me. He is right; but the downside is the effort involved in maintaining two or more user interface designs for your app.

This is an old debate. One of the reasons IBM created Eclipse was a disagreement with Sun over the best way to design a cross-platform user interface framework. Sun’s Swing framework, derived from Netscape’s Internet Foundation Classes first released in 1996, takes the custom-drawn approach, which is why Swing apps always look like Swing apps (even if you apply the “Windows” look and feel). A team from IBM, some originally from Object Technology International which was a company acquired by IBM, believed it was better to wrap native controls with a Java abstraction layer, created SWT (Standard Widget Toolkit) to do that, and used it to build Eclipse.

Personally I am wary of toolkits which rely heavily on custom-drawn controls rather than native controls, though I see their value. On the other hand, Xamarin Studio is so far in the other direction that it removes some of the benefit of a cross-platform framework.

My prediction is that Xamarin will come up with its own GUI abstraction framework in future, along the lines of SWT. It is a compromise; but one which delivers a lot of value to developers who want to create cross-platform apps with the maximum amount of shared code.

*I have never understood this use of the term “lowest common demominator”. The LCD in maths is the lowest number into which a specific group of numbers divide exactly, so it is an elegant thing. In cross-platform what you should strive for is the highest common intersection: to make available all the features common to each platform.

Update: in April 2014 Xamarin announced Xamarin Forms, a GUI framework which wraps native controls in a XAML implementation (XAML is the presentation language also used by Microsoft, for WPF, Silverlight, Windows Phone and Windows Runtime (Windows 8) apps. There is a quick hands-on here.

Xamarin 2.0 and Xamarin Studio announced, build for OSX, iOS and Android with C#

Xamarin has announced significant updates to its developer platform. Xamarin is the company formed around 18 months ago, when Novell discontinued its investment in Mono, a cross-platform implementation of C# and the .NET Framework. Its focus is on mobile platforms, in particular iOS and Android, though there is also support for the Mac. On Windows and Windows Phone, the presumption is that developers will continue to use Microsoft’s .NET Framework.

“If you look at what you can develop with C#, there’s about 1.2 billion Windows machines out there, but there’s now about a billion Android and iOS devices. Together we can make C# a universal language for application development and reach 2.2 billion devices,” Xamarin co-founder and CEO Nat Friedman told me.

“There’s a wonderful built-in audience of C# developers, millions of them, who need a bridge to mobile. We can help them take their existing skills and tools, and even code they’ve already written, and bring them to mainstream mobile platforms like iOS and Android.”

The key announcements:

  • Xamarin Studio is  an updated version of MonoDevelop, the Mono IDE. It runs on Mac and Windows.#
  • You can now develop iOS apps in Visual Studio for the first time
  • MonoTouch, the framework for iOS, has been renamed Xamarin.iOS
  • Mono for Android is now called Xamarin.Android
  • A new component store has pre-built components for download, some free, some commercial.
  • Xamarin now offers a free Starter edition, and pricing plans for independent developers, smaller businesses, and enterprises. Indie is $299 per platform per year, Business is $999 per platform/year, and Enterprise $1800 platform/year.

The Starter edition is not much use. It has a limited app size, and even the sample project I downloaded, an Employee Directory, exceeded that size and I had to register for a trial.

Xamarin’s philosophy is to share non-visual code, but to create a user interface that is native for each platform. This is a compromise in terms of the effort involved in supporting multiple platforms, but ensures a native experience on each device. “That’s fundamental to our platform,” says Friedman. “We tell our developers to separate the UI layer from the rest of the app. That allows them to share all the non-UI code across platforms, but to deliver a fully native UI, even though the whole app is written in C#. That’s what users demand now, people want native experiences.”

“We’ve been building tools that essentially project the underlying iOS APIs or Java [Android] APIs into C#”, explains co-founder Miguel de Icaza. “What it means is that people need to build a new UI for each platform.” He adds that Microsoft platform developers should be used to this, as Microsoft itself has several similar but incompatible .NET platforms. “There’s the one on Silverlight, the one on WPF, the one on Windows RT, and the one on the phone, it’s four,” he says. “Developers have had to resort to putting their logic into shared libraries, and build a per-platform UI. We’re reusing that knowledge.”

The ability to develop for iOS in Visual Studio is new. “It’s our most-requested feature of all time.” said Friedman.

I downloaded Xamarin Studio, which in my case was around 1.3GB including an updated Android SDK.

image

The IDE itself is clean and fast, and very much code-centric. It lacks the bloat of Visual Studio, though you will miss many of the features of Microsoft’s IDE.

image

I build the sample Employee Directory app and deployed it to an Android emulator which I use for Nexus 7 development. Deploying the runtime components took a long time, but after waiting patiently the app launched successfully.

image

If you want to do iOS development you will need a Mac of course. Although you can code on Windows, if you then the code is pushed over the the Mac side for compilation and debugging. In order to use Visual Studio, one option is to run Windows in a virtual machine on a Mac, as I have done with reasonable success using Embarcadero’s cross-platform tools.

Xamarin says it is growing fast. There have been 230,000 downloads of its tools, increasing by around 700 per day, and over 12,000 paying customers.

Despite Xamarin’s roots in the open source world (and Mono is still open source), a quick look at the pricing table shows that this is a fully commercial offering and priced accordingly. Presuming customers keep on subscribing, that is a good thing, ensuring the future of the platform; but it is not so good for the smallest developers who might otherwise give it a try.