1,2,3, contact!
I’m not sure if there’s anyone still reading this, but I’ve decided to restart writing here again. I’ll be using this blog to document my experiences with the new ASP.NET 5.0 (for which there’s already a VS 2015 preview version). I’ve decided to do this since I won’t be updating my PT books on these subjects.
If you haven’t been living under a rock, you’ve probably heard about the latest release of ASP.NET, aka ASP.NET vNext. vNext is supposed to use a new stack, where you’ll find several of the traditional .NET features split into several packages that you’ll only load when you really need them (pay-for-play model). You’ll also find a new unified web stack, with simple packaging and versioning rules which should ease the problems associated with side by side run of different versions.
The new platform uses a new runtime/SDK, known as KRuntime. In order to get a specific version of the runtime (yes, there are several versions, based on architecture – 32 vs 64 bits – and features – CLR vs CoreCLR), we’ll need to resort to the K Version Manager tool (aka kvm). The docs already have all the details on how to install the kvm tool, so I’ll concentrate on looking at what we can do with it. Before going on, it’s worth it pointing out that kvm is simply a Powershell script, so nothing prevents you from opening it in your favourite text editor and seeing what it does.
One of the first things we’ll need to do is update the runtime to the latest version by using the upgrade option:
kvm upgrade
Running this command will end up upgrading the x86 CLR K runtime and setting it as the default runtime that is being used by your profile. You can always update the amd64 version (64 bits) by writing the following:
kvm upgrade –amd64
Notice that this will also promote the 64 bits as the default active runtime for your profile. And sure enough, you can also update the Core CLR by using the –r option. For instance, here’s how to upgrade the 64 bits Core CRL K runtime and set it as the default:
kvm upgrade –amd64 –r CoreCLR
Since you can have lots of runtime versions installed in a machine, it would be really great to have a way to list all of them. And that’s why there’s a list option:
kvm list
Running the previous command on my machine results in the following:
Active Version Runtime Architecture Location Alias
—— ——- ——- ———— ——– —–
1.0.0-beta1 CLR amd64 C:\Users\Luis\.kre\packages
1.0.0-beta1 CLR x86 C:\Users\Luis\.kre\packages
* 1.0.0-beta1 CoreCLR amd64 C:\Users\Luis\.kre\packages default
1.0.0-beta1 CoreCLR x86 C:\Users\Luis\.kre\packages
As you can see, we’ve ended up getting the Core CLR 64 bit version set up as the default active runtime. Notice also that the active runtime is aliased to the default name. kvm supports aliases operations by using the alias parameter. When used without any more info, it will simply report all the current aliased versions:
PS C:\code\git\home> kvm alias
Alias Name
—– —-
default KRE-CoreCLR-amd64.1.0.0-beta1
You can also pass a name to the alias and that will return its associated runtime version. For instance, if I pass it the default name, here’s what I’ll get on my machine:
PS C:\code\git\home> kvm alias default
Alias ‘default’ is set to KRE-CoreCLR-amd64.1.0.0-beta1
Now, as we’ve seen, we have 4 versions installed by default and nothing prevents you from creating alias for them. For instance, here’s how we can create a new alias for the 64 bits Core CLR runtime version:
PS C:\code\git\home> kvm alias CoreCLR64 1.0.0-beta1 -amd64 -r CoreCLR
Setting alias ‘CoreCLR64’ to ‘KRE-CoreCLR-amd64.1.0.0-beta1’
And just to be sure that we did end up getting what we wanted:
PS C:\code\git\home> kvm alias
Alias Name
—– —-
CoreCLR64 KRE-CoreCLR-amd64.1.0.0-beta1
default KRE-CoreCLR-amd64.1.0.0-beta1
PS C:\code\git\home> kvm alias CoreCLR64
Alias ‘CoreCLR64’ is set to KRE-CoreCLR-amd64.1.0.0-beta1
Now, aliases are quite useful because we can use them with the other options that can be passed to kvm. For instance, let’s say that we want to use the Core CLR 64 bits version as the default runtime. Since we’ve created the CoreCLR64 alias, them we can simply pass that name to the kvm use command:
PS C:\code\git\home> kvm use CoreCLR64
Adding C:\Users\Luis\.kre\packages\KRE-CoreCLR-amd64.1.0.0-beta1\bin to process PATH
PS C:\code\git\home> kvm list
Active Version Runtime Architecture Location Alias
—— ——- ——- ———— ——– —–
1.0.0-beta1 CLR amd64 C:\Users\Luis\.kre\packages
1.0.0-beta1 CLR x86 C:\Users\Luis\.kre\packages
* 1.0.0-beta1 CoreCLR amd64 C:\Users\Luis\.kre\packages CoreCLR64, default
1.0.0-beta1 CoreCLR x86 C:\Users\Luis\.kre\packages
If we didn’t had the alias, we’d have to specify the version, CPU and flavour of the CLR we want to use (sure, there are defaults, but my brain is already lagging for my daily tasks, so I won’t really be memorizing any of them):
PS C:\code\git\home> kvm use 1.0.0-beta1 -amd64 -r CoreCLR
Adding C:\Users\Luis\.kre\packages\KRE-CoreCLR-amd64.1.0.0-beta1\bin to process PATH
PS C:\code\git\home> kvm list
Active Version Runtime Architecture Location Alias
—— ——- ——- ———— ——– —–
1.0.0-beta1 CLR amd64 C:\Users\Luis\.kre\packages
1.0.0-beta1 CLR x86 C:\Users\Luis\.kre\packages
* 1.0.0-beta1 CoreCLR amd64 C:\Users\Luis\.kre\packages CoreCLR64, default
1.0.0-beta1 CoreCLR x86 C:\Users\Luis\.kre\packages
As you can see, the result is precisely the same and that’s why I prefer to create an alias in order to reduce the required typing (yes, I’m lazy!).
Whenever you want to remove an alias, you should use the unalias option:
PS C:\code\git\home> kvm unalias CoreCLR64
Removing alias CoreCLR64
PS C:\code\git\home> kvm list
Active Version Runtime Architecture Location Alias
—— ——- ——- ———— ——– —–
1.0.0-beta1 CLR amd64 C:\Users\Luis\.kre\packages
1.0.0-beta1 CLR x86 C:\Users\Luis\.kre\packages
* 1.0.0-beta1 CoreCLR amd64 C:\Users\Luis\.kre\packages default
1.0.0-beta1 CoreCLR x86 C:\Users\Luis\.kre\packages
There’s one final option which you can use with the kvm command: install.You can use this option to install a specific runtime. It works in a similar way to the upgrade/use options, so I won’t be giving any examples of its usage here.
Before ending, I’d just like to mention the existence of the –g and –f flags, which can be used with the upgrade, install and use options. The –g flag can be used to persist changes globally across the machine (instead of just saving them on the current user profile).As for the –f flag, you can use it to force the execution of the current request. For instance, if you want to force the download of a previously downloaded runtime, you can use the following command: kvm update –f.
And that’s it for now. Stay tuned for more on the ASP.NET vNext.
Posted in .NET, ASP.NET, C#, CLR