Arthur Wang's Blog
Follow me on
  • My General Blog
  • Software Development
    • Latest Articles on Software Development
    • Complete Resources for Developers >
      • Tutorial Information for Developers
      • .NET Developer Blogs
      • Developer Journals and Magazines
      • Developer's Tools
      • Database Development
      • ​Developer Conference and Events
  • Tech
    • Latest Articles on Technology Development
  • Health
  • Money
  • Services
    • Modern Website Design
    • Web Maintenance of Existing Websites Service
    • Corporate Business Consulting Service
  • About
  • Contact
  • Art
  • 中文部落格

Understanding the New .NET Core Technologies

4/27/2016

0 Comments

 
.NET Code Life Cycle in Desktop and UWP Applications
.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.
Read Part 3 of 3: ​Understanding .NET Native Tool Chain Under the Hood
0 Comments

    Arthur Wang

    @ArthurWangLA
    MCSD App Builder
    MCSD Web Applications
    ​Member of Windows Insider Program & HoloLens Developer Community & Dev Center Insider Program

    Over 17+ years of  experience in web-based software development & management.  Specialized in Microsoft technology with c# language and its architecture design.  MCSD, MCSE, Microsoft Specialist, MCP + Internet, and B.S. from UCLA

    Archives

    August 2018
    March 2018
    January 2017
    December 2016
    May 2016
    April 2016
    March 2016
    February 2016
    April 2014

    Categories

    All
    API
    Arduino
    ASP.NET
    Cognitive
    CSS
    Database
    Deep Learning
    DevOps
    Electronics
    Flexbox
    HTML5
    IoT
    Katana
    Machine Learning
    Management
    .NET
    .NET Core
    Neural Network
    OWIN
    Programming
    Programming Tools
    Recognition
    Security
    SQL Server
    UWP
    Visual Studio
    Web API
    Web Developer

    RSS Feed

    Latest Articles

© 2014-2020 ArthurWiz.com All Rights reserved. | Home | About |
Protected by Copyscape