If you are a Front-end developer you may have worked with several command windows open. I always have a minimal of 3 or 4 command windows open. One for Git, one for npm start (building projects), one for npm test (testing projects) and most of the time also one for some other stuff I am doing. So, most of the time one of my desktops look something like this.

I like to have all the console windows visible to be able to see live updates when watching files. That why I like to use the Windows feature for stacking windows with WIN + Arrow Key.

On very annoying thing about several windows is that when you have some other windows (like a browser) temporarily on the desktop with the consoles is that when using Alt + Tab only focus one of the command windows. The other thing I don't like is the face of having multiple console windows in the taskbar.

Fortunately, there is a solution for that. It's called 'ConEmu' (https://conemu.github.io/). It's a windows console emulator which contains Tabs and Splitpanes! Yes... That what I need. Default it looks like below. 

With Ctrl+Shift+E or Ctrl+Shift+O you can split the command window in vertical or horizonal tabs. It is also possible to have tabs stacked with Windows+W.

The console will then look something like this:

Great!! So, know I can use Alt+Tab to switch to all consoles at once. If you also want one item in the taskbar (like I do) you can this in the settings window:

So Yes!! I finally have one window that contains all the consoles I need in my project.

But things get better and better!!!....

It is possible to start ConEmu with command parameters. So, it is possible to start the windows with all your windows in place and in the directory you want. To start with multiple windows, you can do the following:

start conemu64.exe 
        -title "GIT-SRC-TESTS" 
        -runlist -new_console:d:"C:\YourGitRepo\":t:GIT 
        ^|^|^| -cur_console:s1T70V:d:"C:\YourGitRepo\src\":t:SRC 
        ^|^|^| -cur_console:s2T50H:d:"C:\YourGitRepo\tests\":t:TESTS

The line break in the sample above should be removed. All should be on one line.

The command above sets the title for the ConEmu window. Then it uses the -runlist parameter to be able to run multiple commands. The first command is opening a new console (-new_console) in the directory C:\YourGitRepo and gives the tab the name 'GIT'. Then there are the ^|^|^| to split the commands and a second console is added with -cur_console, it is added to the first console s1T and made 70 percent of the height vertically (70V).

The output of the above command will result in a window like below:

More about the several command line arguments can be found on the ConEmu website.

But.... Again!! I can even be better...

ConEmu contains 'Tasks' which are predefined command groups:

These tasks can be requested from the command line (or batch file) by using the following command:

ConEmu64.exe -run {Bash::Git bash}

In the sample above the task '{Bash::Git bash}' is triggered, which opens a new command window started with bash on the current directory.
Best part of this is that you can also create your own tasks. Let's take the example from earlier to create a task that creates one ConEmu window with 3 splitted tabs on the correct directories. I created a new task called '{cmd::MyProject}' and in the command window I added the following code (beware, line-breaks are important here).

-cur_console:d:"C:\YourGitRepo" -cur_console:t:GIT2 cmd

-cur_console:s1T70V -cur_console:d:"C:\YourGitRepo\src" -cur_console:t:SRC cmd

> -cur_console:s2T50H -cur_console:d:"C:\YourGitRepo\tests" -cur_console:t:TEST cmd

You may wondering what the '>' sign means, but this will be the active tab. In the settings window it looks like this:

Tip: If you have set up the tabs by hand you can press the 'Active tabs' button in the right bottom corner. This will create the correct text for you.

So now it is possible to start the same tabs with just:

ConEmu64.exe -run {cmd::MyProject}

I really like this ConEmu and there are a lot of configurations you can change to customize it to your wishes. Personally I like my tabs below and some other colors. There is also another command emulator Cmder (http://cmder.net/) which is based on ConEmu. I like the colors used with Cmder, but I could not clearly find how to start cmder with tasks. In the directory of Cmder you can find the folder that contains ConEmu. I use that ConEmu64.exe to have the default colors of Cmder. But of course It's totally up to you to decide what you like!

Happy Coding!

Have you ever created a C# windows service? I found it really ease to create. But what if something is going wrong? I could never really find a good way of debugging windows services. So most of the time I was writing verbose logs to be able to find the problem. On other way was not running as windows service, but as a simple console application. But somehow there are situations where the console app does work and the windows service doen't. 

Now I found an easy way of debugging windows services. So in this post I will try to explain how to create a simple windows service and be able to debug it.

First  start Visual Studio as Administrator (administrator rights are needed for debugging the windows service).

Secondly create a windows service project. This will create a Program that looks like the code below:

    static class Program
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        static void Main()
        {
            ServiceBase[] ServicesToRun;
            ServicesToRun = new ServiceBase[]
            {
                new YourWindowsService()
            };
            ServiceBase.Run(ServicesToRun);
        }
    }

 In 'YourWindowsService.cs' (where YourWindowsService must be replaced with the name you have choosen) add the selected lines to the OnStart() method.

    protected override void OnStart(string[] args)
    {
        if (args != null && args.Contains("-d"))
        {
            Debugger.Launch();
        }

        // Do Your Things
    }

The code added above checks if one of the arguments is '-d' and ifso it will ask the Debugger to launch. More about this will be explained later in this post.

Build you solution and start a console window to register the service you just created.

Commands for registering windows services are:

sc create YourWindowsServiceName binPath="full-path-to-service.exe"

# start without debugger
sc start YourWindowsServiceName

Your windows service should run now without debugging.

So how start the debugger? Follow the next steps: 

1. Open the 'Services' of windows
2. Right click 'YourWindowsService'
3. Open the properties
4. Stop the service (if running)
5. Type '-d' in the Start parameters edit box
6. Press start.

Now the Visual Studio Just-In-Time Debuger will ask to debug:
'Yes, debug YourWindowsService.exe'

Hit yes to allow the Just-In-Time Debuger to start.

The Just-In-Time debugger shows a window to choose the Visual Studio instance to select, if you started visual studio in the first steps as Administrator it will be listed here also. Otherwise choose the version you want (if multiple versions installed) and start debugging.

Visual Studio will open and break at the Debugger.Launch() line.

You have successfully attached a debugger in your windows service.

Never thought it would be so simple as this.

As you may noticed in my previous posts I use Git in a lot of projects I am working on.

Previous posts:

Git commands I keep forgetting

Update local develop branch without checkout

Git commands I keep forgetting part 2

In the last one I already talked about "Remove local branches when remote branch is already removed". I used this way of removing a lot the last couple of months. But even with these simple command it is still a lot of work to get your local copy clean.

During some searching on the internet I found another great way to make it even simpeler to cleanup the local repository.

List branches that have no remote branch anymore.

git branch -vv

The above command can be used to list branches in a verbose way. And the output will be something like this:

bugfix/BF_Bug1           6a64538 [origin/bugfix/BF_Bug1: gone] Fixed bug1
bugfix/BF_Bug2           b7cf3ea [origin/bugfix/BF_Bug2] Fixed bug2
* develop                ca60d674 [origin/develop] Merged PR 91: Added Feature
feature/SomeGreatFeature ccb8b3f [origin/feature/SomeGreatFeature: gone] Some great feature added
master                   10ed942 [origin/master] Updated README.md

As you can see 2 branches are 'gone', which means the remote branch does not exist anymore. Now you know which branches you can remove from the local repository with the commands:

git branch -d bugfix/BF_Bug1

git branch -d feature/SomeGreatFeature

The above commands are not so hard to learn, but if you have a lot of branches that you want to remove it can be time consuming to remove every branch manualy. To make your life a little bit easier you have to do the following steps:

1. Find you .gitconfig file which contains the configuration of GIT.
   On my machine the .gitconfig file could be found at: %USERPROFILE%\.gitconfig
2. It is possible to add alias command in this configuration file and that's excactly what we are going to do. Add the following lines to the .gitconfig file:
   

   [alias]
   prune-branches = !git remote prune origin && git branch -vv | grep ': gone]' | awk '{print $1}' | xargs -r git branch -d

3. You can now remove all local branches from which the remote branch is removed. Open a command prompt in you source directory and type the following command:
   

   git prune-branches

4. The output will be something like:
   

   Deleted branch bugfix/BF_Bug1 (was 6a64538).
   
   Deleted branch feature/SomeGreatFeature (was ccb8b3f).

I really like this command, because now I can execute one command that will clean my local repository. Of course you can name the alias whatever you like. Personally I updated my alias to be ' git pb'  which is faster to type than 'git prune-branches'.

I hope I have made you life a little easier by writing this blog!

Happy Coding!

One year ago I wrote a blog about the Git commands I keep forgetting and Update local develop branch without checkout. These blogs contains some of the commands that I frequently use during developing. After writing this first blog post about git commands I learned other git commands as well that I find interesting to share with you.

Remove local branches when remote branch is already removed

In the projects I currently work on we use Git Flow a lot. This means that we use a lot of branching and when a remote branch is removed (ex: git flow feature finish) by someone else my own local git repo must be updated. You can delete the remote branches from the cache using the fetch prune command:

git fetch -p

But if you have pulled the branch ones then you also have a local branch. When you use this command the local branch is not deleted. For deleting local branches use the following command:

git branch -d some_feature_branch

If the local branch has some changes that where not merged to the master or develop branch git will show a warning. To force the branch deletion use:

git branch -D some_feature_branch

*note: the uppercase -D instead of -d

Remove remote branch

Sometimes it happens that the remote branch is not correctly removed from the remote repository during 'git flow feature finish'. I you want to delete the remote branch using the command line use the following command:

!!!!CAUTION NO UNDO, USE AT OWN RISK!!!

git push origin --delete some_feature_branch

Temporarily store changes without commit

If you have made changes but suddenly you see you are working on the wrong branch. Oops... What to do now? Stash comes to rescue you.
With stash you can set changes in a temporary storage of git and pull the changes when needed. So when you have changes on some branch and want to move them to another branch you can use the following commands:

# Stash the uncommited changes
git stash

# Swith to other branch
git checkout some_other_branch

# Get the changes from the stash
git stash pop

There is a lot you can do with stashing so for the full documentation go to https://git-scm.com/docs/git-stash

Happy Coding!

I am currently working on different project using Angular 2 with webpack. For these projects we use remap-instanbul to generate coverage reports.

The last week I was upgrading the solution from Angular 2.0 to Angular 2.4 and everything seems to be working as expected except the coverage. During unit testing this error occurred:

Error: Could not find source map for: "C:\Sources\NG2\src\app\app.component.ts"
    at CoverageTransformer.addFileCoverage (C:\Sources\NG2\node_modules\remap-istanbul\lib\CoverageTransformer.js:148:17)
    at C:\Sources\NG2\node_modules\remap-istanbul\lib\CoverageTransformer.js:268:14
    at Array.forEach (native)
    at CoverageTransformer.addCoverage (C:\Sources\NG2\node_modules\remap-istanbul\lib\CoverageTransformer.js:266:24)
....
....
....

Some files however seem to be working and some others not.... Really strange....

But after reading some discussions on the internet I found one solution that was to downgrade the "istanbul-instrumenter-loader" to version 0.2.0. And voilà it worked... So If you like to stop with the first fix you find on the internet.. STOP READING NOW.... Otherwise continue for the even simpler solution.

Ok, so I am not the kind of person to stop with the first fix I find and since you are reading this you are also willing to find the best solution instead of the first solution.. So here is the 'real' solution:

In the webpack configuration for the unit tests check if you have a configuration for typescript like:

ts: {
        compilerOptions: {
            sourceMap: false,
            sourceRoot: './src',
            inlineSourceMap: true
        }
    }

If you have some configuration like this, remove both line about sourcemaps. The configuration will look like this:

ts: {
        compilerOptions: {
            sourceRoot: './src'
        }
    }

Now you can use the newest version of the "istanbul-instrumenter-loader" and it works like a charm.

So have fun with your unit tests and keep up with the coverage ;-).

Today I was trying to start a TFS build with a specified commit id using the "QUEUE NEW BUILD" windows of TFS vNext.

But when trying to do so TFS reports the following problem: "The value specified for SourceVersion is not va valid commit id"

After a lot of searching on the internet I found the problem dat TFS vNEXT uses the SHA1 version of the commit id. To get the SHA1 commit id you can execute the following command:

git rev-parse HEAD

This command returns the latest commit id on HEAD and returns this in the SHA1 format:

c7ab3fd13e30b55394afc3ebb5c73240c662b160

Using this SHA1 version of commit id in the TFS windows will start the Build for the specified commit. If you want to start a build for an older commit perform the following steps:

1. Find the Commit id from TFS (ex: a9d8f7e7)
2. Open the Command prompt and type 

   git rev-pars a9d8f7e7

3. Output of the command should be something like: a9d8f7e76d24d5b4f1cc15378eb9513a6e2cdb4d
4. Copy the SHA1 commit id
5. Queue new build in TFS
6. Past the output of the git command in the "Commit" textbox

Hopefully Microsoft will add some support for the smaller commit id's in the future, but for now this can be the workaround.

Update (Thanks to Travis and Artour)

There is a way to get the CommitID using Visual Studio. If you open the History from a branch and open de Commit Details of a commit you can press the 'Actions' link and choose 'Copy Commit ID'

If you are using SourceTree you see the full CommitId.

Happy coding ;-)

Early this year I wrote a post about Git Command that I think are handy to know: Git commands I keep forgetting

After working with Git more and more I have gathered some other command as well that I would like to share with you:

Update the local develop branch while working on a feature branch

We use git flow from nvie a lot. Which is very nice because it handles a lot of stuff for you. But one thing that I did not like was when I wanted to finish the feature using: 

$ git flow feature finish FEATURE-NAME

I first had to update the develop branch because otherwise it will merge with an old version of develop. Steps that I had to follow where:

# switch to develop
$ git checkout develop

# update develop
$ git pull

# switch to feature branch
$ git checkout feature/FEATURE-NAME

# merge from develop to feature branch
$ git merge develop

# finish feature
$ git flow feature finish FEATURE-NAME

# push changes
$ git push

It is also possible to merge from origin/develop to your feature branch, but still if you want to finish the feature branch you have to make sure that the local develop branch is up to date.

With the following command you can eliminate the first 3 commands:

# update develop branch without checkout
$ git fetch origin develop:develop

So if the feature branch is not up to date with develop the flow becomes the following:

# update develop
$ git fetch origin develop:develop

# merge from develop to feature branch
$ git merge develop

# finish feature
$ git flow feature finish FEATURE-NAME

# push changes
$ git push