.NET for Metro style apps

.NET is now a core part of several Microsoft platforms, and each has focused on specific subset of APIs. A lot of thought has been put into crafting each API surface area. Many of you have asked how the .NET APIs available for Metro style apps were chosen. In the following post, Immo Landwerth – a program manager on the CLR’s Core Framework team – provides an answer to this question. — Brandon

Since the releases of the Windows 8 Consumer Preview and the Windows Developer Preview, developers have been busy exploring Windows 8, and many have asked questions about the subset of.NET Framework APIs that can be used to develop Windows Metro style apps. The natural tendency has been to compare the .NET APIs for Metro style apps to those available for other platforms such as Windows Phone. In particular, developers are wondering how much of their existing C# or Visual Basic source code they can expect to reasonably port to build a new Metro style app. We asked ourselves the same question when we carefully designed .NET APIs for Metro style apps.

In this post, I’d like to give you an overview of the APIs that are available to you for building Metro style apps. I will primarily discuss the design principles and requirements we used to decide which .NET Framework APIs to make available for Metro style app development. I will also touch on the relationships between .NET APIs for Metro style apps and other .NET API profiles.

Design goals

From the start of this project, we realized that we had a great opportunity to simplify app development, but also some interesting challenges to resolve. Metro style apps enable developers to provide compelling end-user experiences across all the supported Windows 8 devices. In order to achieve this goal, many important changes were made within Windows, some of which affected our design approach to the .NET Framework APIs that we would expose.

The biggest change, in terms of .NET Framework APIs, was the introduction of the Windows Runtime APIs. The Windows Runtime is a new API surface in Windows that exposes the functionality necessary to write Metro style apps. These APIs were designed to be used from a variety of programming languages: C# and Visual Basic and also native C++ and JavaScript. The task for our design team was to ensure that .NET Framework developers would be able to use both .NET Framework and Windows Runtime APIs together in a way that felt natural and intuitive. Also, the Windows Runtime team worked closely with us and approached the same task from the opposite direction.

We established the following goals to define the API surface of .NET for Metro style apps:

Avoid duplication of functionality between the Windows Runtime and the .NET Framework.

Provide a clear focus on .NET Framework APIs that are needed to write Metro style apps.

Make sure that existing .NET Framework developers will feel at home with this profile.

Make it easy to port existing C# and Visual Basic code to the profile.

We also looked at a collection of Windows Phone and Silverlight apps to determine how developers used .NET Framework APIs in practice. These apps helped us assess the two last goals, in particular.

Designing the API profile

To design a new profile for Metro style apps, it made sense to start from an existing subset of APIs, and to pare it down while extending it toward the goal, which was to provide simple and well-designed .NET Framework APIs that specifically target Metro style app development. Note that the following diagram is intended for illustrative purposes only, and is not drawn to scale.

Figure 1: .NET Framework profiles in context

In this diagram, the smaller circles represent .NET profiles. The intersection of the profiles represents APIs that are common to all the profiles. Conceptually, you can think of .NET for Metro style apps as a subset of the .NET Framework that shares a relationship with other .NET Framework profiles. Portable Class Library does not show up in this diagram as a separate profile, but is a separate concept that deserves a post of its own.

With that diagram in mind, we decided to start with the .NET API subset for the Windows Phone, with selective additions from the full .NET Framework and Silverlight. While Windows Phone apps were likely to be similar to Metro style apps, the introduction of the Windows Runtime in Windows 8 meant that the Windows Phone profile was only a starting point.

API selection process

In addition to the goals discussed earlier, we established a rigorous selection process. We made sure that every API we considered adding passed the criteria defined below:

Is the API applicable to Metro style apps? Of course, the answer isn’t always obvious. For example, ASP.NET APIs are clearly not relevant to Metro style app development, but console APIs could be considered helpful (for example, during testing). When in doubt, we asked ourselves whether we’d want to ship a Metro style app that called the given API, and we removed APIs that simply won’t work in Metro style apps. For example, file access using paths isn’t supported in Metro style apps, because file access is done through a broker process and requires using Windows Runtime APIs, so we removed those APIs.

Is the API obsolete or outdated? This includes APIs that are difficult to use correctly, are confusing, or don’t follow basic design guidelines.

Is the API duplicated by another .NET Framework API in the profile or by a Windows Runtime API? Duplication of APIs means that you have to choose, and this choice is often arbitrary. Duplication also means that you cannot easily share code with other developers, because they might have chosen to use different types in their signatures.

Arriving at the final set of APIs

After our design phase and a progressive series of refinements, we arrived at a set of APIs that met the stated design goals. We validated this set of APIs with the apps that we had available, and requested feedback from Microsoft developers who were involved in early Metro style app development. We made more changes to enable the set of scenarios that the validation exercise uncovered. With the exception of a few more minor changes, this is the surface area we made available for Metro style app development with Visual Studio 11 Developer Preview, and more recently, with Visual Studio 11 Beta.

The diagram below shows the functionality exposed in the .NET for Metro style apps profile. The diagram should match what you see available in Visual Studio 11 Beta. The Windows Dev Center is a great place to explore these new APIs.

Figure 2: Feature areas supported by .NET for Metro style apps

For a more quantitative view, the following table compares the new profile to existing profiles you might be familiar with. It’s not surprising that .NET for Metro style apps is much smaller than the full .NET Framework, and similar in size to the profile for Windows Phone. .NET for Metro style apps is even smaller than the Windows Phone profile, because we removed functionality such as the UI stack and sensors, which is exposed by the Windows Runtime.

Have you used the .NET for Metro style apps and the Windows Runtime APIs to build Metro style apps? Which APIs do you think are missing? Are there any additional APIs that should have been removed? Please tell us what you think.

I am a developer for some successful apps on WP7. I want to convert my apps to W8 but have several stumbling blocks:

Portable Class Library is a great idea but many essential API's are missing. It's only really good for very basic projects. I have still gone back to resorting to if and endif pre-processor directives so my code is portable between W8, W7 and WP7.

A lot of controls don't have an equivelant in W8. When is the Silverlight Toolkit going to be ported in W8 for example.

No Linq To SQL. This is a deal breaker for one of my apps. There are open source alternatives but its a lot of work. I will wait until this is added later on like it was for WP7.

A lot of API's are different even though they seem to do the same thing. I guess this is where WP8 will come in and fix this. Will WP8 deprecate WP7 style API's and introduce W8 API's? We need to know this stuff pretty soon. it might make moving to W8 more palatable.

WP7 badly needs the new parralell task library and async and await keywords to make porting easier. I believe there is a dll we can reference but I think it's in beta.

Overall I've very impressed with the work you are doing but the framework is currently fragmented. There needs to be greater parity between the different versions. I'd be glad if Microsoft could do a little more to answer any of these questions.

@Brad: My best guess: Because System.Collections is essentially obsolete. These are the old non-generic versions of the types in the System.Collections.Generic namespace. No guarantees though as I haven't had a look at any profile beyond the full framework yet.

@Ken: If you just want to create and use local databases, the Extensible Storage Engine (JET Blue) API is apparently available to Metro style applications; see msdn.microsoft.com/…/br205753. It is not SQL though, and I don't know how hard it would be to call from C#. If you want SQL, I guess the easiest solution is to include SQLite-WinRT in your app.

One example: originally I wanted to develop a home accounting app for Win 8 but then realised that the DB access is completely missing, in favour of web calls. This is insane, I won't tell my customers that it's ok to upload all their transactions to some remote DB owned by me. Such things should only be local.