The behavior of FlagsAttribute is probably not what you suspect

Let’s create another enum:

enum Foo
{
    A,
    B,
    C,
    D
}

You add the FlagsAttribute:

[FlagsAttribute]
enum Foo
{
    A,
    B,
    C,
    D
}

Meaning you want to use the Enum as a Flag, so you can combine them. For example:

Foo foo = Foo.B | Foo.C | Foo.D;

Later, you pass this value on, and you want to test for the presence of Foo.A:

// foo is the same foo as previous 
var hasA = (foo & Foo.A) == Foo.A;

Console.WriteLine("hasA: {0}", hasA);

You think that hasA is false. Is it? It’s not:

Does foo include Foo.A?
Does foo include Foo.A?

How come? Applying the FlagsAttribute doesn’t DO anything with the generated constants for your enum members.

As per the documentation you still need to do it yourself:

Define enumeration constants in powers of two, that is, 1, 2, 4, 8, and so on. This means the individual flags in combined enumeration constants do not overlap.

So we update our enum:

[FlagsAttribute]
enum Foo
{
    A = 1,
    B = 2,
    C = 4,
    D = 8
}

and then we test our code again:

Foo foo = Foo.B | Foo.C | Foo.D;
var hasA = (foo & Foo.A) == Foo.A;

Console.WriteLine("hasA: {0}", hasA);

And the result is:

Does foo include Foo.A? It does!
Does foo include Foo.A? It does!

Success!

Hope you have a good one,

-Kristof

PS: please not that I should have added a None enum member, as per the documentation:

Use None as the name of the flag enumerated constant whose value is zero. You cannot use the None enumerated constant in a bitwise AND operation to test for a flag because the result is always zero.

Windows Server 2008 R2 domain controller couldn’t contact the outside network

Network setup:

  • A private network (*.1, *.3, *.4, …)
  • A public network (other range)
  • One server in between to provide routing services (network card in both VLANs) from the private to the public (*.2 on the private)

In the private network there were multiple servers whose gateway (*.2) were all set to the router. They all could contact the public network.

Except for one, the domain controller.

We compared the network configuration, and all was the same. After investigating we looked at the routes, and it seemed that the domain controller had to routes with network destination 0.0.0.0 and netmask 0.0.0.0. On one the gateway was the *.1, on the other one the gateway was *.2,even though it should only be using the *.2.

The weird thing was that the server itself was the *.1. Because the route to *.1 was higher on the list (same metric though…), it couldn’t route it’s request, because it thought it was the router itself. We didn’t see this in the network configuration of its network card (weird2):

Duplicate route

By deleting the route manually the request flowed as normal to the outside. (with netsh).

We think this had to do with the server initially having the *.2 as network address, then upgrading it to a DC, and then changing the IP to *.1.

Hope this is helpful.

-Kristof