GitHub Releases New “Topics” Feature

GitHub added a new feature, Topics, which allows repo admins to tag their repositories. Topics can be things such as the purpose, language, platform, subject area, or anything else that you think might be useful as a classification.

Topics appear right below the repo’s description on the repository’s main page.

GitHub Topics
Topics allow users to more easily find repositories to use and contribute to by allowing for searches by these tags. You can perform a topic search by using the topic keyword. For example, the following would be used to search for repositories with “react” as a topic:


GitHub Topic Search

GitHub uses machine learning to analyze public repositories in order to provide topic suggestions. GitHub doesn’t perform this analysis on private repositories. While both public and private repositories can have topics, you will only see private repositories that you have access to when searching by topic.

If you are a repo administrator, you can classify the repository by clicking “Add Topics” under the repository description. Once you have at least one topic associated with a repository, the option becomes “Manage topics”, and allows you to delete existing topics as well as add new ones.

GitHub Manage Topics


PowerShell Replaces Command Prompt in Latest Windows 10 Insider Build

The future direction that Microsoft is taking with the Windows Command Prompt and PowerShell became evident in the latest Windows 10 insider build (14971). PowerShell is now the command shell from File Explorer, replacing the Command Prompt (cmd.exe). When users click the “WIN + X” menu, right-click the Start button, select off the “File” menu in File Explorer, or view the context menu that appears when right-clicking whitespace in File Explorer, they will see PowerShell instead of Command Prompt.

In addition, typing “cmd” in the Run Dialog now brings up PowerShell rather than Command Prompt.

For those of you who prefer to still use the Command Prompt, you can change this new behavior by opening “Settings > Personalization > Taskbar” and turning the new “Replace Command Prompt with Windows PowerShell in the menu when I right-click the Start button or press Windows key + X” setting to off.

PowerShell recently reached 10 years in production, and with the advanced functionality that it provides, we can expect Microsoft to continue making PowerShell, not the Command Prompt, the main command shell of Windows.


Top 10 GitHub Project Releases

One way to measure the popularity of GitHub projects is to look at their star count. After the recent successful launch of the JavaScript dependency manager Yarn, GitHub compiled some statistics on the projects which received the most stars in their first week.

Since 2015, the following are the most successful open source project launches on GitHub, based on the number of stars they received in their first week:

#1 – Swift
Swift programming language by Apple
Release Date: December 3, 2015
Star Count After 1 Week: 23,097

#2 – Yarn
Package manager for JavaScript
Release Date: October 11, 2016
Star Count After 1 Week: 16,068

#3 – Tensorflow
Software library for numerical computation using data flow graphs
Release Date: November 9, 2015
Star Count After 1 Week: 11,822

#4 – React Native
Framework released by Facebook for building native apps with React
Release Date: March 26, 2015
Star Count After 1 Week: 10,976

#5 – Material Design Lite
Material design components in HTML/CSS/JavaScript from Google
Release Date: July 7, 2015
Star Count After 1 Week: 9,609

#6 – N1
Extensible desktop mail app built on the modern web
Release Date: October 5, 2015
Star Count After 1 Week: 8,588

#7 – Visual Studio Code
Electron based code editor from Microsoft
Release Date: November 18, 2015
Star Count After 1 Week: 7,847

#8 – Clipboard.js
Lightweight JavaScript library for copying text to clipboard
Release Date: November 27, 2015
Star Count After 1 Week: 6,522

#9 – create-react-app
Create React apps with no build configuration
Release Date: July 22, 2016
Star Count After 1 Week: 6,348

#10 – Anime
Flexible, lightweight JavaScript animation library
Release Date: June 27, 2016
Star Count After 1 Week: 6,013


Registration-Free COM Component Activation

In order to use a Component Object Model (COM) component in an application, the binding/activation information must be made available so that the operating system can find it when a program needs the component. Typically this is accomplished by registering the COM component, which places the activation information in the Windows registry.

Registration-free COM allows a COM component to be activated without registration. This is a feature that has been available since Windows XP.

There are a couple of main advantages to registration-free COM. The first is that it allows us to use XCOPY or FTP to simply copy our application for deployment, without the additional step of registration. Another advantage is that in situations in which you have multiple versions of the same DLL installed on a computer, we can control which version is activated. This reduces the possibility of DLL version conflicts.

Registration-free COM is made possible through the use of manifest files. Component manifest files, which are in XML format and are created at design time, contain the necessary binding and activation details. At runtime, in the absence of registry entries, the manifest files are used for activation.

In order to create a manifest file, we first need the type library (TLB) of the component. A type library is a binary file that stores information about a COM object’s properties and methods, in a form that is accessible to other applications at runtime.

Tools like the Type Library Exporter (Tlbexp.exe) or the Assembly Registration Tool (Regasm.exe) can be used to generate a type library. For cases where you are dealing with an unmanaged COM DLL, you can use a tool such as Resource Hacker.

To generate a type library using Resource Hacker, first open the relevant DLL file and navigate to the TYPELIB node in the treeview.


Right click on the node and select “Save Resource to a *.bin file …”. Supply a filename and give it a .tlb extension.

Now that we have a type library, we can generate a manifest file from it. There are a variety of tools that can be used to generate a manifest file from a type library. One of the most readily available is Mt.exe, which is included in the Microsoft Windows SDK (which is installed with Visual Studio).

At the command line, simply supply the TLB and DLL filenames to mt.exe, along with the name you want used for the output. The output will be the manifest file, so name it with a .manifest extension.


If you open the newly created manifest file, you will see the classes and interfaces exposed by the COM component, along with the binding and activation details that will be needed to use it.

Once the manifest file has been created, use Visual Studio to add the manifest file to the project(s) that will need to use the COM component. In addition, ensure that the COM component DLL is located in the same directory as the assembly that will be using it.

If you want to use a COM component without registering it, using manifest files is a fairly straightforward approach. Taking advantage of this technique will allow you to use XCOPY or FTP for deployment without the additional steps for registration. And if you have a situation in which you have multiple versions of the same COM component on a machine, this approach allows you to control which version will be activated.


C# Anonymous Pipes for Interprocess Communication

There are times when you may need to communicate between multiple processes, perhaps to send messages or share data. A recent example that I worked on involved a 64-bit application that needed to use a 32-bit DLL. The 32-bit DLL had to run in a separate process, so interprocess communication (IPC) was needed to allow the two processes to work together.

The .NET Framework provide a number of ways to perform IPC. In this post we’ll explore one such method: anonymous pipes. Anonymous pipes don’t provide as much functionality as some other methods (i.e. named pipes), and you can’t use it for communication over a network. But when you need to communicate between processes on the same computer, anonymous pipes are an excellent choice as they require less overhead.

In the “parent” (or “server”) process, we begin by creating a separate process.

The FileName property should equal the executable for the second process, and can include a full or relative path. In the code above I am assuming that “SomeOtherApp.exe” is going to be located in the same directory.

We then use the AnonymousPipeServerStream class to expose a stream around an anonymous pipe. Anonymous pipes are unidirectional, so if you need bidirectional communication, you will need two pipes. When you instantiate an AnonymousPipeServerStream, you can specify the pipe direction (in or out).

Once the anonymous pipes have been instantiated, handles to the pipes can be passed to the second process, and then that process can be started.

We then need to release the local handles that were created with the above GetClientHandleAsString calls:

If DisposeLocalCopyOfClientHandle is not called, the anonymous pipe will not receive notice when the child/client process disposes its pipe stream.

Now that the pipes have been established, we can read/write values with the other process.

In the code above I am only passing strings between the two processes, so I am using StreamWriter/StreamReader. If you had other needs, you could use something else, such as BinaryWriter/BinaryReader.

Once we’re done, we call WaitForExit and Close to end the second process that we created.

The code for the “child” (or “client”) process is similar, with a few notable exceptions. We first have to get the anonymous pipe handles that we previously passed to the second process.

Please note that we passed in the parent process’s read and then write handles, but to the second (“client”) process, the roles are reversed. The pipe that the parent process is reading from is the one that the child will be writing to, and the pipe that the parent process is writing to is the one that the child will be reading from.

Also, in the parent process we used the AnonymousPipeServerStream class. In the client process we need to use the AnonymousPipeClientStream class instead to expose a stream around an anonymous pipe. Once again, since the pipes are unidirectional, if you need bidirectional communication you will need two pipes.

In addition to the code listings that follow, all of the code for a working example is available on GitHub so you can download and run it. Here is the code for the parent/server process:

Here is the full code listing for the child/client process: