Saturday, May 12, 2018

Ubuntu (for the color blind developer): Removing colors from ls

The Ubuntu virtual machine I created under Azure displays the output from ls as follows:

The file names are in light grey and the directory names are in illegible dark gray.  A lazy approach to fixing this was presented in Git (for the color blind): Detecting changes to a repository, which was simply to pipe the output through more to strip of the colors (ls | more). An example of this is as follows:

The real issue is that some person, who hates people who are color blinded, decided to alias ls to ls --color=auto as is shown when all the aliases are listed courtesy of the alias command (see below):

To fix this flaw in the default Ubuntu configuration use unalias ls as follows:

Once ls is unaliased the output is legible as is demonstrated below:

Thursday, May 10, 2018

From JSON to C#

The problem is common. As a developer you are handed JSON (mostly likely from a RESTful web service). From said JSON you need to generated the corresponding C# classes.

Solution 1: Web Essentials

The approach with the tightest Visual Studio integration is installing the Web Essentials extension found at After installing the extension create a C# file into which C# code will be generate. Below in example of a source file just waiting to be filled with C# generated from JSON:

Notice in the screenshot above the cursor is left where class will be generated.

Select the JSON text and copy it to the clipboard (CTRL-C). Once this open Visual Studio's Edit menu and select Past Special | Paste JSON As Classes:

An example of the code Paste Special |mJSON as Classes can generate is as follows:

Solution 2:

The web site provides the same service as the Web Essentials, Visual Studio Extension, Paste JSON As Classes. This site is simple to use. Paste in the JSON and click on the Generate button. An example of this is as follows:

Saturday, May 5, 2018

StyleCop: Setting to use it for a Solution with multiple Project Types (.NET Framework, .NET Core and .NET Standard Library)

StyleCop is a static code analysis tool from Microsoft targeting C# applications that is elegantly integrates with Visual Studio. In layman's terms, it makes developers code in a consistent manner. This post details how to setup StyleCop for projects that use the .NET Framework, .NET Standard and .NET Core.

The setup steps presented include the inclusion of a StyleCop configuration file, stylecop.json. The stylecop.json file is used for configuring the behavior of the static code analysis rules. The enabling and disabling of these rules is handled by a different mechanism. What stylecop.json does provide is a way to specify a company name and copyright to be used in the header documentation of each source file.

The sample solution for which StyleCop will be setup as as follows, a solution composed of a .NET Framework console application and a .NET Library class library:

The setup of StyleCop is identical for .NET Standard libraries and .NET Core so the projects above will demonstrate the setup differences.

The first step is setting up StyleCop is to right click on the solution Solution Explorer and from the context menu, select Manage NuGet Packages for Solution:

Selecting Manage NuGet Packages for Solution display the NuGet manger for the solution:

There are four tabs along to of the NuGet manager: Browser, Installed, Updates and Consolidate. Make sure the Browser tab is selected:

Enter StyleCop in the search text box which displays a list such as the following:

Select StyleCop.Analyzers and install the package for all the C# projects in the solution (for this example the projects are ADotNetConsoleApplication (.NET Framework 4.6.1) and ADotNetStandardClassLibrary). After installing the StyleCop.Analyzers NuGet package rebuilding our reveals a plethora of warnings courtesy of StyleCop:

One of the warnings is a clue to the next setup step:

To remove this error right click on each C# project in the solution in Solution Explorer and select Properties form the context menu:

As can easily be surmised, selecting Properties displays the properties that can be configured for the project:

From the tabs alone the left of the configuration window select Build:

When the Build properties are displayed scroll down to the bottom of the settings until the "XML documentation file" checkbox is visible:

Check the "XML documentation file" checkbox and close the properties window.Repeat the previous step of checking the "XML documentation file" checkbox for each C# project in the solution. The aforementioned, SA1652 Enable XML documentation output, warnings will no longer appear.

One error the continues to appear is the following:

Each file must begin with a standard header that includes the company name and standard copyright text. This is a matter of cut and paste but it raises an additional issue. How can the company name and copyright standard text be enforced across all source files. Enter the stylecop.json file and example of which is as follows:

  "settings": {
    "documentationRules": {
        "companyName": "Software Pronto, Inc.",
           "Copyright © {companyName} All rights reserved."

The stylecop.json file is just a text file which can be placed at the solution level and can be shared by each project in the solution. Am example of the stylecop.json added to the solution is as follows:

Instead of copying the stylecop.json file to project and adding it to each project the stylecop.json file can be added as link to each project where the link refers to the master copy of the file at the solution level. How to add linked files, specifically the stylecop.json file is reviewed in the previous blog post: Visual Studio (file linking): using Solution-level files in Projects. The solution with both projects containing the linked version of stylecop.json file is as follows:

stylecop.json has been added as link to both projects by neither project knows what build action to take with this newly added file. To configure stylecop.json for the .NET Framework project, ADotNetConsoleApplication, right click on the stylecop.json file in Solution Explorer and select Properties from the context menu:

Selecting Properties from the context menu displays the following, the properties for the stylecop.json file:

Notice in the properties that the Build Action is set to None which means the project has no idea what to do with the file. For a project targeting the .NET Framework, the correct Build Action is AdditionalFile. See below for the correct Build Actions assigned to this project stylecop.json file:

For the .NET Standard project the Build Action for stylecop.json is also set by right clicking on the file in Solution Explorer and selection Properties from the context menu. This displays the properties for the linked stylecop.json file which is clearly a different window that is shown for .NET Framework projects:

Notice in the window above that the Build Action is set to Content. The correct setting for Build Action is, C# analyzer additional files. Below is an example of the Build Action correctly set for stylecop.json for a .NET Standard Library or .NET Core project:

After the Build Action for the stylecop.json file has bee set to C# analyzer additional files, click on OK or Apply to record the change in Build Action. Remember this is how the Build Action is set for stylecop.json files for a .NET Standard Library or .NET Core project:

What remains to resolve the "The file header is missing or not located at the top of the file." warning. The following header text should be added to each C# file in the projects and of note, the company name and copyright text in the header match that specified in stylecop.json:

An example of the header used in (matching stylecop.json) in each C# source file is as follows:

// <copyright file="AssemblyInfo.cs" company="Software Pronto, Inc.">
// Copyright © Software Pronto, Inc. All rights reserved.
// </copyright>

It is important to note that the "file" documentation property must match the name of the C# source file.

The projects in this sample still generate warnings. Removing these warnings is an exercise left to the reader. These warnings are of course making the solution conform to the default rules enforced by StyleCop.

Appendix A: Why .NET 4.6.1 was select to work with .NET Standard 2.0

The article, .NET Standard, contains the following compatibility matrix showing that the highest version of the .NET Framework that is compatible with .NET Standard 2.0 is .NET Framework 4.6.1:

Wednesday, May 2, 2018

Visual Studio (file linking): using Solution-level files in Projects

In Visual Studio there are times when it makes sense to share a non-code file between multiple projects in a solution. One such scenario is when using the static code analysis tool, StyleCop. Among the rules StyleCop can enforce is that every source file in a project must contain a standard header including company name and copyright. For each source file, company name and copyright must match values specified in the StyleCop configuration file, stylecop.json. So the file to share between multiple projects is stylecop.json which can be added at the solution of a Visual Studio solution such as the following:

The solution contains two project, ADotNetConsoleApplication and ADotNetStandardClassLibrary. The goal is to add Solution Items\stylecop.json to both projects. To to this right click on the project, ADotNetConsoleApplication and select Add | Existing Item from the context menu displayed (see below):

When Existing Item is selected the following dialog is displayed (aptly named the Add Existing Items dialog):

Notice that the file filter is set to Visual C# Files. In order to see the stylecop.json file, change the filter to All Files (*.*) as follows:

Navigate in the Add Existing ITems dialog to the root of the solution and select the file stylecop.json.

Notice next to the Add button on the dialog there is a downward pointing arrow. Click on this arrow:

Click on Add As Link and once this is selected the file will show up in the project:

The master copy of the file is at Solution Items\stylecop.json and the linked version is under the ADotNetConsoleApplication project. Too add stylecop.json as a linked file to the ADotNetStandardClassLibrary project is a matter of repeating the steps shown above.

Sunday, February 25, 2018

Git hosted by Creating a Pull Request

For some reason Git had create new names for things that already existed in computer science. The term code review was coined by Charles Babbage in 1810 so two centuries later Git decided that they would change Babbage's term "code review"  to "create a pull request." So this post describes how to create a pull request using a Git repository hosted on

Once a branch is pushed (see Git: Pushing code to a remote repository) a pull request can be generated that allows other team members to review the code. There is no mechanism to create pull requests from the command-line. Creating a pull request is done suing the web front end of the Git provider (GitHub, BitBucket, , etc.).

To generate a pull request for a Git repository hosted on , open the Git project in the web interface and navigate to Code | Branches:

To create the pull request first hover the mouse to the right of the delete icon (the trash can) until three dots (...) are displayed with the tool tip "More Actions...".

Clicking on the three dots (....) displays a context menu that include menu item, New pull reuqest:

Selecting New pull request displays the following:

Notice in the screen above the individual reviewers can be added to the pull request. Also notice that a work item (e.g. Task-335) can and should be associated with the pull request. A correct pull request is associated with only a single work item.

Once the fields have been filled in as desired, click on the Create button to create the pull request.

Saturday, February 24, 2018

Git: Pushing code to a remote repository


This is the second recipe in the series designed to inspire my team of user-interface-git-users to embrace the command-line. This post presents the commands used to determine which files have been changed in a repository and how to push to a remote repository.

Detecting changes to Git repository

After modifying files, deleting files or adding files to a Git repository, the git status command can be used to determine which files have been changed;

git status

Below the changes to a repository can be seen by invoking git status:

Using git status the files modified can be determined. Additional the files/directories added and deleted can be determined. The output is color code for those who can see color. Being color blind, I cannot read the non-white text above so I wrote a separate post to address the issue Git (for the color blind): Detecting changes to a repository.

Pushing code to a remote Git repository

The steps to pushing code to a remote repository are:

  • git add -- adds files in the directory or sub-directory to a staging area. Individual files or folders can also be specified.
  • git commit -- records the change to the repository (commits them locally) and includes a message to describe the purpose of the commit.
  • git push -- pushes changes from a local branch to a remote branch meaning your local changes get pushed up to the server hosting Git.

An example of the commands to run is as follows:

git add .
git commit -m "Task-335 completed"
git push origin Task-335

Invoking the command sequence above generated the following:

The "git add ." added all modified, created and delete files and directories including those in sub-directories. It is also possible add files or folders individual using "git add <filename>" and "get add <directoryname>".

 The message with commit should describe the action. Since Task-335 is completed there is not much to describe,. To see Task-335 the bug tracker can be used.

The command "git push origin Task-335" pushes the local changes from branch, Task-335, back to origin. The term "origin" refers to the cloned repository.

Wednesday, February 21, 2018

Git (for the color blind): Detecting changes to a repository

I am color blind. Git's command-line clearly written by developers who are not color blind. This post will present how to get around Git's use of unreadable, dark-gray-text on a black background. Here is an example of Git's use of dark-gray to indicate files have been modified (if you see the color red, why are you reading this article?):

In order to change from the dark-gray-text on a black background run git Gtatus and pipe it through more:
git status | more

An example of this is as follows:

Notice above that piping through more removes all dark-gray and makes the text legible.

Another way to fix the text issue is to swap the foreground and background colors of the console window. This works for modified but new files are markee in light green so these become hard to see.  It is even possible to set the colors Git uses. An excellent article discussing this is How to: Colours in Git.

In case Mr. Nnathan Hoad's blog link (reference above) goes away, here is the contents of his blog: