When accessing ParameterInfo.HasDefaultValue for a parameter of type System.DateTime, I
get an unexpected System.FormatException.
ParameterInfo.Attributes is correctly set to Optional | HasDefault.
If the parameter is of any other value type (e.g. decimal or some custom _struct_) the
property works as expected. There is something specific to DateTime in the implementation
of RuntimeParameterInfo.GetDefaultValueInternal() which is broken.
Code snippet to test:
``` c#
public void Usage()
{
var type = typeof (Foo);
var ctor = type.GetConstructors ()[0];
var para = ctor.GetParameters ()[0];
// This throws an exception...
Assert.True (para.HasDefaultValue);
}
static class Foo
{
public Foo(System.DateTime value = default (System.DateTime)) { }
}
```
Exception:

@sepidehMS do you think you can have a look at this issue?
I feel that these tests should be updated to include also the System.DateTime scenario.
@justinvp would you like to update the ParameterInfoTests in _corefx_ to cover this issue?
Is the described behavior from desktop .NET Framework? Or just general desire?
I have also run into this on .NET Core.
The DefaultValue and RawDefaultValue properties also throw the same FormatException when the ParameterInfo.ParameterType property is of type System.DateTime.
The only way I see to avoid it is having my reflection code step around DateTime parameters.
```c#
private static object GetDefaultValue(ParameterInfo parameter) {
return parameter.ParameterType == typeof(DateTime) ? default(DateTime) : parameter.DefaultValue
}
var defaultValues =
typeof(Foo)
.GetConstructors()[0]
.GetParameters()
.Select(GetDefaultValue)
.ToList();
```
Guid also has issues. The DefaultValue property on ParameterInfo is null when the default value is default(Guid). It doesn't throw when you access it, but it should be equivalent to Guid.Empty.
@karelz in my case, I want this to work both on the .NET Framework and on .NET Core.
Looks related to dotnet/runtime#18599
Next step: Root-cause (under debugger) and propose a fix.
@steveharter Given https://github.com/dotnet/coreclr/pull/17877 has been merged for quite some time now and the titular bug does not repro on .NET Core 3.1, maybe it is time to close this issue and remove it from the reflection roadmap for 5.0?
I'm going to resolve based on comment above.
I'm going to resolve based on comment above.
Most helpful comment
Looks related to dotnet/runtime#18599
Next step: Root-cause (under debugger) and propose a fix.