Undoing Commits in Git

I’ve begun using Git for my personal software development about a year ago. So far, I’ve been very careful in what I commit and push back to the current branch. Making sure that it’s good before proceeding.

But any good VCS must have a undo function. And so far, I haven’t learned how to use that. Kinda silly of me; as that’s what any VCS should do. So, I’ve been searching the Internet to learn how Git does it. I’ve found this excellent, detailed description on how you can do it with Git on the command line.

Next I’d like to learn how to do this in Visual Studio Code and Visual Studio 2019. I’d appreciate any pointers to good references on doing this, please.

Visual Studio’s Shared Projects

Background and Motivation

At work we’ve been slowly replacing really old, legacy applications with some more modern technologies. This is so we can better maintain them and put them under source control. (Something that the old “apps” couldn’t do.) Our approach has been to write a single, base project in Visual Studio. Once we did that we branch the main project within source control, into new projects to replace an old, legacy app. (Yes, I know that our habit of branching within source control into a new VS solution which never gets merged back into main, isn’t standard. I’m working on trying to convince my colleagues that isn’t standard procedure.) This was OK, at the beginning. But the violation of the DRY principle has really got me wondering how we could better approach this, especially when it comes to code components which are identical for all of the projects, including the main trunk. Once we get to the point of having 10 or so projects, it’s going to become very tedious to have to make any necessary modifications to the common components within all of those projects.

Shared Projects, a way to help

So, I started to look around for some way of mitigating this. I came across something called Shared Projects within Visual Studio, which I didn’t even know existed. I learned that Shared Projects have been a part of Visual Studio since version 2015. I found a tutorial by Praveem Kumar called Shared Project: An Impressive Feature of Visual Studio 2015 Preview. It is very helpful, with only one problem for me. Praveem put the shared project in the same Visual Studio solution with the 3 client projects that he used to illustrate using shared projects. It’s my hope that at work we’ll create one solution and put one or more shared projects into it. Then later when we branch the main trunk into a new solution, we’d reference the shared project. So, what I’ve done to illustrate how I think we should do it is created 2 VS 2017 solutions, one with the Shared Project and the other a Windows Forms project that consumes the Shared Project, which I’ve shared in my GitHub account.

The Shared Project: MySharedProject

Following Preveem’s tutorial, to a point, I created a MySharedProject solution in VS 2017. (I decided to use .NET Framework 4.6.2.) You can find it in my GitHub repo MySharedProject. My GetEmployeeDetail() method is a little different in the property assignments and I was able to use string interpolation, which wasn’t available to Preveem when he wrote his.

public string GetEmployeeDetail()
EmployeeID = 247;
FirstName = "Ved";
LastName = "Prakasj";
Phone = "5055551234";
Address = "Albuquerque, New Mexico";
return $"Name: {FirstName} {LastName}\nEmp ID: {EmployeeID}\nAddress: {Address}\nPhone: {Phone}";

One thing I noticed that was different from what Praveem got, was that I couldn’t compile my version of the MySharedProject. Indeed, it wasn’t even an option:

Couldn't Build

My Client App: SharedWindowsFormsApp

Next I created a new VS 2017 solution that I called SharedWindowsFormsApp, which I’ve got in a different GitHub repo. (Please note that on my system, I put both repos under one folder. Also note that I decided not to replicate both the MVC and console apps that Praveem did.) My code for SharedWindowsFormsApp isn’t really different in any way from Praveem’s. So, how to make SharedWindowsFormsApp aware of the shared project? I right mouse button clicked on the solution and choose Add Existing Project:

Add Existing Project

Looking for the shproj file:

Select shproj

Now my SharedWindowsFormsApp’s solution looks like this:

New SharedWindowsFormsApp solution

Of course, I had to add a reference to the shared project, in SharedWindowsFormsApp project:

Add a Reference to MySharedProject

One thing that I thought would happen is I thought Visual Studio would copy the MySharedProject code under that SharedWindowsFormsApp solution, into a folder named MySharedProject. I opened up File Explorer on my Windows 10 machine to verify that, but found I was wrong! So, I opened up the SharedWindowsFormsApp.csproj file to see what was going on.  At the bottom I found this:

Solution View

Looking at this you can see the first Import is a relative reference to the place, on my machine, where I found the .shproj file. And it has the attribute of Label=”Shared”.
Once that was done, I could build SharedWindowsFormsApp and it ran fine:

Running SharedWindowsFormsApp

Discussion with MS Tech Support on Web API

A note about this blog post

Everything below is what I wrote, basically on the fly as it was happening. Please excuse the somewhat haphazard blog post.

The Problem

After creating a new Web API project and only adding the necessary information for the dev ADFS server, I got this error:



Message=Could not load file or assembly ‘Microsoft.IdentityModel.Protocols.WsFederation, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)


I called Microsoft technical support on 7/20/20178 to resolve this issue.

Wrong WsFederation version

The error message I got when running VS 2017 debugging, telling me to install Microsoft.IdentityModel.Protocols.WsFederation version, was in fact, wrong. I should have installed 5.2.1.

And this post on asp.net forums

Fusion Logging

The tech support enabled something called Fusion logging, to help her diagnose what the issue was. She pointed me to this Stack Overflow post describing how to enable Fusion logging in the Registry.

Running Visual Studio was slow after that

The Fusion logging did slow down VS startup, obviously I’ve set both the EnableLog and ForceLog keys to 0 (they were set to 1). I had to reboot, to get it to work a bit faster.

Note: Do NOT simply delete the Registry cluster

Don’t just delete the registry cluster at Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion
There are sub-folders (sub registry clusters) under that cluster that belong there! (e.g.: GACChangeNotification, NativeImagesIndex and PublisherPolicy).

Possible Alternatives to editing the Registry

The MS Technical support person didn’t mention this, but it looks like it is possible to run the Fusion log viewer differently.

Oh Groove, I am Going to Miss You!

We learned this week that Microsoft intends to discontinue their excellent music service, known as Groove. This for me very sad news. I’ve been a member of Microsoft’s music services since back in the Zune days. In the last 12 months I’ve really come to love Groove. I love its suggesting new playlists for me. I’ve listen to many of them. Some, I didn’t care for, but others I’ve loved. Its introduced new artists and music to me.

Then they made Groove even better by adding music videos! I had no idea how much I’d love watching music videos!

Yes, I know that the transition is going to Spotify. Yes, I know that many people love Spotify. But this still is a very, very sad time. And at least from the time I’ve spent with Spotify it didn’t deliver the music I liked, nor (as far as I know) does it provide music videos.

Oh well, we’ve no choice in the matter. I’ll just enjoy Groove for the time I have left with it and then move everything to Spotify.