.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.

Table: API surface counts, by .NET Profile

Learn more

If you want to learn more about the thinking process that went into the design of the API surface area, watch Krzysztof Cwalina’s A .NET developer’s view of Windows 8 app development talk from the BUILD conference.

If you’re interested in porting your existing .NET Framework code, watch Daniel Plaisted’s BUILD talk Bringing existing managed code into Metro style apps, and check out the .NET for Metro style apps overview in the Windows Dev Center, especially the section about converting your existing .NET Framework code.

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.