Serializing enums as strings

Enumerations in C# are ints by default, which is fine most of the time. That said, there are situations where you’d want to store and retrieve them using their string names, especially when you are persisting them to a database. The string names make them more readable for one reason. For another, a re-ordering of the enums (caused inadvertently by the addition or removal of an entry) would change their int values, which can potentially break your data when reading them back from a database. Consider the following types – Model and Seasons.

enum Seasons
{
    Spring,
    Summer,
    Fall,
    Winter
}

class Model
{
    public string Name { get; set; } = String.Empty;

    public Seasons Season { get; set; }
}

If you serialize an instance of Model, you’d see the int value for the Season property.

var model = new Model
{
    Name = "Test Model",
    Season = Seasons.Fall,
};

var json  = JsonConvert.SerializeObject(model, Formatting.Indented);
Console.WriteLine(json);

Output looks like this.

{
  "Name": "Test Model",
  "Season": 2
}

It’s fairly easy to change this behavior though. Just add a JsonConverter attribute to the Season property.

class Model
{
    public string Name { get; set; } = String.Empty;

    [JsonConverter(typeof(StringEnumConverter))]
    public Seasons Season { get; set; }
}

Output is now nice and clean.

{
  "Name": "Test Model",
  "Season": "Fall"
}

You get the same behavior both when serializing and deserializing, and the latter is important when reading data back from a database.

How about if you have a collection of enums though? That’s simple too, just replace the JsonConverter attribute with the following JsonProperty attribute.

class Model
{
    public string Name { get; set; } = String.Empty;

    [JsonProperty(ItemConverterType = typeof(StringEnumConverter))]
    public List<Seasons> Seasons { get; set; } = new List<Seasons>();
}

Output is as expected.

{
  "Name": "Test Model",
  "Seasons": [
    "Fall",
    "Winter"
  ]
}

Advertisement

C# and the need (lack of) for move semantics

Someone recently asked me why C# does not support move semantics. Well, C# mostly deals with references, so you don’t have to to deal with copy constructors called on temporary objects. C# does support value types too but they are nearly always used for POD (plain old data) types. And when there is the need for a copy, what’s usually done is to implement an interface such as ICloneable. In the C# (and .NET) world, assignments are mostly reference copies. A reference variable takes the value of another reference variable. In summary, C# as a language does not have a need for move semantics.

Validating a bit flags enum value

This was recently asked in the Code Project Q/A forums, and while there were several responses posted, I think the following is succint and works well.

private static bool IsValidFlagValue<T>(int x) where T : struct
{
    int aggregate = Enum.GetValues(
      typeof(T)).Cast<int>().Aggregate((z, y) => z | y);
    return x <= aggregate && (aggregate & x) > 0;            
}

Note that it does not handle a case where the flag-enum has a 0-value. Here’s a version that does that too (a little less brief).

private static bool IsValidFlagValue<T>(int x) where T : struct
{
    var values = Enum.GetValues(typeof(T)).Cast<int>();
    if (x == 0 && values.Contains(0))
    {
        return true;
    }

    int aggregate = values.Aggregate((z, y) => z | y);
    return x <= aggregate && (aggregate & x) > 0;            
}

Using Socket.Disconnect(true)

Recently, someone asked this question on the CodeProject forums where the OP wondered if reusing the socket would mean he’d get the same client endpoint. This is the gist of my response to him.

Calling Socket.Disconnect(true) will internally result in Winsock’s DisconnectEx function being called with the TF_REUSE_SOCKET parameter.

From the docs:

Prepares the socket handle to be reused. When the DisconnectEx request completes, the socket handle can be passed to the AcceptEx or ConnectEx function.

So it’s only the socket handle that will be reused. This has nothing to do with your local endpoint.

Socket reuse is meant for fairly advanced use, where you know exactly what you are doing. It’s typically used in high performance heavy traffic TCP servers. The idea being that by reusing a socket, you save some time (the time that would normally have gone into allocating that socket and its resources). So what some server developers do is to have a pre-created socket pool that they pull sockets from as and when required.

So in my opinion, for a client side TCP application there is never a good reason to reuse a socket.

In short, always use Socket.Disconnect(false) unless you really know what you are doing.

For some reason, this is not so well documented and leads to a lot of confusion.

What about static indexers in C#?

Well, that’s not really possible but often people do ask if they can do this. Here’s a solution I recently gave someone which comes quite close which uses a singleton class instead of a static one:

class Test
{
    static Dictionary<int, string> map = new Dictionary<int, string>();

    private Test() { }

    private static Test instance = new Test();

    internal static Test Instance
    {
        get { return Test.instance; }
    }

    public string this[int i]
    {
        get
        {
            return map[i];
        }

        set
        {
            map[i] = value;
        }
    }
}

And here’s how you would use this:

Test.Instance[3] = "hello";
string s = Test.Instance[3];

DateTimePicker focus issue

The Winforms DateTimePicker has this odd behavior. If you set focus to either the day or the year, then when you tab out of the control and tab back in, focus is not restored to the month as it is by default (even if you reset or change the DateTime value for the control). There is no elegant way to resolve this as the control does not expose those inner controls in any way. You could send mouse/keyboard clicks to change focus, but it’s way simpler to use this arguably ugly hack. The code below will force the control to recreate itself and thus we reset focus to its default state.

var format = dateTimePicker1.Format;
dateTimePicker1.Format = DateTimePickerFormat.Custom;
dateTimePicker1.Format = format;

The trick is to force the control to internally reset itself by changing the Format and then setting it back to what it was. The code above assumes that it is something other than Custom.

Directory.GetFiles and extensions longer than 3 characters

This question pops up in various forums every once in a while. Essentially, someone would call Directory.GetFiles with something like “*.dat” and would be annoyed to find that *.dat matches .dat, .data, and even .date. Not what they wanted.

Unfortunately, this is by design. You have to do post-filtering to select just the files you want.

var files =  Directory.GetFiles(@"d:\tmp", "*.dat").Where(
    s => s.EndsWith(".dat"));

The reason it works this way is most likely for backward compatibility with the old 8.3 file system. And it’s really not a .NET restriction here, it’s an API restriction. Both FindFirstFile and FindNextFile have this behavior and it’s these API calls that are P/Invoked by Directory.GetFiles.

Generic arrays and casting to an object array

This question was posted recently on the CodeProject forums. The OP wanted to know why this code would not compile (I’ve simplified it):

private void FooInternal(object[] values)
{
}

private void Foo<T>(T[] values)
{
    FooInternal(values);
}

The error thrown is:

Error	2	Argument 1: cannot convert from 'T[]' to 'object[]'

The fix is to add a constraint:

private void Foo<T>(T[] values) where T:class
{
    FooInternal(values);
}

If you are wondering why that is needed, consider this code snippet:

struct S
{
}

static void Main(string[] args)
{
    object[] arr = new S[10];
}

That won’t compile either. The reason’s that each of those value type members need to be boxed into an object to get an object array, meaning it’s now a different array. Since that is not standard behavior for casts, the compiler will not automatically do that for you (which is a good thing). If you did it manually, this is what it’d look like:

object[] arr = new S[10].Cast<object>().ToArray();