Introducing. NET Core

at Connect (), we announce that the. NET core will be fully released as open source software. I also agree with more details on the. NET Core. In this article, I will provide the. NET core, how we go about releasing it, how it relates to the. NET Framework, and what this means for cross-platform and open source development profiles.

Looking back--inspiring. NET Core

for the first time, let's look back and see how the. NET platform is packaged in the past. This helps motivate some of the decisions and results created by the. NET core idea.

. net--this set of vertical markets

we initially shipped the. NET framework in 2002 with only a single framework. Soon after, we released the. NET Compact Framework that is suitable for smaller devices, specifically for a subset of the Windows Mobile footprint. NET Framework. The Compact Framework is a separate code base from the. NET framework. It includes the entire vertical: the runtime, the framework, and the application model on top.

Since then, we have practiced this subset several times: Silverlight,windows Phone and most recently for the Windows store. This can result in fragmentation because the. NET platform is not a single entity, but a set of platforms that are owned and maintained independently by different teams.

of course, there's something wrong with providing specialized functionality to meet specific needs. But it becomes a problem if no systematic approach and specialization takes place at a very small level in the other vertical corresponding layers without regard to each layer. The result is a set of APIs that share only the fact that they started from the common code base of the platform. over time this will lead to more disagreement unless explicit (and expensive) measures take a convergent Api.

What is the problem of fragmentation? If you only target a single vertical then there really is no problem. you provide an API set that optimizes your vertical. as long as you want the target level, this is multiple vertical problems. Now, you have to have the APIs available for the reason and to come up with a way to produce the vertical cross-working assets that you want to target.

today it is extremely common to have cross-device applications: There is almost always running on a Web server, often an administrative front end using a Windows desktop and a set of mobile applications exposed to consumers that are available for multiple devices. Therefore, it is critical to support developers in building components that can be vertically across all of the. NET.

The birth of the Portable class library

Initially, there is no concept of cross-industry sharing of code. There are no portable class libraries, no shared items. you are basically trapped with the creation of multiple projects, linked files and #if . This makes a daunting task for multiple verticals.

during the Windows 8 week we caught up with a plan to deal with the problem. When we designed the Windows store profile we introduced a subset of new conceptual models in a better way: contracts.

originally, the. NET framework was built around the assumption that as a single unit, deployment has always been, so factoring business does not care. everything depends on the core conference is mscorlib. The Mscorlib.net framework provides the inclusion of many features that cannot be supported everywhere (for example, remoting and Appdomain). This forces the core of each vertical subset platform. This makes it very complex tool to get your target multiple vertical class library experience.

the conceptual contract is to provide a well-constructed API surface area. The contract is simply against the compiled assembly. the contract assembly with the regular assembly is designed around the appropriate factoring business. We are deeply concerned about the contracts between these dependencies, they have only a single responsibility, not the Api of being caught. Standalone contract versions and assemblies that follow the correct versioning rules, such as adding API results in newer versions.

we use contracts to cross all vertical market model API sets. vertically You can then simply select the contract they want to support. An important aspect is that the vertical must support the contract, wholesale or not at all. In other words, they cannot subset the contents of the contract.

This allows for reasoning about vertical at the assembly level, rather than the API differences that we used at the individual API level. This allows us to provide experience in libraries that can target multiple industries, also known as portable class libraries.

Unified and unified execution API shapes

You can consider a portable class library as a combination of different. NET vertical experiences based on their API shapes. the most pressing need to solve this problem is the ability to create a library that runs vertically in different. NET. It also serves as a design tool to drive convergence between vertical, for example, Windows 8.1 and Windows Phone 8.1.

However, we still have different implementations--or fork--.net platforms. Those implemented by different teams, versions are independent and have different transport vehicles. This makes the Unified API shape a constant challenge: The API is only portable when the execution crosses all vertical forward movements, but because of the different codebase, it is quite expensive and therefore always obeys (rare earths) to prioritize. Even if we can do a perfect job by converging the API: all vertical have different transport vehicles, which means that certain parts of the ecosystem will always fall behind.

A better approach to unified implementation: instead of just providing a well-constructed view, we should provide a well-constructed implementation. This allows the same implementation to be shared vertically and simply. Convergence will no longer be extra; it was built through. Of course, there are situations where we may need multiple implementations. file I/O, which requires the use of different technologies, is a good example of environment-based. However, it is much simpler to ask each team to have specific components and think about their API across all vertical markets than to try to provide a consistent API stack on top of the work. This is because portability is not a thing you can provide later. For example, our file Api includes support for Windows access control lists (ACLs) and cannot be supported in all environments. the design of the API must consider this issue, and, for example, provide this functionality on a platform that does not support ACLs in a separate assembly that can be omitted.

Full-machine framework and local application framework

Another interesting challenge is how to deploy with the. NET Framework.

the. NET Framework is a machine-wide framework. Any changes that you make to it affect all applications with its dependencies. having a machine-wide framework is a deliberate decision because it solves these problems:

1. It allows centralized service
2. It reduces disk space
3. Allow native images to be shared between applications

But it also has to pay a price.

First , it is a complex application developer who takes a dependency on the recently announced framework. You must bring the latest operating system dependencies or applications that are installed when the Setup program for the application is able to install the. NET Framework. If you are a Web developer you may not even have this option because the IT department tells you which version you are allowed to use. If you are a mobile developer you really do not have a choice but your target operating system.

But even if you are willing to trouble by providing the installer to install the chain in the. NET Framework, you may find that upgrading the. NET Framework can break other applications.

insist--don't we say our upgrade is highly compatible ? we all are. and we are very serious about compatibility. We have a rigorous review of any changes made to the. NET Framework. Any impact that may be materially changed as we have a special review investigation. We run a compatible lab, where we test many popular. NET applications to make sure we don't return to them. We also have the ability to tell the application to compile the. NET framework. This allows us to maintain compatibility with existing applications and, at the same time, to provide better behavior for the application by choosing the. NET framework that is the newer version of the final target.

Unfortunately, we also learn that even compatible changes can disrupt the application. Let me give you a few examples:

• adding an interface to an existing type can break the application because it may interfere with how the type is serialized.

• Previously there were no overloaded methods to add overloads that could break the reflective consumer that never handled the discovery of more than one method.

• renaming an internal type can break the application if the type name is surfaced through the ToString () method.

Those are rare cases, but when you have 1.8 billion machines compatible with 99.9% of the customer base can still mean that 1.8 million machines are affected.

more interestingly, repairing the affected application in many cases is quite trivial. The problem is that application developers do not necessarily involve interruptions when they occur. Let's take a look at a specific example.

you test your application on. NET Framework 4, which is the installation you have with your application. But some first day your customer installs another application to upgrade to the. NET Framework 4.5 machine. You do not know that your application is broken until the customer calls your support. dealing with compatibility issues with your application at this point is quite expensive because you have to get the appropriate source, set up the filming machine, debug the application, make the necessary changes, they incorporate the release branch, generate a new version, test it, and finally release the update for your customers.

This is in contrast to the situation where you decide that you want to take advantage of publishing features in the newer version of the. NET Framework. at this point in the development process, you are ready to make changes to your application. If there is a slight compatibility failure, you can easily handle it as part of the functional work.

because of these issues, we spent some time releasing a new version of the. NET Framework. the more drastic the change, the more time we need to bake it. This results in a paradoxical situation where our beta has been quite locked down and we can hardly take a design change request.

Two years ago, we had started on board the NuGet library. Because we didn't add these libraries to the. NET Framework we called them "in-band". with out-of-band libraries We're just talking, because they're an application-local problem. in other words, the library is deployed if they are part of your application.

this largely resolves any issues that prevent you from upgrading to a newer version. You take a newer version of the ability to only limit the ability to release an updated version of your application. This also means that you are controlling which version of the library is taking advantage of a particular application. The upgrade is complete without affecting other applications running on the same machine in the context of a single application.

This enables us to release updates in a more flexible and diverse manner. NuGet also provides a preview version that lets us release the notion that a bit has not yet been submitted for a particular API or behavior. this supports workflow, where we can provide you with our latest design, as well-if you don't like it-just change it. A good example of this is the immutable collection. It has a period of about nine months between probation. We spent a lot of time trying to get the right design before we shipped the first version. it goes without saying that the final design-thanks to you for the extensive feedback-is better than the initial version.

Enter. NET Core

all of these aspects enable us to rethink and change the styling of the forward. NET platform approach. This results in. NET Core Authoring:

The. NET core is a modular implementation that can be used in a variety of vertical scaling from a touch-based device to a data center that is available as open source and supported by Microsoft Windows, Linux and Mac OSX.

Let me go into how the. NET core looks like, it's how to solve the problem I discussed in more detail earlier.

Unified implementation for. NET native and ASP.

when we design. NET native It is clear that we cannot use the. NET Framework-based framework class library. This is because. NET native is basically merging with the application framework and then removing fragmentation, which is not required by the application before it generates native code (I greatly simplify this process here.) For more details, take a look at this deep dive). As I have just said, the. NET framework does not consider making it extremely challenging, the linker to reduce how much of the framework gets compiled into an application-dependency blocking is too large.

ASP. 5 is facing a similar challenge. Although one of the goals of the new ASP. NET 5 Web stack is to provide XCOPY deployment stacks so that Web developers do not coordinate with their IT department to be able to rely on later versions. In this case it is also important to minimize the size of the frame as it needs to be deployed with the application.

The . NET core is essentially the implementation of the Fork NET framework and also optimizes the attention of the factoring business around. Although the scenario for. NET Native (touch-based) and ASP. 5 (server-side web development) is completely different, we can provide a unified base Class library (BCL).

The . NET Core BCL API table area is the same as from these two. NET native and ASP. 5. at the bottom of the BCL we have a very thin layer specific to the. NET Runtime. We currently have two implementations: one is specific to the native. NET runtime and one that is specific to CoreCLR, using ASP. However, the layer does not change very often. It contains types, such as strings and Int32. The vast majority of BCL are pure MSIL assemblies that can be shared-yes. In other words, the API does not just look the same-they share the same implementation. For example, there is no reason to have different implementations of the collection.

BCL, in addition to the application model-specific APIs. For example,. NET native aspects provide APIs that are specific to Windows client development, such as WinRT Interop. ASP. NET 5 is an API that is added as MVC is specific to server-side web development.

we believe that the. NET core is not specific to. NET native 5--BCL and the runtime environment is generally used for modular design. Therefore, it is based on all future. NET Vertical markets.

NuGet as a first-class vehicle

with the. NET Framework, the. NET core platform will be delivered as a set of NuGet packages. We've landed on NuGet because this is where the vast majority of library ecosystems are already.

in order to continue our modular and well-structured efforts we are not just providing the entire. NET core platform as a single NuGet package. Instead, it is a set of fine-grained NuGet packages:

For the BCL layer, we will have 1 to 1 relationships between the assembly and the NuGet package.

forward, the NuGet package will have the same name as the assembly. For example, immutable collections are no longer delivered in a package called Microsoft.Bcl.Immutable, but instead are called System.Collections.Immutable packages .

In addition, we have decided to make semantic versioning available for our Assembly versioning. the version number of the NuGet package aligns the assembly version to the alignment.

The alignment between naming and versioning of assemblies and packages helps greatly with discovery. no longer the mystery of the NuGet package contains System.foo, Version = 1.2.3.0--It is provided by the System.foo package 1.2.3 version.

NuGet allows us to deliver. NET core in an agile manner. So if we offer to upgrade to any NuGet package, you can simply upgrade the appropriate NuGet reference.

providing the framework itself to NuGet also removes the difference between 1-party. NET Dependencies and third-party dependencies-they are all NuGet dependencies. This enables third-party packages to express, for example, they need a higher version of the System.Collections library. Installing this third-party package now prompts you to upgrade your reference to System.Collections. The dependency graph you don't need to know-you just have to agree to make changes to it.

NuGet is also turned into a. NET core platform for the on-premises application framework based on delivery. the modular design of the. NET core ensures that each application needs only to deploy it. We are also enabling smart sharing if multiple applications use the same frame bit. However, the goal is to ensure that each application logically has its own framework so that the upgrade does not interfere with other applications running on the same machine.

we decided that using NuGet as a delivery mechanism would not change our commitment to compatibility. We continue to be extremely serious about compatibility and will not make significant changes to the API or behavior once the package is marked as stable. However, application-local deployment ensures that the situation where change is considered an additive interrupt application is seldom an isolated development time only. In other words, these breaks for. NET core can only occur after you upgrade the package reference. At that moment, you have two options: resolve the failure in the application, compatibility or rollback to the previous version of the NuGet package. but the. NET framework with those breaks will not occur after you deploy to a customer or production server application.

The business is ready.

The NuGet deployment model enables an agile version and a faster upgrade. However, we do not want to compromise, and the. NET Framework provides a one-stop-service experience today.

One of the great things about the. NET Framework is that it acts as a monolithic unit, which means that Microsoft tests and supports all components as a single entity for a vessel. for the. NET Core we will provide the same experience. We will create a concept of a. NET core distribution. This is basically just a snapshot of all the packages in a specific version of which we tested them.

The idea is that our team usually has a single package. the new version of the shipping team package only requires the team to test their components in the context of the components they depend on. because you can mix and match NuGet packages It is obviously possible to play together in some combinations of components that are not good. Distribution does not have this problem because all components are tested in combination.

we expect to distribute at a lower rhythm than a single package shipped. We are currently considering four times a year. This allows for time and it will take us to run the necessary tests to determine the signature.

although. NET core delivery as a set of NuGet packages does not mean that you must download the package every time you need to create a project. We will provide offline installers for distribution, and also include them with Visual Studio so that creating new projects will be as fast as today and do not require an Internet connection in the development process.

Although application-local deployment is well suited to the impact of isolation, a dependency on a newer feature does not apply to all situations. Critical Security patches must be quick to deploy and comprehensive in order to be effective. We are fully committed to making security patches, because we are always on. NET.

to avoid compatibility issues, we have seen security vulnerabilities in the past with the. NET framework that are critical to these unique targets. of course, there are also small opportunities for destroying existing applications. That's why we only have to do the really critical problem, and it is able to accept applications that make a very small group of applications that are no longer working, and not all of them running with this vulnerability.

Foundation open source and cross platform

with. NET cross-platform in a sustainable way, we decided to open source. NET Core .

from past experience we understand that successful open source is the community function around it. A key aspect of this is the open and transparent development process that enables communities to participate in code reviews, read design documents, and assist with product changes.

Open source allows us to extend. NET Unified, cross-platform development. If the basic components, such as collections, need to perform multiple positive pain ecosystems. the goals of the. NET core have a single code base that you can use to build and support all platforms, including Windows, Linux, and Mac OSX.

of course, some components, such as file systems, require different implementations. The NuGet deployment model allows us to abstract out these differences. We can have a single NuGet package that provides a number of implementations for each environment. However, the important part is that this is the implementation detail of this component. All consumers see a unified API that happens to work on all platforms.

Another way to look at this is that the open source of desire is the continuation of desire we release. NET components in an agile way:

1. Open source provides the implementation and general direction of quasi-real-time communication technology
2. Release to nuget.org package provides at the component level agility
3. Release provides platform-level agility

At all three elements allows us to provide broad agility and maturity.

. NET core relationships with existing platforms

While we design the. NET core, it will be the foundation of all the stacks of the future, and we know very well the dilemma of creating "a universal stack" that everyone can use:

we believe that the future we find lays the groundwork, while maintaining a good balance of interoperability with existing stacks. I went to see a few of these platforms for more details.

. NET Framework 4.6

The. NET Framework remains a platform for choosing to build rich desktop applications and the. NET core does not change.

Vision Studio 2015 Our goal is to ensure that the. NET core is a pure subset of the. NET Framework. In other words, there should be no functional gap. Visual Studio After 2015 we expect that. NET core will be faster than the version of the. NET Framework. This means that the feature will only be at the point of time that is available on the. NET core platform.

we will continue to release updates to the. NET Framework. Our current idea is that the release rhythm will be roughly the same today, which is once a year. In these updates, we will take our innovation in the. NET core to the. NET Framework. We will not just blindly port the functions of the work, although-it will be based on cost-benefit analysis. As I pointed out, the. NET Framework even additive changes can cause problems with existing applications. Our goal is to minimize API and behavioral differences without breaking the compatibility of existing. NET Framework applications.

There are also specific ongoing work that we advertise in the WPF roadmap for. NET Framework Investments .

Single channel

Many of you ask a single cross-platform story about what the. NET core means. the Mono project is essentially an open source re-implementation of the. NET Framework. It shares a rich Api with the. NET framework, but there are some issues, especially around the implementation of factoring business.

living alone, it works well on top of a large ecological system. This is why, independent. NET core, we have also released the. NET Framework reference source under open source friendly licensing on GitHub section. The purpose of this is to enable mono society to use the same code to close the gap between the. NET framework and Mono. However, the complexity of the. NET Framework we are not installing on GitHub to run it as an open source project. In particular, we are unable to accept requests for it.

another way to look at it: the. NET framework has essentially two forks. A fork is provided by Microsoft, just Windows. Other forks are channels, you can use Linux and Mac.

with the. NET core we are able to develop the entire. NET stack as a fully open source project. Therefore, it is no longer necessary to maintain separate forks: with Mono society we will vigorously. NET Core Windows, Linux, and Mac OSX. This also enables the mono community to innovate in a streamlined. NET core stack, and take into account the environment that Microsoft is not interested in.

Windows Store and Windows Phone

Windows Store 8.1 and the Windows Phone 8.1 platform have a number of smaller. NET framework subsets. However, they are also subsets of the. NET Core. This enables us to use the. NET core as the underlying implementation of the two forward platforms. So if you are going for these platforms will be able to directly consume all the innovations without waiting for the updated framework.

This also means that the number of BCL APIs available on these two platforms will be exactly the same as those you can see in ASP. NET 5 today. For example, this includes a non-generic collection. This will make it easier for you to bring in the existing code that runs on the. NET framework based on the application experience.

Another obvious side effect is that the BCL Api in Windows Store and Windows Phone is fully converged and the underlying. NET platform is now two powered by. NET core will continue to converge.

Sharing code between. NET core and other. NET Platforms

Because the. NET core lays out the future of all. NET platform code with. NET core based on a shared platform has become frictionless.

Here's the problem code share how to use a platform that is not based on. NET core, such as the. NET Framework. The answer is: As it is today, you can continue to use portable class libraries and shared projects:

• Portable class Libraries are great when your common code is platform-independent and platform-specific code as a reusable library location can be decomposed.

• Sharing Items is great for code, and when your common code has several platforms specific to it, because you can adapt it with #if .

choose between the two for more details and see this blog post.

moving forward, the Portable class library will also support the underlying platform for. NET Core. The only difference is that if you have only the target. NET Core Foundation platform you don't want a fixed set of APIs. Instead, it is based on the NuGet package that you can upgrade in.

If you are not based on at least one platform on. NET core, you are being exposed to APIs that can share it. In this mode, you will still be able to upgrade the NuGet package, but you may be prompted to choose a higher version of the platform or completely abandon support for them.

This approach allows you to coexist in both worlds while also gaining the benefits of the. NET Core.

Introducing. NET Core