Category Archives: .net

.net, cloud computing, microsoft, mobile, software development

Office, Azure Active Directory, and mobile: the three pillars of Microsoft’s cloud

When Microsoft first announced Azure, at its PDC Conference in October 2008, I was not impressed. Here is the press release, if you fancy a look back. It was not so much the technology – though with hindsight Microsoft’s failure to offer plain old Windows VMs from the beginning was a mistake – but rather, the body language that was all wrong. After all, here is a company whose fortunes are built on supplying server and client operating systems and applications to businesses, and on a partner ecosystem that has grown up around reselling, installing and servicing those systems. How can it transition to a cloud model without cannibalising its own business and disrupting its own partners? In 2008 the message I heard was, “we’re doing this cloud thing because it is expected of us, but really we’d like you to keep buying Windows Server, SQL Server, Office and all the rest.”

Take-up was small, as far as anyone could tell, and the scene was set for Microsoft to be outflanked by Amazon for IaaS (Infrastructure as a Service) and Google for cloud-based email and documents.

Those companies are formidable competitors; but Microsoft’s cloud story is working out better than I had expected. Although Azure sputtered in its early years, the company had some success with BPOS (Business Productivity Online Suite), which launched in the UK in 2009: hosted Exchange and SharePoint, mainly aimed at education and small businesses. In 2011 BPOS was reshaped into Office 365 and marketed strongly. Anyone who has managed Exchange, SharePoint and Active Directory knows that it can be arduous, thanks to complex installation, occasional tricky problems, and the challenge of backup and recovery in the event of disaster. Office 365 makes huge sense for many organisations, and is growing fast – “the fastest growing business in the history of the company,” according to Corporate VP of Windows Server and System Center Brad Anderson, speaking to the press last week.

image
Brad Anderson, Corporate VP for Windows Server and System Center

The attraction of Office 365 is that you can move users from on-premise Exchange almost seamlessly.

Then Azure changed. I date this from May 2011, when Scott Guthrie and others moved to work on Azure, which a year later offered a new user-friendly portal written in HTML5, and Windows Azure VMs and web sites. From that moment in 2012, Azure because a real competitor in cloud computing.

That is only two years ago, but Microsoft’s progress has been remarkable. Azure has been adding features almost as fast as Amazon Web Services (AWS – and I have not attempted to count), and although it is still behind AWS in some areas, it compensates with its excellent portal and integration with Visual Studio.

Now at TechEd Microsoft has made another wave of Azure announcements. A quick summary of the main ones:

  • Azure Files: SMB shared storage for Azure VMs, also accessible over the internet via a REST API. Think of it as a shared folder for VMs, simplifying things like having multiple web servers serve the same web site. Based on Azure storage.
  • Azure Site Recovery: based on Hyper-V Recovery Manager, which orchestrates replication and recovery across two datacenters, the new service adds the rather important feature of letting you use Azure itself as your space datacenter. This means anyone could use it, from small businesses to the big guys, provided all your servers are virtualised.
  • Azure RemoteApp: Remote Desktop Services in Azure, though currently only for individual apps, not full desktops
  • Antimalware for Azure: System Center Endpoint Protection for Azure VMs. There is also a partnership with Trend Micro for protecting Azure services.
  • Public IPs for individual VMs. If you are happy to handle the firewall aspect, you can now give a VM a public IP and access it without setting up an Azure endpoint.
  • IP Reservations: you get up to five IP addresses per subscription to assign to Azure services, ensuring that they stay the same even if you delete a service and add a new one back.
  • MSDN subscribers can use Windows 7 or 8.1 on Azure VMs, for development and test, the first time Microsoft has allows client Windows on Azure
  • General availability of ExpressRoute: fast network link to Azure without going over the internet
  • General availability of multiple site-to-site virtual network links, and inter-region virtual networks.
  • General availability of compute-intensive VMs, up to 16 cores and 112GB RAM
  • General availability of import/export service (ship data on physical storage to and from Azure)

There is more though. Those above are just a bunch of features, not a strategy. The strategy is based around Azure Active Directory (which everyone gets if they use Office 365, or you can set up separately), Office, and mobile.

Here is how this works. Azure Active Directory (AD), typically synchronised with on-premise active directory, is Microsoft’s cloud identity system which you can use for single sign-on and single point of control for Office 365, applications running on Azure, and cloud apps run by third-parties. Over 1200 software as a service apps support Azure AD, including Dropbox, Salesforce, Box, and even Google apps.

Azure AD is one of three components in what Microsoft calls its Enterprise Mobility Suite. The other two are InTune, cloud-based PC and device management, and Azure Rights Management.

InTune first. This is stepping up a gear in mobile device management, by getting the ability to deploy managed apps. A managed app is an app that is wrapped so it supports policy, such as the requirement that data can only be saved to a specified secure location. Think of it as a mobile container. iOS and Android will be supported first, with Office managed apps including Word, Excel, PowerPoint and Mobile OWA (kind-of Outlook for iOS and Android, based on Outlook Web Access but delivered as a native app with offline support).

Businesses will be able to wrap their own applications as managed apps.

Microsoft is also adding Cordova support to Visual Studio. Cordova is the open source part of PhoneGap, for wrapping HTML and JavaScript apps as native. In other words, Visual Studio is now a cross-platform development tool, even without Xamarin. I have not seen details yet, but I imagine the WinJS library, also used for Windows 8 apps, will be part of the support; yes it works on other platforms.

Next, Azure Rights Management (RMS). This is a service which lets you encrypt and control usage of documents based on Azure AD users. It is not foolproof, but since the protection travels in the document itself, it offers some protection against data leaking out of the company when it finds its way onto mobile devices or pen drives and the like. Only a few applications are fully “enlightened”, which means they have native support form Azure RMS, but apparently 70% of more of business documents are Office or PDF, which means if you cover them, then you have good coverage already. Office for iOS is not yet “enlightened”, but apparently will be soon.

This gives Microsoft a three-point plan for mobile device management, covering the device, the applications, and the files themselves.

Which devices? iOS, Android and Windows; and my sense is that Microsoft is now serious about full support for iOS and Android (it has little choice).

Another announcement at TechEd today concerns SharePoint in Office 365 and OneDrive for Business (the client), which is getting file encryption.

What does this add up to? For businesses happy to continue in the Microsoft world, it seems to me a compelling offering for cloud and mobile.

.net, development, open source, software development, visual studio

Microsoft’s new open source direction for C# and .NET (and native compilation too): Anders Hejlsberg explains

2 Comments

At the April 2014 Build conference Microsoft made some far-reaching announcements about its .NET platform and the C# programming language. Yes, there was talk of C# 6.0, the next version, but the real changes are more profound. Specifically:

C# and Visual Basic have a new compiler, itself written in C#, code-named Roslyn. Roslyn is not just a new compiler; Microsoft now calls it the “.NET Compiler Platform”.

There is a new commitment to open source for .NET projects. Microsoft formed the .NET Foundation to oversee existing open source projects, including  ASP.NET, Entity Framework, the Azure .NET SDK, and now Roslyn as well. “When it comes to development projects we are going to operate from the premise that open source is the default. Unless there are reasons why it does not work,” said C# lead architect Anders Hejlsberg.

image

Note that open source does not mean chaos. It does mean that you can fork the project if you want – the Roslyn license is Apache 2.0 – but getting Microsoft to accept new features you have contributed will not be trivial. Hejlsberg makes the point that language features are easy to add, but impossible to take away, so extreme care is necessary.

Microsoft is also supporting cross-platform C# to a greater extent than it has done in the past. The most obvious sign of this is its cooperation with Xamarin, which provides C# compilers for iOS and Android. Xamarin’s Miguel de Icaza got a top billing at Build, and is also involved in the .NET Foundation.

There is more though. The idea of standardised C# is re-emerging:

“The last ECMA standard was C# 2.0. There wasn’t a lot of demand for it, but that demand has recently risen and we have re engaged with the ECMA community to produce a standard for C# 5.0,” said Hejlsberg.

This bears some unpacking. Why was there little demand for ECMA C#? Partly I would guess from the assumption the C# was firmly in Microsoft’s grip, with Java the obvious choice for cross-platform development. The main interest was from the Mono folk (Miguel de Icaza again), which implemented .NET for Linux and the Mac with some success, but nothing to disturb Java’s momentum.

The focus now though is on mobile, and interest in C# is stronger, mainly from Microsoft-platform developers reaching beyond Windows. There is also Unity, which uses C# as a scripting language for developing games for multiple platforms, including iOS, Android, Windows, Mac, Linux, Xbox, PS3 and Wii – PS4 is coming very soon.

Microsoft has now consciously embraced multiple platforms, as evidenced by Office for iOS as well as the Xamarin collaboration. “We want C#developers to build great applications across different form factors and different device platforms,” said Jay Schmelzer Director of Program Management for Visual Studio.

You might observe that this position has been forced on the company by the rise of iOS and Android, a view which likely has some merit, but the impact it has on C# and .NET itself is still real.

I asked Hejlsberg to unpack the difference between the Roslyn project and C# 6.0, bearing in mind that both are covered on the Roslyn open source site; you can see the current status of C# 6.0 and the next Visual Basic here.

Roslyn is the name for the project that encompasses the new C#compiler and the new VB compiler and the new language services that they share. C# 6.0 is the name of the next version of the C #language which will have a specification and which will have an implementation. We are implementing C# 6.0 on the Roslyn platform. We are not going to continue to evolve our old C++ C# compiler – the C# compiler was originally written in C++ and has been evolved up through C# 5.0. That is where we are going to retire that code base, and going forward versions of C# will be built on Roslyn and therefore will be built open source. Unlike previously where, boom. C# came down from the sky with a set of features, it is going to happen more organically now, people will submit pull requests, open up issues, and you will see us work on these features. You will see them from inception to fruition.

“The C# team, the Roslyn team, the VB team, their day to day workplace now is the open source site. That is where they check-in code. It is a community in the making.

Even that is not all. At Build, Microsoft also announced .NET Native, which is a native compiler for C# and Visual Basic, now in preview for x64 Store apps. What is the difference between .NET Native and the existing NGen native compiler for .NET? Over to Hejlsberg:

NGen is the native feature that we currently support. NGen is really, “I’m going to JIT [Just in time compile] your code and then snapshot all the data structures and dump them in a file so that I can quickly rebuild that file later when you run this particular application”. But it is the same code generator and all the same features, and JIT is still there. NGen is really a way to pre-cache the JIT output and therefore get better performance, but it adds to the size of your app because you still have all the assemblies and metadata and then the NGen image as well.

.NET Native is a completely different approach. Instead of the JIT we use the backend from the C++ compiler. You can think of it as a linker that takes as input assemblies, and as output produces a PE [Portable Executable] executable. In the process this linker or code generator will analyse all the IL [Intermediate Language] that goes into the application and it will apply a thing known as tree-shaking where it eliminates all of the code that will never execute based on known execution roots.

In other words, the public static main of your program and also whatever pieces of your app that you designate as reflectable, they also become roots. Based on that we produce an optimised exe, and into that exe we link the pieces of the framework that you are referencing. We link in a garbage collector [GC], and it looks to the operating system just like an exe. When you run it, it runs a local GC in there and it is as efficient really as C++ code.

There are some restrictions associated with .net native, mainly that you can’t just willy-nilly reflect on the whole world. You can’t just generate new code and ask for that to be jitted because they may not be a JIT compiler. We are considering allowing you to link in a JIT compiler, but there are certain execution environments which don’t permit jitting, like Xbox. If you use reflection in your lap you have to tell us what to keep reflectable, because otherwise we will optimise it away.

According to Schmelzer:

The preview out today is scoped to Store app x64 and ARM. We haven’t run into any technical limitation that shows it can’t be done across the breadth, it is just a matter of request and need.

Open source, native code compilation, and an innovative compiler: it adds up to huge changes for C# and .NET, positive ones as far as I can tell.

The Xamarin connection is intriguing though. Developers in general admire the technology as far as I can tell, but it is expensive, and paying out for a Xamarin subscription on top of maybe MSDN for Visual Studio is too much for some smaller organisations and does not encourage experimentation. Might Microsoft acquire Xamarin and build Visual Studio into an IDE targeting all the major mobile platforms, but with special hooks to Azure-hosted services?

That prospect makes sense to me, though it would be a shame if the energetic Xamarin culture became bogged down in big-company bureaucracy. Currently though: no news to report.

.net, development, microsoft, professional

Hands on: SQL Server 2014 with data files in Azure Blob Storage

2 Comments

One intriguing new feature in Micrsosoft’s SQL Server 2014 is the ability to create or attach databases whose files are in Azure blog storage. This sounds like something that would not work at all well: why would you want a database engine to mount files located hundreds or thousands of miles away? However, the feature is apparently baked deeply into SQL Server, according to this white paper (which is essential reading if you want to know more):

SQL Server 2014 integration with Windows Azure blob storage occurs at a deep level, directly into the SQL Server Storage Engine; SQL Server Data Files in Windows Azure is more than a simple adapter mechanism built on top of an existing software layer.

· The Manager Layer includes a new component called XFCB Credential Manager, which manages the security credentials necessary to access the Windows Azure blob containers and provides the necessary security interface; secrets are maintained encrypted and secured in the SQL Server built-in security repository in the master system database.

· The File Control Layer contains a new object called XFCB, which is the Windows Azure extension to the file control block (FCB) used to manage I/O against each single SQL Server data or log file on the NTFS file system; it implements all the APIs that are required for I/O against Windows Azure blob storage.

· At the Storage Layer, the SQL Server I/O Manager is now able to natively generate REST API calls to Windows Azure blob storage with minimal overhead and great efficiency; in addition, this component can generate information about performance counters and extended events (xEvents).

It also seems that the main target usage is SQL Server running on Azure VMs in the same region as the blog storage, removing latency concerns, though the wording of the explanation is curious, implying almost that on-premise connection is supported but should not be:

Although it is theoretically possible and officially supported, using an on-premises SQL Server 2014 installation and database files in Windows Azure blob storage is not recommended due to high network latency, which would hurt performance; for this reason, the main target scenario for this white paper is SQL Server 2014 installed in Windows Azure Virtual Machines (IaaS). This scenario provides immediate benefits for performance, data movement and portability, data virtualization, high availability and disaster recovery, and scalability limits.

If you use blob storage in this way on an Azure VM, then I/O goes through the Virtual Network Driver, whereas an Azure data disk uses the Virtual Disk Driver. This nicety may be the main reason to consider the feature.

I tried both scenarios: on-premise and from an Azure VM. I had some difficulty getting started, despite this seemingly exhaustive tutorial. I followed it, I thought, to the letter, but got either the error:

Unable to open the physical file "https://myaccount.blob.core.windows.net/sqldata/azuredb.mdf". Operating system error 86: "86(The specified network password is not correct.)".

or else

CREATE FILE encountered operating system error 1117(The request could not be performed because of an I/O device error.) while attempting to open or create the physical file https://myaccount.blob.core.windows.net/sqldata/azuredb.mdf

The problem turned out to relate to the Shared Access Signature required. The supposedly exhaustive tutorial merely refers you to the CloudBlobContainer.GetSharedAccessSignature method in the Azure SDK and offers an incomplete code snippet. I wrote C# code for this and was able to generate a Shared Access Signature but it did not work (see above). I found myself in the depths of the Azure SDK, wondering if I should use version 2.1 or 3.0, and whether I should use Microsoft.WindowsAzure.StorageClient.CloudBlobClient or Microsoft.WindowsAzure.Storage.Blob.CloudBlobClient. The tutorial is also not clear about exactly which part of the Shared Access Signature you should store in the SQL Server Credential Manager; it is a multipart string separated by ampersands.

I have still not fully worked it out, but discovered the very helpful Azure Storage Explorer on CodePlex. If you follow the instructions in the white paper referenced above, and use the Azure Storage Explorer to generate the Shared Access Signature, then it works. The project is open source, so with a little effort it should be possible to find and document the exact requirements.

image

I tried creating and using a database from my on-premise SQL Server 2014 and I find the performance remarkably good, considering. There is no doubt some smart caching going on under the covers. Selecting 1000 rows from a table took 11 seconds the first time, and was instant the second time. It seems to me viable, on my brief look, though I am not sure why you would want to do this. However it is a good demonstration of how cloud and on-premise are coming ever-closer.

image

Running from an Azure VM in the same region is a different case, though I would suggest detailed and intensive testing before going into production.

.net, development, microsoft, software development, visual studio, windows

A quick hands-on with native code compilation for .NET

4 Comments

I had a quick look at the .NET Native Preview. I am interested to see what the benefits might be. Note that currently the preview only supports 64-bit Windows Store apps.

Here is what is promised:

For users of your apps, .NET Native offers these advantages:

  • Fast execution times
  • Consistently speedy startup times
  • Low deployment and update costs
  • Optimized app memory usage

I created a small C# app that counts prime numbers using a simple approach. I created it first as a Universal App that does not use .NET Native, and then as a second app that does use .NET Native.

image

My initial results are disappointing. The time taken to count prime numbers is similar in both apps.

image

As a further test, I added code that adds the prime numbers found to a ListView control using an async task. The idea was to see if GUI interaction and multi-threading would be more revealing than simply crunching numbers in a tight loop. The apps takes much longer with this enabled, but again, there is nothing to choose between the two.

Did I really succeed in compiling the app to native code? I think so. Here are the contents of the AppX folder for the standard .NET executable:

image

and here for the native compiled executable – note the additional DLLs:

image

I am not actually surprised that there is no performance benefit in my example. JIT (just-in-time) compilation means that any .NET application is native code at runtime, though optimization might be different.

I have ended up with a much larger app to deploy, though the relative difference would be less, I imagine, with an app that contains more code.

I can also readily believe that start-up time will be better for a native compiled app, since there is no need for the JIT compiler. However my app is so small that this is not significant.

My question though is what kind of app will benefit most from native compilation? I would be interested to see guidance on this.

Of course it is also possible that later iterations of the technology will yield different results.

.net, development, microsoft, mobile, mono, nokia, open source, professional, software development, visual studio, windows

Microsoft Build 2014: what happened

2 Comments

It’s curious. Microsoft’s new CEO Satya Nadella has been in place for only a month which means that almost everything announced at Build, Microsoft’s developer conference which took place last week in San Francisco, must have been set before he was appointed; yet there was a sense of “all things new” at the event, as if he had overseen a wave of changes.

The wave began the previous week, with the simultaneous announcement and delivery of Office for iPad. The significance of this is threefold:

  • It demonstrated Microsoft’s decision to give first-class support to mobile platforms other than Windows
  • It demonstrated that Office can be redesigned to work nicely on a tablet
  • The quality of the product exceeded expectations, showing that in the right circumstances Microsoft can do excellent non-Windows software

image

Next came Build itself. It was a tale of two keynotes. The first was all about Windows client – both Phone and PC. The core news is the arrival of the Windows Runtime  (WinRT, the engine behind Metro/Store Apps) on Windows Phone 8.1. This means that WinRT is now the runtime that developers should target for apps that run across phone and desktop – and even, we were shown, Xbox One, which will support WinRT apps written in HTML and WinJS (Microsoft’s JavaScript library for Windows apps).

In support of this, Microsoft announced a new Universal App project for Visual Studio, which lets you share both visual and non-visual code across multiple targets. How much is shared is a developer choice.

There is more. A Universal App is now (kind-of) a desktop app as well as a Store app, since in a future free update to Windows 8, it will run on the desktop within a window, as well as appearing in the Start menu on the desktop. We were even shown this; apparently it is a mock-up. This was the biggest surprise at Build.

image

What did Executive VP Terry Myerson say about this? Here is the exact quote:

We are going all in with this desktop experience, to make sure your applications can be accessed and loved by people that love the Windows desktop. We’re going to enable your Universal Windows applications to run in a window. We’re going to enable your users to find, discover and run your Windows applications with the new Start menu. We have Live Tiles coming together with the familiar experience customers are looking for to start and run their applications and we’ll be making this available to all Windows 8.1 users as an update. I think there will be a lot of happy people out there.

This is significant. When Myerson says, “we are going all in with this desktop experience”, he does not mean backtracking on Windows Store apps, to return to desktop windows apps (Win32 or WPF) as the future of Windows development. Rather, he means Windows Store apps integrated into the desktop.

There is a further twist to this. Windows Store apps are sandboxed and cannot communicate with each other or with the operating system other than via carefully designed and secured paths. This is in general a good thing, but restrictive for businesses designing line of business apps. It also means that legacy code cannot be carried over into a Store app, other than by full porting.

In the just-released Windows 8.1 Update this has changed. Side-loaded apps (in other words, not deployed from the Windows Store) can now escape the sandbox thanks to Brokered Windows Runtime Components. There are some limitations (32-bit only on the desktop side, for example) but this will make it possible to implement business applications as Store apps even if they need to interact with existing desktop applications or services.

There is still a huge blocker to Store apps from a business perspective, which is that you need Windows 8. Still, my guess is that once the update with the restored Start menu appears, most of the objections to Windows 8 will melt away.

We also saw Office for the Windows Runtime, which will run on both Phone and PC. It is written, I discovered later, in XAML, DirectX and C++ (“Blazingly fast”, we were told). Corporate VP Kirk Koenigsbauer introduced a preview of this, or at least PowerPoint.

image

No detail yet, and several references to “early code” suggest to me that this is a year or more away from full release (giving Office on iPad a big head start); but it will come. Koenigsbauer did not call it cut-down; in fact, it was instanced as proof that WinRT is suitable for large-scale apps, so I would expect something more complete than Office on iPad; yet it is hard to imagine things like the VBA macro language appearing here in its current form (VBA is based on the ancient Visual Basic 6.0 runtime), so there will be some major differences.

We also saw Windows Phone 8.1, including the Cortana virtual personal assistant who responds to voice input. For me other things in Windows Phone 8.1 are more significant, including new swipe-style keyboard for fast text input, VPN, S/MIME secure email, and a new notification centre. Unlike touch Office, Windows Phone 8.1 is coming soon; Nokia’s Stephen Elop (soon to be in charge of Windows Phone at Microsoft) said that the first 8.1 Lumia devices could be out from May, depending on territory, and that all Lumia Windows Phone 8 devices will get the update in the summer.

On to day two, which was Cloud day, though we also got significant .NET developer news.

Executive VP Scott Guthrie introduced a new portal for Microsoft Azure, the cloud platform. This is not just a new look, but integrates with Visual Studio online so you can easily view and edit the code and track team projects. There are also new monitoring and analytics features so you can check page views, page load time, browser usage and more. Guthrie also announced integration with Puppet and Chef for deployment automation.

image

Language designer Anders Hejsberg also came on stage. He announced the release version of TypeScript, a “typed superset of JavaScript” which is suitable for large applications. He also announced a new preview release of the compiler project code-named Roslyn, and on stage pushed the button that published it as open source. What is Roslyn? It is the next generation compiler for C# and VB, and is itself written in C#. This enables compiler and workspace APIs, which in turn enable rich editor features:

The transition to compilers as platforms dramatically lowers the barrier to entry for creating code focused tools and applications. It creates many opportunities for innovation in areas such as meta-programming, code generation and transformation, interactive use of the C# and VB languages, and embedding of C# and VB in domain specific languages.

Roslyn will be fully released in the next version of Visual Studio, for which we do not yet have a date. Roslyn will be delivered alongside C# 6.0.

There is also a new .NET Foundation which will oversee open source projects for .NET, with backing from folk including Xamarin’s Miguel de Icaza and Umbraco’s Niels Hartvig. It is all a bit vague at the moment:

In the upcoming months, the .NET Foundation will be inviting many companies and community leaders to join the foundation, including its Board of Directors and will then finalize its operational details, including governance models for its open source initiatives, membership structure and industry and community engagement.

Another significant event in the .NET story is the arrival of true native code compilation for .NET, although currently only for 64-bit Store apps. More on this soon.

A couple of events during Build caught my eye. One was de Icaza’s session on using C# to build for iOS and Android, not so much for the content itself (though there was nothing wrong with it), but rather for the huge attendance it drew.

image

The session was moved to the Build keynote room, and while there were spare seats, the room felt well filled. This speaks loudly about the importance of those platforms even to Microsoft platform developers, as well as of Microsoft’s support of Xamarin’s work.

Another was the appearance of John Gruber, author of the Daring Fireball blog and an Apple enthusiast. He appeared in a video during the keynote, explaining how a project in which he is involved uses Azure for back-end services, and then in person at another session, interviewing journalist Ed Bott about what is changing at Microsoft.

image

Gruber seems to me representative of a group of smart observers who have not in general been impressed with Microsoft’s endeavours over the past few years; but he for one is now more positive on the subject. Windows Phone is much better than its market share suggests, he said. This alongside Azure and a new openness to supporting third-party clients has made him look more favourably on the company.

My summary is this. On the Windows client side, Microsoft is taking its unpopular Windows release and its minority Phone platform and making them better and more compatible with each other, making sense of the client platform in a way that should result in growth of the app ecosystem both on Phone and PC/Tablet. On the cloud side, the company is building Azure and Office 365 (two platforms united by Azure Active Directory) into a one-stop platform that is increasingly compelling. The result was a conference and a direction that was largely welcomed by those in attendance, as far as I could tell.

That does not mean that the PC will stop declining, or that iOS and Android will become less dominant in mobile. There is progress though, and more clarity about the direction of Microsoft’s platform than we have seen for some years.

For the official news from Build, see the Build Newsroom.

.net, android, apple, microsoft, software development, windows

Microsoft Build goes nuts over Xamarin’s C# and .NET for iOS and Android

2 Comments

Xamarin’s Miguel de Icaza was booked for a standard session room at Build, Microsoft’s developer conference in San Francisco, but the session was moved to the keynote room because of demand. I am not sure how the likely demand was calculated, but it was possibly something to do with the event app that lets attendees plan their agenda.

It was just as well that the session got moved.

image

The attendance at the session mirrored my observation that Xamarin’s stand in the third-party partner exhibition was drawing more attention than any other. Xamarin’s tools let developers port applications to iOS and Android while still using C# and the .NET Framework.

image

I am not sure what to conclude from the obvious high level of interest in compiling apps for iOS and Android. You can interpret this as good news for Microsoft, in that it keeps developers working in .NET and with easy access to the libraries that support Microsoft services; or as bad news, in that it shows how many developers are moving towards non-Microsoft platforms in their app deployments.

It was the second time today that de Icaza appeared on the keynote stage. Earlier he stood there with Anders Hejlsberg, the author of C#.

image

It has been a long journey, from the time when Mono (the open source implementation of .NET founded by de Icaza) was viewed with distrust by Microsoft (as far as I could tell), as an open source competitor to the official version.

Now there is talk of whether Microsoft might acquire Xamarin – of which there is no news here at Build, I should emphasise.

.net, microsoft, mobile, software development, visual studio, windows

What is a Universal Windows App?

At its Build developer conference in San Francisco, Microsoft has announced a new kind of Windows app: a Universal App. In fact, you can download the latest Visual Studio 2013 update (Update 2 RC) and

image

A Universal App runs on both Windows Phone 8.1 and Windows 8.1. But what is it really?

The place to start is with the runtime. In Windows Phone 8, Microsoft migrated the kernel in Windows Phone from the cut-down CE version of Windows, to the same kernel used by desktop Windows. However the app runtime in Windows Phone 8 remained Silverlight, Microsoft’s Flash competitor which was originally designed as a browser plug-in.

In Windows Phone 8.1 Microsoft has taken the next logical step, and ported the Windows Runtime (WinRT) to the phone. WinRT is the runtime behind the Metro/Modern/Store App environment introduced in Windows 8.

A Universal App runs on WinRT. This means that Windows Phone 8.1 supports the same variety of development options as Windows 8: XAML and C#, XAML and C++, HTML and the WinJS Javascript library (now open source), and DirectX for games.

The port is not 100%; there are some platform-specific APIs. Apparently compatibility is about 90% in terms of APIs available.

That said, a Universal App is not a universal binary. Apparently you can have a universal binary, but it is not the approach Microsoft is taking. A Universal App is a project type in Visual Studio.

image

When you create a Universal App you get a project with multiple targets.

image

By default you get two targets, but we have also seen Xbox One as a target, and conceptually we could see more: maybe Xamarin might extend it to support iOS and Android, for example.

The way this works is that at compile-time any code (which can include XAML and project assets such as images as well as C# code) that is in the Shared project gets merged into the target-specific project.

This means that a Universal App could contain very little shared code, or be almost entirely shared code. This is a developer choice.

Separately, Microsoft has now enabled an app identity to run across multiple Windows platforms in the Store. This means a user can purchase an app once for multiple platforms. However, this is more a business than a technical feature. It would be possible for the developer to offer a multi-platform app in the Store, but keep the development for each platform entirely separate.

That said, the shared WinRT aspect means that code sharing in a Universal App is very feasible. Most if not all non-visual code should work fine, and XAML experts will be able to share most of the UI code as well, thanks to the flexibility built into the XAML UI language.

That is the good bit. There is a problem though. Neither the Windows Phone app platform, nor the Windows 8 app platform have been hugely successful to date, but of the two, Windows Phone has fared better. There are now 500 new apps per day for Windows Phone, we were told here at Build.

Unfortunately, porting those Windows Phone apps to become Universal apps is not easy. Developers have to port their app from Silverlight to WinRT, before they can add a target for Windows 8. They will also need to maintain the old Silverlight app for users with versions of Windows Phone earlier than 8.1. Nokia has promised to offer upgrades for all Windows Phone 8 Lumia models, but that will not the base for all Windows 8 phones out there, and as ever operators have a role here.

Life is easier for Windows 8 app developers who now want to support Windows Phone 8.1; but there are not so many great Windows 8 apps for which Windows Phone users are anxiously awaiting.

Still, the Universal App approach makes perfect sense for the future, once Windows Phone 8.1 is established in the market. It also makes sense for enterprises with internal apps to deploy for mobile and tablet users.  

.net, microsoft, windows

Saving Windows the sequel: the Return of the Start

Day one at Microsoft’s Build conference in San Francisco was Windows client day – including Windows Phone as well as full Windows. Two slides made the biggest impression on me. One was this one, the return of the Start menu to the desktop, and a Store app (the Mail client) running in a desktop window:

image

The other was this: Office redone for the Metro, sorry Modern user interface:

image

Note that Touch Office will run on Windows Phone as well as on full Windows. Microsoft has ported most of the Windows Runtime (WinRT), the software engine that runs the Modern UI, to Windows Phone. The new Office is written in XAML and C++ so will run on both platforms.

Has Microsoft backtracked on the Windows 8 concept championed by former Windows VP Steven Sinofsky?

To some extent it has. Sinofsky’s Windows 8 was a purer conception, in which the whole focus is on the Modern environment and the desktop is presented like a legacy component, an app within the environment that happens to run all your old stuff.

Users rebelled, businesses swore to stick with Windows 7, and Microsoft has been gradually unpicking bits of it to make it more palatable to existing users. In Windows 8.1 we saw the return of the Start button and an option to boot directly to the desktop. In Windows 8.1 Update 1 we see a window bar appear across the top of Store apps, when the mouse is at the top of the screen, Store apps on the desktop taskbar, and the taskbar running at times across the Modern UI.

The security boundaries are getting slightly eroded, with an option for side-loaded apps (mostly the realm of enterprise deployments) now able to escape the sandbox and run legacy code.

Windows 8 vNext goes further. Store apps in windows: is there anything left of Microsoft’s tablet platform?

Well yes, there is. Store apps will still run primarily full-screen, and more important, will still use the new controls – menus, buttons, lists – that can be operated easily with touch. They still use the blocky “Metro” design concept, which for all its faults (it is not the most beautiful of UI concepts) is easy to operate without mouse or keyboard.

The other perspective on Microsoft’s shifting approach to the Windows client is that it is putting all its energy into promoting these modern apps.

Sinofsky’s idea was to push users into the Modern environment by making it the heart of Windows 8 – the Start screen. That did not work, so now Microsoft is taking a gentler approach but with the same goal in mind. If users are working mainly on the desktop, the argument goes, we will bring the apps to them there.

Windows 8.1 Update 1 discreetly plants a link to the Windows Store on the desktop taskbar, making this point perfectly.

For users who work on the desktop, Store apps will now be more visible, and more appealing again once they run in a desktop window.

For developers, there is another big change. They  can now target both Windows and Phone with a single app project, called a Universal App, so the effective size of the target market, though still small compared to Android and iOS, has significantly increased. Users can buy an app once in the Store and run it on both platforms.

The Universal App can be further extended to Xbox One, which also includes WinRT.

It is all about the apps – as it always was. If developers support Microsoft’s app ecosystem with renewed vigour following these changes, the future of Windows in the new mobile world does look brighter.

The forthcoming Office, you will recall, is also a Store app. You will finally be able to get real work done in the tablet environment.

Microsoft has not backtracked, in the sense that we are not hearing at Build about a renewed focus on the desktop. Rather, we are hearing about a more integrated approach to supporting both desktop and Store apps in Windows, but with the same goal as before, to make Windows an operating system fit for purpose on tablets.

It is worth recalling that Windows 8 was not only about supporting touch. The WinRT environment is also about security, where apps are sandboxed, and easy deployment via the Windows Store. This way Microsoft can prevent Windows from being wrecked by malware and other unwanted software.

What of Windows RT, the ARM version? With Office coming to the phone, I am more or less convinced that the next tablet-only Windows devices will be based on Windows Phone rather than Windows RT. You will have Office, but not the desktop, for better or worse. But no such announcement has yet been made.

.net, microsoft, mobile, sharepoint, silverlight, software development, visual studio, windows

Microsoft Build Sessions published: Windows Phone XAML and HTML/JS apps, new Azure APIs and more

2 Comments

Developing for Windows Phone is now closer to developing for the Windows 8 runtime, according to information from Microsoft’s Build sessions, just published.

Build is Microsoft’s developer conference which opens tomorrow in San Francisco.

image

Building a Converged Phone and PC App using HTML and JavaScript states that “An exciting part of Windows Phone 8.1 is that you can now start building applications natively in HTML and JavaScript.”

Other sessions refer to the Common XAML UI Framework, which seems to refer to a shared UI framework for Windows Phone and WIndows 8, but using XAML rather than HTML and JavaScript.

This is in addition to Silverlight, not instead, judging by this session:

We’ve been doing a lot of work with new converged XAML app support on Windows Phone 8.1, but what about legacy Windows Phone Silverlight XAML based apps?  Come learn about all the new features we’ve enabled with Silverlight 8.1.

Microsoft has also come up with new APIs for applications that integrate with its Azure cloud platform and with Office 365. The Authentication library for Azure Active Directory lets you build both Windows and mobile applications that authenticate against Azure Active Directory, used by every Office 365 deployment. There is also talk of using Azure for Connected Devices, meaning “Internet of Things” devices using Azure services.

Some other sessions which caught my eye:

Connected Productivity Apps: building apps for the SharePoint and Office 365 platform.

What’s new in WinJS: the road ahead. XAML vs HTML/JS is a big decision for Windows developers.

Anders Hejlsberg on TypeScript

Automating Azure: “The Azure Management Libraries and Azure PowerShell Cmdlets allow this type of automation by providing convenient client wrappers around the Azure management REST API”

Authentication library for Azure Active Directory: The Active Directory Authentication Library (ADAL)

Panel discussion on desktop development: is there a future for WPF? Maybe some clues here.

Miguel de Icaza gets a session on going mobile with C# and Xamarin. I recall when de Icaza ran sessions on Mono, the open source implementation of the .NET Framework which he initiated shortly after Microsoft announced .NET itself, in nearby hotels at Microsoft events; now he is inside.

Learning from the mistakes of Azure: Mark Russinovich on what can go wrong in the cloud.

Looks like both cloud and apps for Windows Phone/Windows 8 are big themes at Build this year.

.net, microsoft, software development, visual studio, windows

Entering Microsoft’s XAML labyrinth: is it worth it?

6 Comments

I spent some time at the weekend working on a Bridge game for the Windows Store. I am writing it in XAML and C#. The UI is hardly demanding, given that Bridge is a card game, but it has made me take a fresh look at XAML, the markup language for a Windows Store App user interface (unless you use HTML and JavaScript). XAML is also used in Windows Presentation Foundation and in Silverlight/Windows Phone.

As part of the game, the user selects a “bid” which consists of a number from 1 to 7 and a suit of cards (or double, redouble or pass). Most bridge games show this as a grid though functionally it is like a combo-box (choosing from a pre-defined range of options).

Naturally I looked for the easiest way to accomplish this. The solution I came up with was to nest TextBlock controls in Border controls in Grid cells. Then I wrote C# code that detects which cell the user taps and updates the background of the selected Border accordingly.

image

I have in mind to replace the text with graphics and make the numbers a bit smarter at some future date. My solution works fine; here it is at runtime:

image

At the weekend I happened to be chatting with a developer more expert in XAML than myself, who told me I had done it wrong. In XAML everything should be in Style definitions. I should use a ListView and design it in Blend.

Well, I knew that I had somewhat subverted how XAML is meant to work, so I sat down to investigate this different approach. A ListView looks nothing like what I want out of the box.

image

However, with the magic of XAML it can be transformed. I made the ListView horizontal by defining an ItemsPanelTemplate in Application.Resources:

<ItemsPanelTemplate x:Key="ItemsPanelTemplate1">
  <StackPanel Orientation="Horizontal"/>
</ItemsPanelTemplate>

and adding 

ItemsPanel="{StaticResource ItemsPanelTemplate1}

as an attribute of the ListView.

Then I added an ItemTemplate to draw the kind of block that I wanted:

<ListView.ItemTemplate>
    <DataTemplate>
        <Border BorderThickness="1" Height="130" Width="130" BorderBrush="Black">
            <TextBlock FontSize="24" FontWeight="Bold" HorizontalAlignment="Center" VerticalAlignment="Center"
                       Text="{Binding Name}" Foreground="Black" />
        </Border>
    </DataTemplate>
</ListView.ItemTemplate>

Note that I am using a DataTemplate because the ListView is bound to an ObservableCollection in the proper XAML way.

At this point I am close to what I want – never mind that the numbers are missing, they can easily be added with a second ListView:

image

However I do not want that little tick mark appearing, the selected background colour is not to my taste, and the spacing of the items is wrong. How do I fix that?

My search led me to this post which explains a far-from-obvious series of steps you can take in Blend. The steps did not quite work for me but got me on track to create a new Style resource which I called ListViewItemStyleNoGlyph and which lets me adjust the margin and also a previously hidden property called SelectionCheckMarkVisualEnabled. Blend generated a substantial block of code for this:

image

This has helped and now my ListView looks like this:

image

Well, it is nearly there and I can see that with a bit more effort I can get what I want. Even so, I am beginning to wonder whether my initial approach, in which I understood all the code, had advantages over this exploration into the labyrinth.

Is XAML well loved out there? I came across this post by Paul Stovell from a couple of years back which seems relevant. “I’ve lived and breathed the technology for the last six years”, he says, but writes:

What’s disappointing is that WPF started out quite positively during its time. Concepts like dependency properties, styles, templates, and the focus on data binding felt quite revolutionary when Avalon was announced.

Sadly, these good ideas, when put into practice, didn’t have great implementations. Dependency properties are terribly verbose, and could have done with some decent language support. Styles and templates were also verbose, and far more limited than CSS (when WPF shipped I imagined there would be a thousand websites offering high quality WPF themes, just like there are for HTML themes; but there aren’t, because it is hard).

Data binding in WPF generally Just Works, except when it doesn’t. Implementing INotifyPropertyChanged still takes way too much code. Data context is a great concept, except it totally breaks when dealing with items like ContextMenus. ICommand was built to serve two masters; the WPF team who favored routed commands, and the Blend team who favored the command pattern, and ended up being a bad implementation for both.

Stovell mentions the verbosity of XAML, and that it is hard, both of which sound right to me. He contrasts the way ASP.NET has evolved, with ASP.NET MVC a great improvement on web forms. Read the full post for more detail.

It seems to me that XAML does offer much that is wonderful: flexibility, capability, and the ability to separate presentation from data. At the same time, neither XAML nor Blend are intuitive tools for developers; they may make more sense to designers, but it seems to me that removing a tick mark from a ListViewItem should be more straightforward. Perhaps it is, in which case there is a failure of documentation or tooling rather than functionality, but it makes little difference to the developer.