Command line

CMDer/ConEmu – starting new tab in current folder

Recently I posted about a trick allowing the user to open new CMDer/ConEmu tab in current folder from command line. In response ConEmu team twitted a better solution that I would like to share:


I don’t want to have specific shortcut for each task so I just edited default {cmd} task this way:


The key here is to add “/dir “%CD%” as task parameter and remove “:d:”%USERPROFILE%” parameter from the textbox on the bottom. Just after that when you add new tab (in my case Ctrl + Shift + T) you can specify “Startup directory for new process” or leave it empty. In the latter case (and only then!) ConEmu will open new task in current directory.


Why is this better?

The previous solution required active console in order to execute some command. Now everything is done by ConEmu, so you can have some process running (web server/test watch/vim etc) and at the same time start new tab in the same folder.

Thanks a lot ConEmu Team!

Command line

CMDer/ConEmu – starting new tab in current folder from command line

Quite frequently I found myself opening several console tabs in the same folder (for vim, for running unit tests, for git, for executing the application etc). Starting new tab and navigating to my project’s directory is not optimal so I created a short !cmd.bat snippet that I can run everywhere (added as global alias) and it will create a new tab for me in the same directory. Here’s the content:

cmd /k "%ConEmuDir%\..\init.bat" -new_console:C:"%CMDER_ROOT%\cmder.exe"

It’s taken from “ConEmu -> Settings -> Tasks” with slight modification (adding tab icon). Here’s explanation of switches used by the snippet:2017-03-26_23-52-18

/k - run initial script just after running console
-new_console - open process in a new tab
:C:"file location" - path to file containing tab icon

Alternative way is to use shortcut for creating new tab and then selecting current folder from drop-down menu (see below).


Unfortunately because of some bug it does not work in my current version of Cmder/ConEmu (build 161022). The other this is that it requires more clicking 🙂

Own projects

Review/Planning no. 0


The following features have been developed so far:

  • The app reads the structure of given folder
  • It saves the structure to a file
  • It calculates hash of every file
  • Other: Environment configuration (VIM + dotnet core SDK 1.0.1)

Some of the features delivered here does not bring real value i.e. calculating file hash or saving data to a file. This highlights the lack of planning last time. Up till now the app is not useful and does not solve any real problem.


The goal of the next iteration is to create functionality to move media files from source folder to target, applying some simple file reorganisation.
Files are organised by file’s creation year and month. Files structure from source location should be preserved. In order to avoid conflicts/errors the target directory must be empty.
The operation must generate some kind of a journal so that the operation can be rolled back or resumed if needed.


  • Generate dry-run file in order to review the moving/organisation process.
    File moving cannot be done on-the-fly. This operation can take a while and it may mess up files structure, so it’s better first to review the file showing suggested list of “source location -> target location” entries.
  • Generate journal file based on source file structure.
    The application should always leave track of every change as it is about moving sensitive data (personal media files). In case of any issues it should be possible to resume the operation or roll it back.
  • Move files to proper folders updating journal.
    Moving physical files from one place to another, based on generated dry-run file.

Currently I do not set the date of next Review/Planning. I expect to have it at latest in 3 weeks but I want to check my velocity first.

Own projects

DSP2017 – What’s your methodology?

Almost three weeks have passed since the start of DSP2017. I cannot say that I feel excited about what I did. Nothing really changed since the last year (which was unsuccessful). Maybe it’s time for a quick recap? Maybe the way I drive my project after-hours is less serious than then one I do at work? Why? Wiseman said: Pay yourself first.

Maybe the thing is that I miss some kind of a process, rules to proceed, methodology? Why not to take the best of what I do and practice at work?


Talking about me, from now on I want to introduce some scrum ceremonies into my project. I do want to have iterations. And what’s related I want to have a review session followed by planning for the next iteration. I want to make it public, so expect Review/Planning post every iteration (I guess it will be done bi-weekly but this may change).


I feel I need review session to motivate myself. And nothings is a better motivation than making the progress public. Praise if it’s good, sling mud at me if it’s bad. Let it be colorful with clear decision that I want to go on or not.


Planing is also crucial for such project. It makes me know what to do next, so I can focus on coding instead of looking for the next thing to do. The worst excuse for not planning is not having time for it. I was about wasting a lot of time for doing stuff which turned out to be low-priority. Not only once.

Expect the first post soon.

Command line, Programming (back-end)

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 ^
@echo        where ^ 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-*

Command line, Programming (back-end)

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 “. 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
Own projects

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!