Getting started with kpm

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.

Advertisements

~ by Luis Abreu on November 20, 2014.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: