On the last TechEd Microsoft unveiled the preview of the VNext version of ASP.NET. Even if it’s on alpha, all the source is already available on GitHub (https://github.com/aspnet).
For more info see Jon Galloway’s post (http://weblogs.asp.net/jongalloway/a-30-minute-look-at-asp-net-vnext).
One of the Microsoft current development efforts is to create a great command line experience. Visual Studio remain the best tool for developing ASP.NET applications, but there are few scenarios where to be able to develop, modify and run an application right from the command line is a real bonus. On the other side, this enable us to start playing with ASP.NET vNext right now, even if many things are not ready on the Visual Studio 14 CTP side. To give you an example, at this time the only way to add a reference to a project is by manually editing the project.json file because the NuGet Packages Manager is still unavailable on VS 14 CTP.
Since many of us has never or rarely needed to write batch files, I’ve thought it would be nice to write a post about some exoteric command syntax of Windows Batch Scripting buried on my memories, to help read and understand the meaning of some of the command files we use while developing a ASP.NET vNext application. One for all, the
KVM (K-Runtime Version Manager) command.
First thing first, to whom it may ask himself why the letter K is almost everywhere, please note that initially ASP.NET vNext was called Project-K. That’s why we have:
- The new runtime, called K-Runtime o KRE. It is self-contained and you can have multiple different versions running side by side on the same machine.
- The Version Manager, called KVM. It’s used to manage KREs. It’s a PowerShell script called from the (you guess what) KVM.cmd.
- The Package Manager, called KPM. It’s used to manage NuGet Packages. Internally it calls the Loader with specific predefined parameters, from the KPM.cmd.
The Loader, called KLD. It’s used to complete many tasks, like:
- Install NuGet Packages (from the KPM.cmd)
- Restore NuGet Packages (from the K.cmd)
- Run the application (from the K.cmd)
For a wider and deeper comprehension of these aspects, please see the Wiki article written by David Fowler: https://github.com/aspnet/Home/wiki/KRuntime-structure.
That being said, we can start analyzing the KVM (K-Runtime Version Manager) command.
This is the command that execute the PowerShell script of the K-Runtime Version Manager. You may wonder why we need a batch file to launch a PowerShell script, and the answer is easy as a piece of cake:
- First of all, PowerShell cannot execute a script if the execution policy doesn’t allow it (and by default it is not) and a batch can do it for us.
- Last but not least, the PowerShell script may (for the sake of KRE version management) create a run-once batch file that need to be executed after the script completion, and this is also a task easily accomplished by a batch command.
Let’s see the code:
Line 3 is where the PowerShell execution is launched, with those parameters:
- -NoProfile to prevent loading the Windows PowerShell profile.
- -NoLogo to hide the copyright banner at startup.
- -ExecutionPolicy unrestricted to allow script execution and other tasks, otherwise not available.
-Command that contain three commands, semicolon separated:
- [System.Threading.Thread]CurrentThread.CurrentCulture = ‘ ‘
- [System.Threading.Thread]CurrentThread.CurrentUICulture = ‘ ‘
The first two PowerShell commands are self-explanatory.
The third command, that made me mumbling and required a fair amount of time to be resolved, by looking at the “ancient books of Windows Batch and PowerShell Scripting”, is made of two parts:
- & ‘%~dp0kvm.ps1′
The first element is obviously the name of the script that PowerShell is required to execute, given the ‘ps1’ extension. It’s worth noting that, to PowerShell be able to execute a script, some condition have to be met:
- The Execution Policy does allow script execution (and this condition is meet with the ExecutionPolicy parameter set to unrestricted).
- The script must be declared with the full path (drive:\DirPath\Filename. Extension).
- If the path contains spaces, it must be enclosed inside quotes and preceded by the Call Operator (&) that instruct PowerShell to interpret the enclosed string as the path of the script to be executed.
Looking at the first part, we do have the Call Operator and the single quotes that frames the full path. The last piece of the puzzle is made by the Percent tilde Operator (%~).
On a Windows command file the %0 represent the full path of the command file being executed, and the Percent Tilde Operator can help us extract parts of it. You can learn all about it on the Windows Batch Scripting wikibook (http://en.wikibooks.org/wiki/Windows_Batch_Scripting) but here all we need to know is that %~dp0 extract the drive and directory path of the command file being executed.
The second element is straightforward, because %* is a shorthand of %1 %2 %3 … %9 so it routes the command parameters to the PowerShell script.
As an example, if we have installed the KVM.cmd command and the kvm.ps1 PowerShell script on “C:\Users\Nick\.kre\bin” and from the command line we execute:
then &’%~dp0kvm.ps1′ %* will be resolved as:
& ‘C:\Users\Nick\.kre\bin\kvm.ps1’ list
And that’s all folks, happy coding!