Things, they are a-changing!
I found that I’ve been mostly able to survive the transition with a few questions around runtimes and where things have moved, but not all the bits are obvious. Here’s a list of some things that you’ll likely want to know as you navigate the M-V-Seas. (See what I did there? )
There used to be two separate commands for language services and running/booting up a site or application. These commands (k and klr) have both been merged with the runtime environment and are all now part of dnx, a.k.a. the .Net Execution environment.
The version manager, which was previously the kvm script (ps1 or sh, depending on environment), is now a command line utility called dnvm, or .Net Version Manager.
Finally, a new utility has been added that replaces the previous dependencies manager with a few enhancements (such as command hoisting from your project.json). The new name is dnu (the .Net Development Utility) and you use it to restore or manage packages, create NuGet packages or publish your project.
So, in summary:
k, klr, kre => dnx
kvm => dnvm
kpm => dnu
We used to use the package manager console in Visual Studio to do our migrations work, however, this is not currently the case in VS2015. I imagine that this will continue to improve, but there is still a delta in the way that we used to do things. Today, we’re going to do things a little differently: in a properly prepared console, you’ll type the following in your project directory (not your solution directory):
dnx . ef [options] [command]
This command tells the .Net execution environment to use the current directory and to run the ef command. From there you could type migration or whatever else you’re looking for. Leaving the options and command out, for instance, gives you the magic unicorn of awesome.
First of all, you’ll need to make sure that you have the tooling for the dn* utilities on your PATH. There needs to be environment variables setup to point you to the correct runtimes, or rather, the runtimes you’re currently targeting. You can see all the runtime versions you have installed by typing:
Typically, you’ll see two different runtimes (clr and coreclr) for each architecture (x64, x86), and you’ll see each of those for each version you have installed.
The “correct” version for your purposes may be a moving target, so make sure you have a runtime and version that works with the version of EF you have. If you’re not sure (or you thought you were sure but things aren’t working) take to Jabbr and ask for a hand (they are great there).
Next, your solution and/or project will have to have the correct references to EF. Edit your project.json to have the following dependencies and commands (you can do this in VS or Notepad or whatever tool you like, just save the file when you’re done):
Almost there. Now we need to restore those packages locally so that you can use the EF tooling. To do that, we’re going to use the following command from the solution directory:
Voila! You should be good to go! Navigate to your project directory and hack away at your migrations.
So, go grab Visual Studio 2015! If you run into trouble there is a wealth of information out there (albeit, much of it is quickly becoming outdated or conflicting). As I already mentioned, Jabbr is a great place to ask questions, as are Twitter and Stack Overflow. Brice Lambson periodically posts updates on his blog. I have found that the documentation for Asp.Net 5 has also been kept fairly up-to-date, which you can read here.