{"id":18534,"date":"2014-12-04T13:10:00","date_gmt":"2014-12-04T13:10:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/dotnet\/2014\/12\/04\/introducing-net-core\/"},"modified":"2021-09-30T16:11:15","modified_gmt":"2021-09-30T23:11:15","slug":"introducing-net-core","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/introducing-net-core\/","title":{"rendered":"Introducing .NET Core"},"content":{"rendered":"

At connect()<\/a>, we announced that .NET Core will be entirely released as open source software<\/a>. I also promised to follow up with more details on .NET Core. In this post, I\u2019ll provide an overview of .NET Core, how we\u2019re going to release it, how it relates to the .NET Framework, and what this means for cross-platform and open source development.<\/p>\n

Looking back \u2013 motivating .NET Core<\/h2>\n

First let\u2019s look back to understand how the .NET platform was packaged in the past. This helps to motivate some of the decisions and ideas that resulted in the creation of .NET Core.<\/p>\n

.NET \u2013 a set of verticals<\/h2>\n

When we originally shipped the .NET Framework in 2002 there was only a single framework. Shortly after, we released the .NET Compact Framework which was a subset of the .NET Framework that fit within the footprint of smaller devices, specifically Windows Mobile. The compact framework was a separate code base from the .NET Framework. It included the entire vertical: a runtime, a framework, and an application model on top.<\/p>\n

Since then, we\u2019ve repeated this subsetting exercise many times: Silverlight, Windows Phone and most recently for Windows Store. This yields to fragmentation because the .NET Platform isn\u2019t a single entity but a set of platforms, owned by different teams, and maintained independently.<\/p>\n

Of course, there is nothing wrong with offering specialized features in order to cater to a particular need. But it becomes a problem if there is no systematic approach and specialization happens at every layer with little to no regards for corresponding layers in other verticals. The outcome is a set of platforms that only share APIs by the fact that they started off from a common code base. Over time this causes more divergence unless explicit (and expensive) measures are taken to converge APIs.<\/p>\n

\"\"<\/a><\/p>\n

What is the problem with fragmentation? If you only target a single vertical then there really isn\u2019t any problem. You\u2019re provided with an API set that is optimized for your vertical. The problem arises as soon as you want to target the horizontal, that is multiple verticals. Now you have to reason about the availability of APIs and come up with a way to produce assets that work across the verticals you want to target.<\/p>\n

Today it\u2019s extremely common to have applications that span devices: there is virtually always a back end that runs on the web server, there is often an administrative front end that uses the Windows desktop, and a set of mobile applications that are exposed to the consumer, available for multiple devices. Thus, it\u2019s critical to support developers in building components that can span all the .NET verticals.<\/p>\n

Birth of portable class libraries<\/h2>\n

Originally, there was no concept of code sharing across verticals. No portable class libraries, no shared projects<\/a>. You were essentially stuck with creating multiple projects, linked files, and #if<\/code>. This made targeting multiple verticals a daunting task.<\/p>\n

In the Windows 8 timeframe we came up with a plan to deal with this problem. When we designed the Windows Store profile<\/a> we introduced a new concept to model the subsetting in a better way: contracts.<\/p>\n

Originally, the .NET Framework was designed around the assumption that it\u2019s always deployed as a single unit, so factoring<\/a> was not a concern. The very core assembly that everything else depends on is mscorlib. The mscorlib provided by the .NET Framework contains many features that that can\u2019t be supported everywhere (for example, remoting and AppDomains). This forces each vertical to subset even the very core of the platform. This made it very complicated to tool a class library experience that lets you target multiple verticals.<\/p>\n

The idea of contracts is to provide a well factored API surface area. Contracts are simply assemblies that you compile against. In contrast to regular assemblies contract assemblies are designed around proper factoring. We deeply care about the dependencies between contracts and that they only have a single responsibility instead of being a grab bag of APIs. Contracts version independently and follow proper versioning rules, such as adding APIs results in a newer version of the assembly.<\/p>\n

We\u2019re using contracts to model API sets across all verticals. The verticals can then simply pick and choose which contracts they want to support. The important aspect is that verticals must support a contract either wholesale or not at all. In other words, they can\u2019t subset the contents of a contract.<\/p>\n

This allows reasoning about the API differences between verticals at the assembly level, as opposed to the individual API level that we had before. This aspect enabled us to provide a class library experience that can target multiple verticals, also known as portable class libraries.<\/p>\n

Unifying API shape versus unifying implementation<\/h2>\n

You can think of portable class libraries as an experience that unifies the different .NET verticals based on their API shape. This addressed the most pressing need, which is the ability to create libraries that run on different .NET verticals. It also served as a design tool to drive convergence between verticals, for instance, between Windows 8.1 and Windows Phone 8.1.<\/p>\n

However, we still have different implementations \u2013 or forks \u2013 of the .NET platform. Those implementations are owned by different teams, version independently, and have different shipping vehicles. This makes unifying API shape an ongoing challenge: APIs are only portable when the implementation is moved forward across all the verticals but since the code bases are different that\u2019s fairly expensive and thus always subject to (re-)prioritization. And even if we could do a perfect job with converging the APIs: the fact that all verticals have different shipping vehicles means that some part of the ecosystem will always lag behind.<\/p>\n

A much better approach is unifying the implementations: instead of only providing a well factored view, we should provide a well factored implementation. This would allow verticals to simply share the same implementation. Convergence would no longer be something extra; it\u2019s achieved by construction. Of course, there are still cases where we may need multiple implementations. A good example is file I\/O which requires using different technologies, based on the environment. However, it\u2019s a lot simpler to ask each team owning a specific component to think about how their APIs work across all verticals than trying to retroactively providing a consistent API stack on top. That\u2019s because portability isn\u2019t a something you can provide later. For example, our file APIs include support for Windows Access Control Lists (ACL) which can\u2019t be supported in all environments. The design of the APIs must take this into consideration, and, for instance, provide this functionality in a separate assembly that can be omitted on platforms that don\u2019t support ACLs.<\/p>\n

Machine-wide frameworks versus application-local frameworks<\/h2>\n

Another interesting challenge has to do with how the .NET Framework is deployed.<\/p>\n

The .NET Framework is a machine-wide framework. Any changes made to it affect all applications taking a dependency on it. Having a machine-wide framework was a deliberate decision because it solves those issues:<\/p>\n

    \n
  1. It allows centralized servicing<\/li>\n
  2. It reduces the disk space<\/li>\n
  3. Allows sharing native images between applications<\/li>\n<\/ol>\n

    But it also comes at a cost.<\/p>\n

    For one, it\u2019s complicated for application developers to take a dependency on a recently released framework. You either have to take a dependency on the latest OS or provide an application installer that is able to install the .NET Framework when the application is installed. If you\u2019re a web developer you might not even have this option as the IT department tells you which version you\u2019re allowed to use. And if you\u2019re a mobile developer you really don\u2019t have choice but the OS you target.<\/p>\n

    But even if you\u2019re willing to go through the trouble of providing an installer in order to chain in the .NET Framework setup you may find that upgrading the .NET Framework can break other applications.<\/p>\n

    Hold on \u2013 aren\u2019t we saying that our upgrades are highly compatible? We are. And we take compatibility extremely seriously. We have rigorous reviews for any changes made to the .NET Framework. And for anything that could be a breaking change we have dedicated reviews to investigate the impact. We run a compat lab where we test many popular .NET applications to ensure that we don\u2019t regress them. We also have the ability to tell which .NET Framework the application was compiled against. This allows us to maintain compatibility with existing applications while providing a better behavior for applications that opted-into targeting a later version of the .NET Framework.<\/p>\n

    Unfortunately, we\u2019ve also learned that even compatible changes can break applications. Let me provide a few examples:<\/p>\n