Using several dotnet CLI versions and why you should care

Frankly speaking “several” keyword in the title is an overuse, because while writing this article I’m thinking only about two versions of dotnet CLI. Why? Because RC4 version dropped support to project.json and switched completely to the new *.csproj format. On one hand it’s good – let’s follow the hype, cool to have tooling already. On the other hand if you still maintain/develop solution based on project.json then you have a problem (you will not be able to use dotnet CLI with that).

I am in such case and have found a solution that might be worth sharing.


Download dotnet CLI binaries (without installer) and extract package to some known folder. In my case it was:


Overriding PATH variable

The trick is to switch PATH variable to proper dotnet CLI location. Of course you could copy paste specific “set PATH=…” expression but some script may come in handy. Below is the script that works for me (I use an alias “set-dotnet.cmd”).  Remember to add script location to PATH (you may want to see this post).

@echo off
set _DOTNET2=c:\Tools\dotnet-prev2;
set _DOTNET4=c:\Tools\dotnet-rc4;
:: Batch way of string replace
set path=%path:C:\Tools\dotnet-prev2;=%
set path=%path:C:\Tools\dotnet-rc4;=%

if [%1]==[] goto usage
if "%1"=="prev2" goto prev2
if "%1"=="rc4" goto rc4
goto unknown

@echo you selected prev2
set path=%_DOTNET2%%PATH%
exit /B 0

@echo you selected rc4
set path=%_DOTNET4%%PATH%
exit /B 0

@echo Unknown parameter %1
goto :usage

@echo Usage: %0 ^<ver^>
@echo        where ^<ver^> is one of: prev2, rc4
exit /B 1

This lets me switch PATH to specific dotnet version using:

set-dotnet prev2
set-dotnet rc4

Normally I do scripting in Powershell but things related to environment variables are done easier in batch scripting – neither setx nor [Environment]::SetEvironmentVariable() affect currently active console (challenge me in comments if you want).

As batch scripting is pretty exotic some explanation is needed:

Exit /b 0

This means exiting current subrouting which is the whole batch script in case of “goto” or returning from “call” (0 is errorlevel)

:: Batch way of string replace

This is a way to do string replace withing variable. Let’s have another example

set x=hello world
set x=%x:world=chriss%

Executing these two lines above results in x=hello chriss


PS: Refactoring

Further refactoring can lead to having much simpler version which is having two batch scripts:


set path=c:\Tools\dotnet-prev2;%PATH%


set path=c:\Tools\dotnet-rc4;%PATH%

As an extra credit this will enable autocomplete for set-dotnet-*


Getting started with dotnet CLI

Dotnet CLI is a command line interface used for working with .NET projects. It’s not something new in .NET world. It was established in 2015. Back then there was another try with DNX in 2013 – not very successful.

Why to bother CLI?

You do not need CLI if you work with .NET code only from perspective of Visual Studio. CLI is really needed if you want to setup build pipeline, because build agent does not have to have Visual Studio installed. But let’s not forget about .NET migrating from Windows to the world. From now on you can run it everywhere (far far away there are systems without *.exe files) and build it with notepad, VIM or emacs. And that’s when dotnet CLI comes in.

It’s also valuable in Windows – from time to time you may want to automate your job by running specific tests just before “git commit” or run the application simply, without knowing full “../bin/Debug/net461” location.

Solution file

When working with dotnet CLI you can see that the solution file is no longer needed. Actually now it is fully based on solution folder containing necessary projects. If you want to build/run some project, you need to run “dotnet run <path/to/project/folder>”. It should build all dependencies as well. You can also run “dotnet restore” command in “solution” folder which should restore dependencies for all the projects inside. It’s very useful when creating new solutions. The only thing to do is preparing folder structure for the new solution and running “dotnet new” in each of them.


New dotnet CLI can be downloaded from here:

While installing, I prefer to download *.zip package and extract it to my known place without affecting the whole system. Doing so remember about adding “dotnet” location to PATH or adding alias.

Finally you should be able to run the following commands:

# list all available project templates
dotnet new

# create new xunit test project
dotnet new xunit

# restore projects dependencies (can be run in solution folder)
dotnet restore

# build specific project (run without parameter when in project's folder)
dotnet build .\src\project1

# run tests in project (run without parameter when in project's folder)
dotnet test .\test\project1.Tests

# add package to project
dotnet add .\src\syncfiles\Syncfiles.csproj package Newtonsoft.Json

# add project reference
dotnet add .\test\Syncfiles.Tests\Syncfiles.Tests.csproj reference .\src\syncfiles\Syncfiles.csproj

# create deployment package
dotnet publish .\src\syncfiles

Other commands

There is a list of commands we can use when working with .NET projects:

new Creates a new project, configuration file or solution based on the specified template
migrate Migrates existing project from project.json to *.csproj version
restore Restores dependencies of a project.
run Runs the project. Alternative to running produced *.exe file in Windows. Unified way of running .NET project for all supporter operating systems. It runs “dotnet build” when needed.
build Builds the project. It does not run “dotnet restore” automatically – you have to run it manually prior to building the project
test Runs test project with specific test runner (restored with other dependencies). You don’t have to select anything.
publish Packs the application and all of its dependencies into a folder getting it ready for publishing. Such folder can then be deployed to desired environment.
pack Packs the code into a NuGet package.
clean Cleans build outputs
sln Add/remove projects in solution
add Add project reference or package from nuget repository
remove Remove project reference or package
list List project dependencies
nuget Publish package to nuget server or delete it
msbuild Wrapper for msbuild.exe
vstest Wrapper for vstest.console.exe
help Shows help screen

DSP2017 again – introducing my project

DSP2017 has just begun. Last year I started and sank like Titanic – I was not blogging, left the project. In general, I was finding excuses like having no time because of children etc. That was weak.

If you’re new to the topic – DSP2017 is a competition when in three months (March – May) you have to run OpenSource project and blog about it at least twice a week (ok, once a week you can blog about anything).

I started again because I still want to improve. And I know that if I would not start in this competition, I would not get myself together and not blog/code after hours. Frankly speaking I do not play to stand on the podium but rather kick off my after-hours activity.

Getting back to the topic, here’s my project.
I want to create an application for synchronising media files on my computer with external HDD. It comes with a real need. At home my disks are full of images/movies from camera and phones and I do not know which of these were already moved to external storage (usually they are not moved at all). Files are duplicated, unsorted, unnamed. The mess is growing in opposite to free disk space. I need a tool that could help me (or even clean it up for me). I know that there are different tools on the web, but I tried some of them and I was not satisfied (still if you like any of these tools, please leave a comment). I plan to implement the following features:

  • Building file index within selected location
  • Getting file metadata (like creation date of picture/video)
  • Moving files from local drive to external storage (or from one folder to another)
  • Organising files by dates / other criteria
  • Detecting and cleaning file duplicates
  • Rolling back changes (just in case)

About technologies and interesting stuff:

  • I want to use dotNetCore (newest possible)
  • I want to use new dotnet cli
  • As a console freak I do want it to work in terminal (Text mode). At the same time it must be useful and comfortable so it’s possible that I will implement some console widgets
  • I am a huge fun o vim and I will use it as my default editor. But I must admit that I want to try VSCode as well. I don’t want to use full Visual Studio but it’s not a rule.

Wish me luck!