The new ASP.NET 5 execution model is a bit of a complex beast. By making use of the .NET version manager (dnvm), we can actually change the currently active .NET framework that our application will use. This is quite handy for running multiple .NET framework versions side-by-side on the same machine.
The workflow for changing the .NET execution environment is as follows:
1. dnvm list
First we can check which execution environments are installed and which one is currently active.
> dnvm list
Active Version Runtime Architecture OperatingSystem Alias
------ ------- ------- ------------ --------------- -----
1.0.0-beta5 clr x64 win
1.0.0-beta5 clr x86 win
1.0.0-beta5 coreclr x64 win
1.0.0-beta5 coreclr x86 win
1.0.0-beta7 clr x64 win
1.0.0-beta7 clr x86 win
1.0.0-beta7 coreclr x64 win
1.0.0-beta7 coreclr x86 win
1.0.0-beta8 clr x64 win
1.0.0-beta8 clr x86 win
1.0.0-beta8 coreclr x64 win
1.0.0-beta8 coreclr x86 win
1.0.0-rc1-16231 clr x86 win
1.0.0-rc1-16231 coreclr x86 win
1.0.0-rc1-final clr x64 win
1.0.0-rc1-final clr x86 win
* 1.0.0-rc1-final coreclr x64 win
1.0.0-rc1-final coreclr x86 win
1.0.0-rc2-16090 clr x86 win
1.0.0-rc2-16090 coreclr x86 win
1.0.0-rc2-16300 clr x64 win
1.0.0-rc2-16300 clr x86 win default
1.0.0-rc2-16300 coreclr x64 win
1.0.0-rc2-16300 coreclr x86 win
2. dnvm use
Next, we can switch the active framework by issuing a use command:
> dnvm use 1.0.0-rc1-final -r clr -a x64
Adding C:\Users\armen\.dnx\runtimes\dnx-clr-win-x64.1.0.0-rc1-final\bin to process PATH
> dnvm list
Active Version Runtime Architecture OperatingSystem Alias
------ ------- ------- ------------ --------------- -----
1.0.0-beta5 clr x64 win
1.0.0-beta5 clr x86 win
1.0.0-beta5 coreclr x64 win
1.0.0-beta5 coreclr x86 win
1.0.0-beta7 clr x64 win
1.0.0-beta7 clr x86 win
1.0.0-beta7 coreclr x64 win
1.0.0-beta7 coreclr x86 win
1.0.0-beta8 clr x64 win
1.0.0-beta8 clr x86 win
1.0.0-beta8 coreclr x64 win
1.0.0-beta8 coreclr x86 win
1.0.0-rc1-16231 clr x86 win
1.0.0-rc1-16231 coreclr x86 win
* 1.0.0-rc1-final clr x64 win
1.0.0-rc1-final clr x86 win
1.0.0-rc1-final coreclr x64 win
1.0.0-rc1-final coreclr x86 win
1.0.0-rc2-16090 clr x86 win
1.0.0-rc2-16090 coreclr x86 win
1.0.0-rc2-16300 clr x64 win
1.0.0-rc2-16300 clr x86 win default
1.0.0-rc2-16300 coreclr x64 win
1.0.0-rc2-16300 coreclr x86 winHere’s the dnvm use command usage:
dnvm use Adds a runtime to the PATH environment variable for your current shell usage: dnvm use <VersionOrAlias> [-a <Architecture>] [-r <Runtime>] [-OS <OS>] [-p] options: <VersionOrAlias> The version or alias of the runtime to place on the PATH -a The processor architecture of the runtime to place on the PATH (default: x86, or whatever the alias specifies in the case of use-ing an alias) -r The runtime flavor of the runtime to place on the PATH (default: clr, or whatever the alias specifies in the case of use-ing an alias) -OS The operating system that the runtime targets (default: win) -p Make the change persistent across all processes run by the current user
The description reveals the magic trick: dnvm adjusts the current PATH variable so that it points at different runtime dependencies depending on the version, architecture (-a), and runtime flavor (-r) of the .NET execution environment you choose.
3. dnx web
Once I’ve changed my current execution environment, I can navigate to the root of my project and run it using the currently active .NET execution environment.
> dnx web Hosting environment: Production Now listening on: http://localhost:5000 Application started. Press Ctrl+C to shut down.
Which Dependencies is it Using?
Sometimes it is helpful to be able to figure out which specific versions of packages your application is using, and where on your hard drive they are coming from.
This is especially true when pulling down some of the open sourced .NET and ASP.NET packages into a local solution in order to assist in debugging. It isn’t always clear whether your local version or a system-installed version is being used.
project.lock.json
Depending on the currently active .NET execution environment, your application will end up using dependencies (.dll assemblies) from different locations on your system. In fact, after restoring packages via dnu restore, a project.lock.json file will be generated which points to the various implementations of all your dependencies for all targeted frameworks.
One option is to take a look through the project.lock.json file to see where the individual dependencies live. The problem here is for even the most basic of projects, this file will be quite unwieldy. For example, the default ASP.NET 5 web application project produces a project.lock.json file over 21,000 lines long on my system!
app.UseRuntimeInfoPage()
I recently discovered an extremely useful tool for assisting in determining what version of packages my application is using and where on my system they’re located: UseRuntimeInfoPage. The best part is it can be enabled as part of your ASP.NET 5 project for free: just add one line to the Startup.Configure method.
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
loggerFactory.AddConsole(Configuration.GetSection("Logging"));
loggerFactory.AddDebug();
if (env.IsDevelopment())
{
app.UseBrowserLink();
app.UseDeveloperExceptionPage();
app.UseDatabaseErrorPage();
app.UseRuntimeInfoPage();
}
// ...As you can see, I’ve only enabled this when I’m running in development (i.e., my desktop or test server) since I don’t want potentially sensitive information to be shared with the world.
After calling the UseRuntimeInfoPage, you’ll be able to navigate to /runtimeinfo when running your web application. (Note: You can override this path by using one of the overloads to UserRuntimeInfoPage).
Lets take a look at that page when I’m using the clr (full .NET framework) runtime:
Now lets take a look when I run using the coreclr (.NET Core) runtime:
As you can see, each runtime pulls in some packages that are the same, but also a bunch that are different – the most obvious being the fact that much of the System.* dependencies are installed to a specific folder below Program Files (x86) under clr whereas coreclr makes use of packages entirely within my .dnx package cache.
Done
One of the coolest features of ASP.NET 5 is the ability to target multiple .NET execution environments. In my limited experience so far, the behavior has been mostly seamless (I did have a few issues pulling down a few aspnet packages directly into my solution).
There are bound to be slight issues and differences in the way a single application behaves when running in different execution environments, which is why I suspect the ASP.NET team has included this super useful diagnostic utility.
If you’re ever trying to figure out what versions of assemblies your application is using and where they’re located on your system, hopefully this tool will be of help to you.
