.NET Core class library solution from scratch

This post documents using the dotnet command to create a class library solution from scratch. The solution builds a class library project, and a MS unit test project that tests the class library.

To create an empty solution called MySolution.sln

dotnet new sln [--force] -n MySolution

sln is just one of several templates supported by the command. To see a list, try dotnet new -l. Additional templates can be installed using dotnet new --install e.g. AvaloniaUI.

To create a new class library project

dotnet new classlib [--force] -n MyLibrary

This creates a folder called MyLibrary and a MyLibrary.csproj file in it. Any C# files in the MyLibrary folder will be compiled during build.

If MyLibrary exists, use --force to replace the exiting project file.

If your project has an AssemblyInfo.cs that contains assembly attributes, you can edit project file to exclude autogeneration of assembly attributes

<Project Sdk="Microsoft.NET.Sdk">


    <PackageReference Include="Microsoft.CSharp" Version="4.4.0" />


Otherwise, you’ll get errors such as

obj/Debug/netcoreapp2.0/MyLibrary.AssemblyInfo.cs(10,12): error CS0579: Duplicate 'System.Reflection.AssemblyCompanyAttribute' attribute ...

Also, note the use of Microsoft.CSharp package in the project file. That is required to use C# language features such as dynamic. Without it, you’ll get an error such as

MyClass.cs(177,50): error CS0656: Missing compiler required member 'Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo.Create'

To add package reference, head into the MyLibrary project folder and run

dotnet add MyLibrary.csproj package Microsoft.CSharp

Then, run the following to restore package(s) from nuget

dotnet restore

Head over to the solution folder. To add the class library project to the solution, and build the solution

dotnet sln [MySolution.sln] add MyLibrary/MyLibrary.csproj
dotnet build

Specifying solution name is optional if you’ve got just one solution file in a folder.

To add a new MS unit test project

dotnet new mstest [--force] -n MyLibraryTest

Head into MyLibraryTest and add a reference to MyLibrary and package references

dotnet add MyLibraryTest.csproj reference ../MyLibrary/MyLibrary.csproj
dotnet add MyLibraryTest.csproj package Microsoft.CSharp
dotnet restore

Head over to the solution folder, build, and run unit tests

dotnet build
dotnet test MyLibraryTest

That wraps up the basic usage of dotnet to create and maintain a simple .NET Core class library project.


Highlighting problems in Lua dissectors

Here’s a snippet of code from nordic_ble dissector that shows how you can highlight problems in Lua dissectors using add_expert_info

        local item  = tree:add_le(hf_nordic_ble_micok, tvb(UART_PACKET_FLAGS_INDEX, 1), micok > 0)
        if micok == 0 then
            -- MIC is bad
            item:add_expert_info(PI_CHECKSUM, PI_WARN, "MIC is bad")
            item:add_expert_info(PI_UNDECODED, PI_WARN, "Decryption failed (wrong key?)")

NOTE I recommend using add_proto_expert_info because add_expert_info is now deprecated.

GRASP SOLID for effective object-oriented programming

Objects are responsible for their state and behavior. Assigning responsibilities to objects effectively makes maintenance of a program less cumbersome.

This post summarizes the GRASP patterns and SOLID principles. They may be thought as the principles and patterns underlying the design patterns described in Design Patterns: Elements of Reusable Object-Oriented Software.

GRASP Patterns

General Responsibility Assignment Principles or GRASP patterns were popularized by Craig Larman in his book Applying UML and Patterns. They help with identifying objects required by a program, and their responsibilities.


Assign responsibility of creation to object that contains, or has the information required to create, a given object.


Assign responsibility to object representing a module’s facade, or a handler of a use case. Beware of a fat controller.

High Cohesion (HC)

Assign responsibility to object with closely related state and behavior. Don’t Repeat Yourself (DRY) rule helps maintain HC.


Assign responsibility to an intermediary object so that coupling is low.

Information Expert (IE)

Assign responsibility to object that has related information.

Low Coupling (LC)

Creation, inheritance, type reference, and message passing, all result in coupling. Assign responsibility such that coupling is low.


Assign behavior to subclass when related behavior varies by type. Prefer aggregation and composition to inheritance.

Protected Variations (PV)

Assign responsibility to new object that provides a stable interface around known instabilities.

Pure Fabrication (PF)

Assign responsibility to a new object not derived from the domain to ensure LC and HC.

SOLID Principles

SOLID are more generalized principles popularized by Robert Martin aka Uncle Bob in his book Agile Software Development: Principles, Patterns, and Practices.

Single-Responsibility Principle (SRP)

A class or module does one thing well. See HC.

Open-Closed Principle (OCP)

A class, module, or function, should be closed for modification but open for extension.

Liskov Substitution Principle (LSP)

Subclasses must be substitutable by their base (super) classes.

Interface Segregation Principle (ISP)

Avoid situation where clients depend on a fat interface. Changes to fat interface due to any client will affect all the other clients.

Dependency Inversion Principle (DIP)

Prevent modules in higher (more abstract) layers of an architecture from being impacted by changes in modules in lower layers. Abstractions should not depend on concrete implementations.