Introduction to ASP.NET 5
Everyone has their own way of acquaintance with ASP.NET 5. And the earlier you start it, the better. Understanding the "ASP.NET 5" is necessary for everyone involved in developing on the .NET platform. Since "ASP.NET 5" is not really about the web. More precisely, not only about the web. After reviewing the N-th number of videos and reading even more blogs (the documentation is not ready yet), there was an overwhelming desire to write something somewhere.
ASP.NET 5 is not just another version of ASP.NET within the .NET Framework. In fact, this is a new Framework without CLR (which is installed separately) and without BCL (which has evolved into a set of NuGet packages that are installed from nuget.org).
The separation of the CLR from the Framework is done through a tricky thing called DNX - .NET Execution Environment. There is no longer a separation between design-time and run-time. There are no more separate dependencies in assemblies, between projects and between nuget-packages. Now there is just an addiction. This can be a project (in source), an assembly (dll) or a Nuget package. For a project in source code, its dependencies are specified in the project.json file, which does not depend on the platform and the IDE used. When a dependency is resolved (no matter at runtime or at design-time), it is either just loaded (build), or downloaded (nuget), or compiled by Roslyn (source). So using Roslyn is supported on-the-fly compilation. For example, in a deployed application, you can replace a dependent project with its sources.
')
The system may have several dnx. To manage them there is a set of scripts (PowerShell) dnvm - .NET Version Manager. Obviously some analogue of NVM (Node Version Manager).
There is DNX using CLR from the full .NET Framework, there is for Mono and there is for CoreCLR (cross-platform CLR, which will soon work on Linux and MacOS besides Windows). CoreXR DNX includes CLR inside.
The situation is somewhat confused due to the fact that a lot of new abbreviations, plus recently (on the eve of dotnetConf ) there was a powerful rebranding (is it the last one?). Previously, DNX was called KRE (and the host process is klr.exe) (in VS CTP6 this is still the case), DNVM is KVM. There was also KPM (K Package Manager), now it's just Nuget.
Realizing that AspNet5 is not Asp.Net, but a new .NET, the “ASP.NET 5 Console Application” project template is no longer shocking. This is really a console application under the DNX infrastructure.
It's funny that the Build project in VS by default does not create any dll in the bin folder, as before. You can enable the “Produce outputs on build” option in the VS project settings (yes, the VS project file is still .kproj, but it is now optional), then Build will create a dll in the $ solutionDir \ artifacts \ bin \ ConsoleApp1 \ Debug \ folder aspnet50 \. Where “aspnet50” is the name of the framework or runtime flavor. In addition to aspnet50, there is also aspnetcore50. What is “framework” in the context of DNX is not completely clear to me. But, roughly speaking, this is a set of DNX of the same type: either based on the CLR from the .NET Framework, or based on CoreCLR.
All DNX are stored in the user profile: C: \ Users \ Shrike \ .dnx \ runtimes
In older versions (for VS CTP6 is still): C: \ Users \ Shrike \ .k \ runtimes
In the same place, by the way, the cache of all packages is stored - \ .dnx \ packages \
Apparently, thanks to this cache when editing project.json in VS, intelliSence is supported when editing dependencies:
You can see all DNX installed on the system using the dnvm list command. One of DNX is “default”, it is used by VS, unless the runtime type is explicitly specified for the project.
Note that the build of the console application creates a dll, not an exe. But how to start it now (not from VS)?
To run an application, you need to publish it - we create Publish from VS. This can also be done from the command line using dnu publish. When publishing, we specify the publish target. For the console application, only the “File System” target is currently available. The set of publish targets will expand. For example, Azure Websites is already available for a Web application. When publishing to the File System, we select the folder in which the distribution will be placed. It will create:
The ConsoleApp1.cmd script launches our application with the command:
This is what happens. The program’s distribution contains .NET itself. More precisely contains DNX. In this case, the DNX used uses the CLR from the global .NET on the machine. But the application can be published using CoreXR's DNX. And then, the distribution will contain everything (since DNX for CoreCLR contains the CLR itself), which is required by the application.
More details about DNX and otherhorror runtime in MSDN Mag .
After all this, the statement that ASP.NET 5 does not depend on System.Web seems to be obvious at all. ASP.NET 5 does not depend on anything. ASP.NET 5 is a new runtime and a huge amount of NuGet packages containing everything that was in the BCL Framework (just rewritten). Many Microsoft.AspNet. * Packages can be conditionally combined into “ASP.NET 5”.
ASP.NET 5 is not just another version of ASP.NET within the .NET Framework. In fact, this is a new Framework without CLR (which is installed separately) and without BCL (which has evolved into a set of NuGet packages that are installed from nuget.org).
The separation of the CLR from the Framework is done through a tricky thing called DNX - .NET Execution Environment. There is no longer a separation between design-time and run-time. There are no more separate dependencies in assemblies, between projects and between nuget-packages. Now there is just an addiction. This can be a project (in source), an assembly (dll) or a Nuget package. For a project in source code, its dependencies are specified in the project.json file, which does not depend on the platform and the IDE used. When a dependency is resolved (no matter at runtime or at design-time), it is either just loaded (build), or downloaded (nuget), or compiled by Roslyn (source). So using Roslyn is supported on-the-fly compilation. For example, in a deployed application, you can replace a dependent project with its sources.
')
The system may have several dnx. To manage them there is a set of scripts (PowerShell) dnvm - .NET Version Manager. Obviously some analogue of NVM (Node Version Manager).
There is DNX using CLR from the full .NET Framework, there is for Mono and there is for CoreCLR (cross-platform CLR, which will soon work on Linux and MacOS besides Windows). CoreXR DNX includes CLR inside.
The situation is somewhat confused due to the fact that a lot of new abbreviations, plus recently (on the eve of dotnetConf ) there was a powerful rebranding (is it the last one?). Previously, DNX was called KRE (and the host process is klr.exe) (in VS CTP6 this is still the case), DNVM is KVM. There was also KPM (K Package Manager), now it's just Nuget.
Realizing that AspNet5 is not Asp.Net, but a new .NET, the “ASP.NET 5 Console Application” project template is no longer shocking. This is really a console application under the DNX infrastructure.
It's funny that the Build project in VS by default does not create any dll in the bin folder, as before. You can enable the “Produce outputs on build” option in the VS project settings (yes, the VS project file is still .kproj, but it is now optional), then Build will create a dll in the $ solutionDir \ artifacts \ bin \ ConsoleApp1 \ Debug \ folder aspnet50 \. Where “aspnet50” is the name of the framework or runtime flavor. In addition to aspnet50, there is also aspnetcore50. What is “framework” in the context of DNX is not completely clear to me. But, roughly speaking, this is a set of DNX of the same type: either based on the CLR from the .NET Framework, or based on CoreCLR.
All DNX are stored in the user profile: C: \ Users \ Shrike \ .dnx \ runtimes
In older versions (for VS CTP6 is still): C: \ Users \ Shrike \ .k \ runtimes
In the same place, by the way, the cache of all packages is stored - \ .dnx \ packages \
Apparently, thanks to this cache when editing project.json in VS, intelliSence is supported when editing dependencies:
You can see all DNX installed on the system using the dnvm list command. One of DNX is “default”, it is used by VS, unless the runtime type is explicitly specified for the project.
Note that the build of the console application creates a dll, not an exe. But how to start it now (not from VS)?
To run an application, you need to publish it - we create Publish from VS. This can also be done from the command line using dnu publish. When publishing, we specify the publish target. For the console application, only the “File System” target is currently available. The set of publish targets will expand. For example, Azure Websites is already available for a Web application. When publishing to the File System, we select the folder in which the distribution will be placed. It will create:
- Linux bash script: ConsoleApp1
- cmd script for Windows: ConsoleApp1.cmd
- approot folder, inside packages folder, and inside:
- ConsoleApp1 folder with application
- kre-clr-win-x86.1.0.0-beta3 folder with executable environment (DNX)
The ConsoleApp1.cmd script launches our application with the command:
@”%~dp0approot\packages\kre-clr-win-x86.1.0.0-beta3\bin\klr.exe” — appbase “%~dp0approot\src\ConsoleApp1” Microsoft.Framework.ApplicationHost ConsoleApp1 %* This is what happens. The program’s distribution contains .NET itself. More precisely contains DNX. In this case, the DNX used uses the CLR from the global .NET on the machine. But the application can be published using CoreXR's DNX. And then, the distribution will contain everything (since DNX for CoreCLR contains the CLR itself), which is required by the application.
More details about DNX and other
After all this, the statement that ASP.NET 5 does not depend on System.Web seems to be obvious at all. ASP.NET 5 does not depend on anything. ASP.NET 5 is a new runtime and a huge amount of NuGet packages containing everything that was in the BCL Framework (just rewritten). Many Microsoft.AspNet. * Packages can be conditionally combined into “ASP.NET 5”.
Source: https://habr.com/ru/post/255983/
All Articles