.NET Code Life Cycle in Desktop and UWP Applications
To understand the new .NET technologies, we must first understand the old one in terms of the life cycle of the code from design, build, deploy, to runtime. As we have mentioned previously, one purpose of the old .NET technologies was trying to solve a problem in which that the operating system can accommodate source codes written in different programming languages and deployed the application codes in the form of DLL files. These applications are either Windows Desktop applications or ASP.NET web applications that can be executed by the processor when the user interacts with them on the Windows-based computer or server. At runtime, the CLR executes these DLL files in a Just-In-Time (JIT) fashion. As a result, the startup time for any Windows app is always slow since it needs to do the compilation of the entire application at the first time it loads.
In the .NET Core technologies, one major purpose is to be able to make the source code runnable in multiple platforms regardless of the type of devices: laptop, phone, tablet, and HoloLens. The goal of CoreCLR is to support other operating systems as well. For example, an application written in C# code can be deployed and run on Android phone or iPhone or even on Linux. In contrast, CoreCLR is not used for building for the desktop application, or at least for now. It creates Windows Store application or called the Universal Windows Application and ASP.NET apps and services.
Only a subset of CoreCLR is merged with your app code to produce the final native code. In this way, it minimizes the executable file size and processor's load, and it was already compiled ahead of the time and serves static codes to the processor instead of dynamically. Consequently, the startup time is much faster than the old CLR method. We will describe how it works in detail next.
Prior to Visual Studio 2015, there is no big difference between the Debug mode and Release mode when you are running your application in term of the process of building the application. The build process is similar except there are more debugging features participating in the process. In the Visual Studio 2015, there is a significant difference between these modes on how the build process is done. In the release mode, it goes through .NET Native process where the .NET Native tool chain compiles the IL (Intermediate Language) binaries into native binaries. Unlike the old way, this time, you need to specify the CPU architecture that this app deploys to. In the Debug mode, you are running in a similar fashion to the previous Visual Studio, but instead of using the CLR, you are using the CoreCLR, a brand new .NET Core Runtime, to compile and run your codes. This new CoreCLR supposes to give you fast compilation and deployment and rich debugging and diagnostics features.
Unlike the old way where you package your final codes into executable files, such as DLL or EXE, which look identical to the files running in the release mode, you will need to fill some additional information about your application on a submission form and a package will be created by the Visual Studio for submitting to the Windows Store. The final package you are submitting to the store is not in the form of native binaries, but they are IL binaries instead. It is because the Windows Store will take care of the final build for your application. It creates different app packages by using the .NET Native tool chain depending on what CPU architectures you specified on the submission form that your apps can run on.
In the .NET Core technologies, one major purpose is to be able to make the source code runnable in multiple platforms regardless of the type of devices: laptop, phone, tablet, and HoloLens. The goal of CoreCLR is to support other operating systems as well. For example, an application written in C# code can be deployed and run on Android phone or iPhone or even on Linux. In contrast, CoreCLR is not used for building for the desktop application, or at least for now. It creates Windows Store application or called the Universal Windows Application and ASP.NET apps and services.
Only a subset of CoreCLR is merged with your app code to produce the final native code. In this way, it minimizes the executable file size and processor's load, and it was already compiled ahead of the time and serves static codes to the processor instead of dynamically. Consequently, the startup time is much faster than the old CLR method. We will describe how it works in detail next.
Prior to Visual Studio 2015, there is no big difference between the Debug mode and Release mode when you are running your application in term of the process of building the application. The build process is similar except there are more debugging features participating in the process. In the Visual Studio 2015, there is a significant difference between these modes on how the build process is done. In the release mode, it goes through .NET Native process where the .NET Native tool chain compiles the IL (Intermediate Language) binaries into native binaries. Unlike the old way, this time, you need to specify the CPU architecture that this app deploys to. In the Debug mode, you are running in a similar fashion to the previous Visual Studio, but instead of using the CLR, you are using the CoreCLR, a brand new .NET Core Runtime, to compile and run your codes. This new CoreCLR supposes to give you fast compilation and deployment and rich debugging and diagnostics features.
Unlike the old way where you package your final codes into executable files, such as DLL or EXE, which look identical to the files running in the release mode, you will need to fill some additional information about your application on a submission form and a package will be created by the Visual Studio for submitting to the Windows Store. The final package you are submitting to the store is not in the form of native binaries, but they are IL binaries instead. It is because the Windows Store will take care of the final build for your application. It creates different app packages by using the .NET Native tool chain depending on what CPU architectures you specified on the submission form that your apps can run on.
Read Part 3 of 3: Understanding .NET Native Tool Chain Under the Hood
RSS Feed
