Is this an C# 4.0 compiler optional parameters bug?

I'm writing custom security attribute and got strange compiler behaviour... When I'm using the attribute at the same file, default parameter values works fine:

using System.Security.Permissions;

[System.Serializable]
sealed class FooAttribute : CodeAccessSecurityAttribute {
    public FooAttribute(SecurityAction action = SecurityAction.Demand) : base(action) { }
    public override System.Security.IPermission CreatePermission() { return null; }
}

[Foo] class Pr开发者_如何学Pythonogram {
    static void Main(string[] args) { }
}

But when I'm separating the code above into two files like that - file 1:

using System.Security.Permissions;

[System.Serializable]
sealed class FooAttribute : CodeAccessSecurityAttribute {
    public FooAttribute(SecurityAction action = SecurityAction.Demand) : base(action) { }
    public override System.Security.IPermission CreatePermission() { return null; }
}

And file 2:

[Foo] class Program {
    static void Main(string[] args) { }
}

I've got an compiler error:

Error: 'FooAttribute' does not contain a constructor that takes 0 arguments

This occurs only with the CodeAccessSecurityAttribute inheritors, looks very strange...

---

So I don't have an exact answer but I took it as far as I could looking into it. I think I understand why it happens when you inherit from CodeAccessSecurityAttribute and not SecurityAttribute. If you look at the IL generated when applying the Foo attribute when it inherits from CodeAccessSecurityAttribute it looks like this:

.permissionset demand = {class 'ConsoleApplication1.FooAttribute, ConsoleApplication1, Version=1.0.0.0, Culture=neutral' = {}}

When Foo inherits from SecurityAttribute it looks like this:

.custom instance void ConsoleApplication1.FooAttribute::.ctor(valuetype [mscorlib]System.Security.Permissions.SecurityAction) = ( 01 00 02 00 00 00 00 00 ) 

Clearly the CodeAccessSecurityAttribute drastically changes the IL generated by applying the attribute.

Looking at the IL more if we change the Foo declaration to be like as follows

[Foo(SecurityAction.Demand)]

We get the following IL:

.permissionset demand = {class 'ConsoleApplication1.FooAttribute, ConsoleApplication1, Version=1.0.0.0, Culture=neutral' = {}}

Its the same as it was when we did not specify the optional parameter. Further we can cause the error not just by splitting the attribute and the Program class into separate files we can cause it by rearranging the files in the class like this:

[Foo]
class Program
{

    static void Main(string[] args) {}


}

[System.Serializable]
sealed class FooAttribute : CodeAccessSecurityAttribute
{
    public FooAttribute(SecurityAction action = SecurityAction.Demand) : base(action) { }
    public override System.Security.IPermission CreatePermission() { return null; }
}

Even more interesting if we do the following with class Other and Other2 give the error but Program does not. Only the classes that come before Foo in the file will have the error

 [Foo]
 class Other
 {

 }

 [Foo]
 class Other2
 {
 }

 [System.Serializable]
 sealed class FooAttribute : CodeAccessSecurityAttribute
 {
      public FooAttribute(SecurityAction action = SecurityAction.Demand) : base(action) { }
      public override System.Security.IPermission CreatePermission() { return null; }        }

 [Foo]
 class Program
 {

  static void Main(string[] args) {}
 }

What this says to me is that there is a problem somewhere in the build process. I don't know enough about how Code Access Security works to put my finger on what the exact problem is. There has to be part of the process that looks at the CodeAccessSecurityAttributes and does something with attempting to apply the SecurityAction to the code. I assume it builds some sort of metadata for the assembly. It must do this in some sort of ordered way so that it doesn't see the optional parameter until after it has already passed the Program class. It then must use that metadata in some way during the build process and that is where you are seeing the failure. For any more detail we'll have to hope someone who knows the compiler i.e. Eric can shed some light on it. I'd submit it on connect.microsoft.com as one of the comments suggested as it seems like a bug caused by the order things are traversed.