Adding GitHub upstream remote in Visual Studio

Forking and opening a GitHub repo in Visual Studio is a matter of seconds. But how to keep your fork up-to-date easily, all within the Team Explorer window? All you need to do is to add the upstream remote.

Navigate to your cloned fork in Team Explorer, click the title bar to reveal repository menu and select Settings.


In the opened page select Repository Settings and then find the Remotes section at the bottom:


Click the Add link to open the Add Remote dialog window. Here fill out:

  • Name – upstream
  • Fetch – URL of the original GitHub repository you forked
  • Push – same as Fetch
  • Push matches fetch – leave checked
Adding upstream remote
Adding upstream remote

Confirm with Save and that’s almost it. Now we just need to do a fetch to get the current state of the upstream. Click the title of the Team Explorer window again and navigate to Sync:


And from the top menu click the Fetch link, select upstream from the dropdown menu and click Fetch. Now the branches from the repository should be available in the Branches view and you can merge the latest changes from upstream in your fork.

Tip: Force-reinstall NuGet packages

NuGet is a great package manager, but sometimes it misbehaves and packages are either not properly downloaded or are not properly included in your project. Whenever you come across this, I recommend doing a force-reinstall of all packages.

In Visual Studio go to Tools -> NuGet Package Manager -> Package Management Console . In the Package Manager Console window then enter the following command:

This will go package by package and force-reinstall them the opened solution.

If you want to force-reinstall packages only for one specific project instead of the whole solution, you can add the -ProjectName switch:


Connect(); 2017

Another year has come and with it the fourth annual on-line Microsoft Connect conference. Between 15th and 17th November you could watch the newest goodness from Microsoft for all developers on all platforms.

Two main keynotes were dedicated to intelligent cloud and building intelligent applications of the future. Let’s see what Scott Guthrie (of course in his favourite red polo shirt) and other speakers have unveiled. Continue reading “Connect(); 2017”

Using custom nuget.exe in VSTS build process

Soon after the release of Visual Studio 2017, the Visual Studio Team Services team has added a Hosted VS2017 build agent that has support for all the latest and greatest technologies. Unfortunately although the build task with Visual Studio 2017 is itself present, the newest version of NuGet wasn’t added, yet. Fortunately, it is possible to use a custom nuget.exe to circumvent this issue and be able to restore packages for project using the new csproj format with <PackageReference>. Continue reading “Using custom nuget.exe in VSTS build process”

Adding Hyper-V-less boot entry with PowerShell

Developers often encounter the need to run virtual machines using VirtualBox and Hyper-V-based mobile emulators on the same machine (for example Windows Mobile or Visual Studio Android Emulator). Unfortunately only one of the two can be enabled at once. The easiest solution is to create two boot entries and disable Hyper-V in one of them.

CMD way

The awesome Scott Hanselman provided a quick command line solution in one of his blogposts.

As part of creating a Chocolatey based PowerShell install script for my most used tools after computer reinstall, I wanted to make this automatic and preferably skip the copy-paste step.

PowerShell script

The script is very simple:

First line of the script runs the bcdedit  tool and create a copy of the current boot entry. The result is a string in the following form:

We need to parse out the identifier enclosed between curly brackets. This is just the job for regular expressions on the second line of the script. The matches are stored in the   $matches  variable.

Finally we can use the identifier to modify the boot entry to disable Hyper-V on the third line.

And that’s it! Pretty simple but convenient. You can simply run the script and the new Hyper-V-less boot entry will be created for you automatically. Be sure to run the script with administrator permissions.

You can download the script here.

How to show touch keyboard on touch interaction with WPF TextBoxes

Updated November 2016 – .NET Framework 4.6.2

Windows Presentation Foundation (WPF) apps have a bit harder life in the touch-enabled world. In WinRT apps, the touch keyboard shows up automatically when a text field gets focus so that the user can type without the need of a classic keyboard (no interrupting of her touch workflow). For classic desktop apps the situation differs – TextBoxes don’t cause the touch keyboard to appear and the user has to open it manually. That is obviously very cumbersome.

Hey! How can I get you to my WPF app?

There are two different workarounds for this problem.

The hack-y way

The first solution is quite a bit of hacking. This requires us to turn off the inking support for our WPF app and actually force the system to behave the right way. You will need some COM import and call native Windows API. This process is extremely well described here on Brian Lagunas’ blog and I encourage you to try it out. If it works for you, great!

The disadvantage of this solution, that I discovered, is that it interferes with touch “panning” of ListBox controls. Any try to do touch panning only fires ItemClick events on the hovered items and the user needs to scroll using the small scroll bar and that is more than inconvenient.

The simple, but more manual way

To overcome the issues that come after disabling inking support in your WPF app, we can go with a simpler but less automatic solution. We will extend the TextBox control and change its behavior when it gets touch focus.

So how does this work?

When the TextBox receives focus after the user enters it with touch, the GotTouchCapture event is called. In this event we can manually start up the process of touch keyboard. The touch keyboard is just a classic desktop application that lives on the path “C:\Program Files\Common Files\Microsoft Shared\Ink\TabTip.exe”.

This solution is very simple and doesn’t require any “hacking” per-se. The only disadvantage is that you as the developer have to ensure, that you use this modified version of TextBox control every time you need to get the right touch-based behavior.

Killing the process

A logical extension to this is to kill the touch keyboard process when it is no longer needed – the input loses focus. The Process.Start( string ) method returns an instance of Process class which provides a Kill() method that will terminate the process when called.

First we need to store the process instance in a private field of the TextBox:

Now we wire up the LostFocus event:


Update – Windows 10 way

In Windows 10, this becomes much less of a problem thanks to the new Tablet mode and settings.

Tablet mode

tablet-modeThe newest version of Windows brings a new mode called Tablet mode, which can be turned on via the Action center or in Settings app, and which is optimized for touch first usage. While some see the way it works as a downgrade opposed to Windows 8.1, it presents much more inuitive integration of both new Windows Store apps and classic desktop applications. Each app defaults to full-screen while preserving the multitasking option of two apps side-by-side. Another nice consequence of turning the Tablet mode on is that the touch keyboard is automatically triggered every time any text field gets focus, no matter the type of application. This undoes the need to launch the touch keyboard manually and lets the operating system take the wheel and ensure everything is handled corretly. The only disadvantage as opposed to the modern applications is the fact, that keyboard doesn’t shift nor resize the app window and overlays it (even in case it is pinned to the bottom of the screen). This means, that some content may become invisible (for example tooltips or context menus).

Outside of Tablet mode

But what about the case when you, for some reason don’t want the Tablet mode on but still want to enjoy the automatic handling of text input by the operating system? A inconspicuous setting can make just this happen!

Open the Settings app, go to Devices category and select Typing – here scroll down and you will see a setting that is by default turned off (for some reason, I can’t really understand why) – to show the touch keyboard in case of input while no keyboard is attached. This is the perfect solution for most cases and makes using all apps with touch a very pleasant and consistent experience.


Updated – .NET Framework 4.6.2

In August 2016 Microsoft announced a new update of .NET Framework 4.6.2. In addition to a very useful addition of Per-Monitor DPI for WPF, this update also addressed the problem with touch keyboard.

WPF apps targeting the new version of the framework support automatic invocation and dismissal of the touch keyboard, matching the behavior of UWP apps on Windows 10. That means you don’t have to make any additional changes to your new apps to support the touch keyboard.


Conditionally copying native libraries to output

With platform dependent native libraries like SQLite we often need to get hold of the right DLL files for the given architecture and copy them to project’s output folder. But how to do it in an easy way? Pre-build event commands give us the answer.

First, you will want to create a folder for the library you want to copy and create subfolders for each architecture you need. In each of those folders just place all the DLLs and supporting files you need to copy.


Now right-click your Visual Studio project’s node in Solution Explorer, select Properties and then Build Events tab in the left pane. You will be presented with two empty boxes. In these boxes you can enter any commands that you want to execute before the project is built or after it is built, respectively.


Now, click the Edit Pre-build … button you are ready to enter your desired command. We can use the simple command line tool xcopy to copy the files from our library folder to the output directory:

To explain what is going on here. The Xcopy tool has two main parameters – copy source and copy target. My sqlite folder is placed in a libs folder that is one level up from my project’s main directory (which is denoted by the “$(ProjectDir)” string) – hence I first navigate to parent folder by “..\” sequence and then to “libs\sqlite\” here I need to enter the correct subfolder for the current project architecture. We can get the “x64”, “x86”, or other current platform name using “$(PlatformName)” macro. Now finally in this folder I use an asterisk (“*”) to instruct xcopy to copy all files in the folder. The target directory for the build is specified by the “$(TargetDir)” macro and I also give two additional options “/E” (to include subfolders in the copying process) and “/Y” (to always overwrite existing files in the target directory).

Now along with each build action, our command will run and the files we need will be copied to the project’s target directory as we wanted. Simple enough, but saves a lot of manual labor.