Solution-wide project properties with Directory.Build.props

2018-04-032018-04-01 TPodolak.NET, MsBuild

1. Problem

When you work with a solution which contains multiple projects, you usually have some kind of convention which is applied to all of the projects. For instance, in my case, I always make sure that Stylecop.Analyzers package is installed and properly configured in every project. In this particular case, this boils down to adding these lines into the csproj file

<PropertyGroup>
  <TreatWarningsAsErrors>True</TreatWarningsAsErrors>
</PropertyGroup>
<ItemGroup>
  <AdditionalFiles Include="..\StyleCop.json" />
</ItemGroup>
<ItemGroup>
  <PackageReference Include="StyleCop.Analyzers" Version="1.0.2" />
</ItemGroup>

</PropertyGroup>

</ItemGroup>

</ItemGroup>

Unfortunately, you have to add these lines to every project in a solution in order to make the Stylecop.Analyzers work for given project. This might be fine if you create all of them up front, but in real life scenario sooner or later you will add a new project to the solution. In that case, you might forget about adding those magic lines, so you will end up with inconsistent coding style in your repository. An additional problem with this approach is a code duplication so in case you rename StyleCop.json file you will have to make sure you update it everywhere. A partial solution for that problem is a manual import of custom made .props file, however, this approach is not perfect as well. The import part is not automatic, that is why you still have to remember about adding import directive to all of your projects.

2. Solution

Fortunately starting form MSBuild 15 you can bypass the limitations mentioned above thanks to automatic imports of properties from Directory.Build.props file. All you have to do is to create a beforementioned file in the root folder of your solution and you are good to go. The properties defined in the Directory.Build.props file will be automatically propagated to all of the child projects. In my case, this file looks as follows

<Project>
  <PropertyGroup>
    <TreatWarningsAsErrors>True</TreatWarningsAsErrors>
  </PropertyGroup>
  <ItemGroup>
    <AdditionalFiles Include="..\StyleCop.json" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="StyleCop.Analyzers" Version="1.0.2" />
  </ItemGroup>
</Project>

</PropertyGroup>

</ItemGroup>

</ItemGroup>

</Project>

The sample application which leverages this feature can be found here

RedisSessionStateProvider – unknown command ‘EVAL’

2016-10-292016-11-03 TPodolak.NET, ASP.NET-MVC, Redis

A couple of days ago I was trying to use Redis as session storage for one of my ASP .NET websites. Even though it seemed to be a rather straightforward task (Scott Hanselman wrote about that a while ago), I ended up with some weird exception while running the app: ERR unknown command ‘EVAL’

This wasn’t for sure a connectivity issue, as I was able to connect to Redis server from Redis Client – redis-cli. For me it looked like my server is not able to “understand” EVAL command. I started digging around and it turned out that this command has been introduced in version 2.6.0
I’ve connected to the server using redis-cli and checked the version with

info

info

command and basically that revealed the problem.

As you can see I’ve accidentally installed version 2.4.6 (I have no idea how I ended up with so old version). After upgrading to the newest one, my problem was gone and I was able to successfully store session in Redis.

Abusing collection initializers

2016-02-012016-02-01 TPodolak.NET, .NET 4.0

Most of .NET developers are familiar with collection initializers syntax. Long story short, this language feature allows you to replace this ugly syntax

var numbers = new List<int>();
numbers.Add(1);
numbers.Add(2);
numbers.Add(3);
numbers.Add(4);

var numbers = new List<int>();

numbers.Add(1);

numbers.Add(2);

numbers.Add(3);

numbers.Add(4);

with much shorter and cleaner one

var numbers = new List<int> { 1, 2, 3, 4 };

1	var numbers = new List<int> { 1, 2, 3, 4 };

The more interesting thing is the fact that you can leverage this syntax not only for build-in collections but also for your custom classes. In order to do that your class must implement IEnumerable interface and expose public Add method. Let’s assume that we have some real case scenario and we have class which looks like that

public class StatusMessages : IEnumerable<StatusMessage>
{
    private List<StatusMessage> messages = new List<StatusMessage>();

    public IEnumerator<StatusMessage> GetEnumerator()
    {
        return this.messages.GetEnumerator();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return this.messages.GetEnumerator();
    }
}

public class StatusMessage
{
    public string Text { get; set; } = string.Empty;
    public string SourceSystem { get; set; } = string.Empty;
    public int StatusCode { get; set; }

    public StatusMessage()
    {
    }

    public StatusMessage(string text)
    {
        this.Text = text;
    }

    public override string ToString()
    {
        return $"Text: {this.Text} StatusCode: {this.StatusCode} SourceSystem: {this.SourceSystem}";
    }
}

public class StatusMessages : IEnumerable<StatusMessage>

{

private List<StatusMessage> messages = new List<StatusMessage>();

public IEnumerator<StatusMessage> GetEnumerator()

{

return this.messages.GetEnumerator();

}

IEnumerator IEnumerable.GetEnumerator()

{

return this.messages.GetEnumerator();

}

public class StatusMessage

{

public string Text { get; set; } = string.Empty;

public string SourceSystem { get; set; } = string.Empty;

public int StatusCode { get; set; }

public StatusMessage()

{

}

public StatusMessage(string text)

{

this.Text = text;

}

public override string ToString()

{

return $"Text: {this.Text} StatusCode: {this.StatusCode} SourceSystem: {this.SourceSystem}";

}

This is a simple wrapper over the List. At this moment we can’t use collection initializer when constructing objects of this classs. However by adding method Add

public class StatusMessages : IEnumerable<StatusMessage>
{
    // rest of the code omitted for brevity
    public void Add(StatusMessage message)
    {
        this.messages.Add(message);
    }
    // rest of the code omitted for brevity
}

public class StatusMessages : IEnumerable<StatusMessage>

{

// rest of the code omitted for brevity

public void Add(StatusMessage message)

{

this.messages.Add(message);

}

// rest of the code omitted for brevity

}

we can create a new instance of that class just like we would do with List

var messagesAddInitializer = new StatusMessages
            {
                new StatusMessage("y"),
                new StatusMessage("x"),
            };

var messagesAddInitializer = new StatusMessages

{

new StatusMessage("y"),

new StatusMessage("x"),

};

What is more, it is possible to have multiple overloads of Add method in our class, so for instance if we add

public class StatusMessages : IEnumerable<StatusMessage>
{
    // rest of the code omitted for brevity
    public void Add(string text)
    {
         this.Add(new StatusMessage(text));
    }
    // rest of the code omitted for brevity
}

public class StatusMessages : IEnumerable<StatusMessage>

{

// rest of the code omitted for brevity

public void Add(string text)

{

this.Add(new StatusMessage(text));

}

// rest of the code omitted for brevity

}

we are able to use this syntax

var messagesAddStringInitializer = new StatusMessages
            {
                "y",
                "x"
            };

var messagesAddStringInitializer = new StatusMessages

{

"y",

"x"

};

In addition it is even possible to use a mix of Add overloads

var messagesAddAndTextInitializers = new StatusMessages
            {
                new StatusMessage("y"),
                "x"
            };

var messagesAddAndTextInitializers = new StatusMessages

{

new StatusMessage("y"),

"x"

};

Add method can also have multiple arguments

public class StatusMessages : IEnumerable<StatusMessage>
{
    // rest of the code omitted for brevity
    public void Add(int statusCode, string text)
    {
        this.Add(new StatusMessage(text) { StatusCode = statusCode });
    }
    
    public void Add(int statusCode, string text, string sourceSystem)
    {
        this.Add(new StatusMessage(text) { StatusCode = statusCode,SourceSystem = sourceSystem });
    }
    // rest of the code omitted for brevity
}

public class StatusMessages : IEnumerable<StatusMessage>

{

// rest of the code omitted for brevity

public void Add(int statusCode, string text)

{

this.Add(new StatusMessage(text) { StatusCode = statusCode });

}

public void Add(int statusCode, string text, string sourceSystem)

{

this.Add(new StatusMessage(text) { StatusCode = statusCode,SourceSystem = sourceSystem });

}

// rest of the code omitted for brevity

}

in that case we are able to use this syntax

var messagesMultipleArgumentsInitializers = new StatusMessages
            {
                { 1, "x" },
                {1,"x","source" }
            };

var messagesMultipleArgumentsInitializers = new StatusMessages

{

{ 1, "x" },

{1,"x","source" }

};

The last thing I would like to point out is that Add function doesn’t have to be an instance method, we can easily implement it as an extension method and still leverage the collection initializer syntax.

namespace AbusingCollectionInitializers
{
    public static class StatusMessagesExtensions
    {
        public static void Add(this StatusMessages statusMessages, int statusCode)
        {
            statusMessages.Add(new StatusMessage() { StatusCode = statusCode });
        }
    }
}

namespace AbusingCollectionInitializers

{

public static class StatusMessagesExtensions

{

public static void Add(this StatusMessages statusMessages, int statusCode)

{

statusMessages.Add(new StatusMessage() { StatusCode = statusCode });

}

Now with proper namespace import we can write this code

using AbusingCollectionInitializers;
// rest of the code omitted for brevity
var messagesExtensionInitializers = new StatusMessages { 1,2,3 };

using AbusingCollectionInitializers;

// rest of the code omitted for brevity

var messagesExtensionInitializers = new StatusMessages { 1,2,3 };

Source code for this post can be found here

Easy way to suppress code analysis warnings

2015-08-102016-01-30 TPodolak.NET, c#, code analysis

Everyone who has ever been using a code analysis knows that sometimes it is hard to follow the Microsoft coding guidelines and it is necessary to suppress some warnings. For me it always was a painful operation because I didn’t know any automated way of doing that. So basically I had to find the warning in the MSDN, copy category, code and other necessary stuff and then manually add appropriate attribute in code. Fortunately a friend of mine yesterday showed me a simple trick to generate this attribute with couple of mouse clicks. All you have to do is to right-click on warning message and choose Suppress Message context menu …

There are two options in there. The first option – In Source, will add attribute directly in the code

and the second one – In Suppression File, will create GlobalSuppressoins.cs file with assembly attribute which suppresses given warning in entire assembly

C# – testing internal classes

2015-07-262016-01-30 TPodolak.NET, c#, UnitTest

I am currently involved in writing library which will be used by couple of external teams. In that library we have a quite a lot classes which are only used internally and won’t be a part of public API. The natural way of keeping that code inaccessible for other assemblies is to use internal access modifier. However this makes the code also inaccessible directly for testing. Of course you can still test your internal code through public API but usually this is inconvenient and forces you to write a lot of additional code in test. This is particularly painful for me, because our build process requires 100% test coverage. Fortunately there is an easy way to make internal classes visible for certain assemblies without making them public. All you have to do is to use InternalsVisibleToAttribute and specify assembly name which is allowed to use code with internal access modifier. This attribute is most commonly added to AssemblyInfo.cs file. For example, assuming that my library is in TestingInternalClasses.Lib assembly and my tests are in TestingInternalClasses.Tests I should add

[assembly: InternalsVisibleTo("TestingInternalClasses.Tests")]

1	[assembly: InternalsVisibleTo("TestingInternalClasses.Tests")]

to AssemblyInfo.cs located in TestingInternalClasses.Lib project. However you can also use this attribute in a class definition file – just like that

using System;
using System.IO;
using System.Runtime.CompilerServices;
[assembly: InternalsVisibleTo("TestingInternalClasses.Tests")]

namespace TestingInternalClasses.Lib
{
    internal class VanillaSerializer : ISerializer
    {
        public Stream Serialize(object obj)
        {
            if (obj == null)
                throw new ArgumentNullException(nameof(obj));

            // rest of the code
            // ...
            // ...
        }

        public T Deserialize(Stream stream)
        {
            if (stream == null)
                throw new ArgumentNullException(nameof(stream));

            // rest of the code
            // ...
            // ...
        }
    }
}

using System;

using System.IO;

using System.Runtime.CompilerServices;

[assembly: InternalsVisibleTo("TestingInternalClasses.Tests")]

namespace TestingInternalClasses.Lib

{

internal class VanillaSerializer : ISerializer

{

public Stream Serialize(object obj)

{

if (obj == null)

throw new ArgumentNullException(nameof(obj));

// rest of the code

// ...

}

public T Deserialize(Stream stream)

{

if (stream == null)

throw new ArgumentNullException(nameof(stream));

// rest of the code

// ...

}

From now on I can easily test internal classes from TestingInternalClasses.Lib project in TestingInternalClasses.Tests. Source code for this post can be found here

.NET BLOG

.NET, C# blog

.NET

Solution-wide project properties with Directory.Build.props

1. Problem

2. Solution

RedisSessionStateProvider – unknown command ‘EVAL’

Abusing collection initializers

Easy way to suppress code analysis warnings

C# – testing internal classes