Null-propagation operator and conditional statements

2017-12-17 TPodolakc#

This post is just a quick reminder for me to put a bit more attention to conditional statements combined with a null-propagation operator. Nothing too fancy but I tend to overlook this when doing code review.
Starting from C# 6 we can simplify accessing members of an object which might be null thanks to ?. operator. For my perspective it is particularly useful within if statements, however, you have to be aware of how compiler rewrites the code under the hood otherwise, it is easy to introduce a bug. Consider following scenario

public Flight GetFirstPossibleFlight(Availability availability)
{
    if (availability.Flights?.Any() == false)
    {
       return null;
    }
            
    // more magic in here
     return availability.Flights.First();
}

public Flight GetFirstPossibleFlight(Availability availability)

{

if (availability.Flights?.Any() == false)

{

return null;

}

// more magic in here

return availability.Flights.First();

}

At a glance everything seems to be ok, we make sure that Flight collection is not accessed if it is null, however simple test shows that this method has a bug.

[Fact]
public void GetFirstPossibleFlight_ReturnsNull_WhenFlightsCollectionIsEmpty()
{
    var availability = new Availability
    {
        Flights = null
    };
            
    var subject = new AvailabilityScanner();

    var result = subject.GetFirstPossibleFlight(availability);

    result.Should().BeNull();
}

[Fact]

public void GetFirstPossibleFlight_ReturnsNull_WhenFlightsCollectionIsEmpty()

{

var availability = new Availability

{

Flights = null

};

var subject = new AvailabilityScanner();

var result = subject.GetFirstPossibleFlight(availability);

result.Should().BeNull();

}

We protected the code from NullReferenceException in if statement, however we failed on the return statement. This happens because our original code is rewritten by compiler as follows

public Flight GetFirstPossibleFlight(Availability availability)
{
    List<Flight> expr_07 = availability.Flights;
    bool flag = expr_07 != null && !expr_07.Any<Flight>();
    Flight result;
    if (flag)
    {
        result = null;
    }
    else
    {
        result = availability.Flights.First<Flight>();
    }
    return result;
}

public Flight GetFirstPossibleFlight(Availability availability)

{

List<Flight> expr_07 = availability.Flights;

bool flag = expr_07 != null && !expr_07.Any<Flight>();

Flight result;

if (flag)

{

result = null;

}

else

{

result = availability.Flights.First<Flight>();

}

return result;

}

Now it is clearly visible that we have to satisfy both of the conditions in order to return null. Fortunately, you still can use one-liner and have a bug-free code, the one thing which is needed is an additional null-coalescing operator in the if statement.

public Flight GetFirstPossibleFlight(Availability availability)
{            
    if ((availability.Flights?.Any() ?? false) == false)
    {
        return null;
    }
            
    // more magic in here
    return availability.Flights.First();
}

public Flight GetFirstPossibleFlight(Availability availability)

{

if ((availability.Flights?.Any() ?? false) == false)

{

return null;

}

// more magic in here

return availability.Flights.First();

}

Now the compiler will rewrite the code in a following way

public Flight GetFirstPossibleFlight(Availability availability)
{
    List<Flight> expr_07 = availability.Flights;
    bool flag = expr_07 == null || !expr_07.Any<Flight>();
    Flight result;
    if (flag)
    {
        result = null;
    }
    else
    {
        result = availability.Flights.First<Flight>();
    }
    return result;
}

public Flight GetFirstPossibleFlight(Availability availability)

{

List<Flight> expr_07 = availability.Flights;

bool flag = expr_07 == null || !expr_07.Any<Flight>();

Flight result;

if (flag)

{

result = null;

}

else

{

result = availability.Flights.First<Flight>();

}

return result;

}

Notice that AND operator was replaced with OR operator, resulting in code safe from NullReferenceException.
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

WCF – exposing metadata over TCP

2015-06-282016-01-30 TPodolakc#, WCF

I think that everyone who has ever been working with WCF knows that we can enable metadata exchange by adding ServiceMetadataBehavior to App.config file

<behaviors>
     <serviceBehaviors>
       <behavior>
         <serviceMetadata httpGetEnabled="true"></serviceMetadata>
       </behavior>
     </serviceBehaviors>
</behaviors>

</behavior>

</serviceBehaviors>

</behaviors>

Up until yesterday the build in solution works fine for me. However recently I’ve had to expose metadata over TCP protocol. ServiceMetadataBehavior doesn’t have something like TcpGetEnabled property so in order to expose metadata over other protocols (in my case TCP) it is necessary to add custom MEX endpoint.

<system.serviceModel>
    <services>
          <service name="AudioLib.Services.AudioService">
            <endpoint address="AudioService/MEX" binding="mexTcpBinding" contract="IMetadataExchange">
    <!-- application endpoints -->
            <host>
              <baseAddresses>
                <add baseAddress="net.tcp://localhost:8080"></add>
              </baseAddresses>
            </host>
          </endpoint>
        </service>
    </services> 
    <!-- rest of the config -->
</system.serviceModel>

<system.serviceModel>

<host>

</baseAddresses>

</host>

</endpoint>

</service>

</services>

</system.serviceModel>

The endpoint configuration has to have a specific binding – in my case mexTcpBinding (there are of course MEX bindings available for other protocols). What is more, the contract has to be set to IMetadataExchange. The address value is up to us, we can use full blown address as well as leverage base address. At this point if we run service we will get the exception

Even though we added custom endpoint for metadata exchange we still have to use ServiceMetadataBehavior. This time however we can skip httpGetEnabled property

<!-- rest of the config -->
<serviceBehaviors>
        <behavior>
          <serviceMetadata httpgetenabled="true"></serviceMetadata>
        </behavior>
</serviceBehaviors>
<!-- rest of the config -->

</behavior>

</serviceBehaviors>

From now on we can access metadata over TCP

Source code for this post can be found here

C# – dynamic type can be useful

2015-05-162016-01-30 TPodolak.NET 4.0, c#, dynamic

I am not a big fan of dynamic type in C#, however there are certain situations in which it can be handy. Let’s assume that we have following piece of code (which I encounter quite often at my work)

public abstract class Weapon
{
    //some properties
}

public class Gun : Weapon
{
     //some properties
}

// more derived types

var weaponService = new WeaponService();
IList<TransferObjects.Weapon> data = weaponService.GetWeapons();
List<Models.Weapon> weapons = data.Select(WeaponConverter.Convert).ToList();

public abstract class Weapon

{

//some properties

}

public class Gun : Weapon

{

//some properties

}

// more derived types

var weaponService = new WeaponService();

IList<TransferObjects.Weapon> data = weaponService.GetWeapons();

List<Models.Weapon> weapons = data.Select(WeaponConverter.Convert).ToList();

As you can see we have to convert DTO objects into “normal” objects using some kind of converter. This is not a problematic when you can use some auto-mappings libraries (Automapper,FastMapper) however I am not allowed to do that in a company I work for. So the question is how to write WeaponConverter.Convert method in some elegant way. The obvious way (but definitely not elegant) is just to use lots of “if” statements

public static Models.Weapon ConvertOld(TransferObjects.Weapon weapon)
{
    if (weapon == null)
        return null;
        
    if (weapon is TransferObjects.Gun)
        return ConvertInternal((TransferObjects.Gun) weapon);
        
    if (weapon is TransferObjects.Sword)
        return ConvertInternal((TransferObjects.Sword) weapon);
        
    throw new ArgumentException("Unknown weapon", nameof(weapon));
}
// ConvertInternal implementation goes here for every derived type

public static Models.Weapon ConvertOld(TransferObjects.Weapon weapon)

{

if (weapon == null)

return null;

if (weapon is TransferObjects.Gun)

return ConvertInternal((TransferObjects.Gun) weapon);

if (weapon is TransferObjects.Sword)

return ConvertInternal((TransferObjects.Sword) weapon);

throw new ArgumentException("Unknown weapon", nameof(weapon));

}

// ConvertInternal implementation goes here for every derived type

But this is really ugly, much better idea (at least from my point of view) is to leverage dynamic keyword introduced in .NET 4. Thanks to it our Convert method can be reduced to this

public static Models.Weapon Convert(TransferObjects.Weapon weapon)
{
    return weapon != null ? ConvertInternal((dynamic)weapon) : null;
}

// ConvertInternal implementation goes here for every derived type

public static Models.Weapon Convert(TransferObjects.Weapon weapon)

{

return weapon != null ? ConvertInternal((dynamic)weapon) : null;

}

// ConvertInternal implementation goes here for every derived type

Source code for this post can be found here

.NET BLOG

.NET, C# blog

c#

Null-propagation operator and conditional statements

Easy way to suppress code analysis warnings

C# – testing internal classes

WCF – exposing metadata over TCP

C# – dynamic type can be useful