I'm creating a system that turns a small script into a dll. I'm encountering a problem when I try to take a nullable value class and make it the default value of a parameter. The problem is that I need to create an instance of user selected nullable within the compiler and set it as the constant.
Unfortunately, whenever I use Activator.CreateInstance(NullableType)
(where NullableType is a created type from user input) I get null
as the return value. For example, simply executing:
object Test = Activator.CreateInstance(typeof(Nullable<int>));
Console.WriteLine(Test == null);
returns true. This ONLY happens with Nullables. A struct created in C#, even a generic one, is created fine. Heck, if I copy & paste nullable from DotNetReflector (and remove TypeDependencyAttribute, TargetPatchingOptOutAttribute, and ThrowHelper calls since I don't have access to those), it shows False above.
What is going on? Is there any other possible way to create a nullable when I don't know the generic parameters until run-time?
From this MSDN blog:
The problem has to do with how variables of
Nullable<T>
are boxed as explained by the blog post.The problem is in
ParameterBuilder.SetConstant
, notActivator.CreateInstance
.SetConstant
is a function for defining the default value of an optional parameter, and requires a concrete value be provided as the constant. For ref classes,null
is a valid concrete value, but for value classes prior to the creation ofNullable<>
,null
was not a valid value. How do you unboxnull
into anint
, for example? SoSetConstant
checked value types to see if the concrete value passed in as the constant wasnull
and throws anArgumentException
as a more descriptive error than theNullReferenceException
you'd get for unboxing a null into a value class.In the case of a
Nullable<>
,null
is now a valid concrete value for a value class.Nullable<>
itself is a value class, as seen withActivator.CreateInstance
, and unboxingnull
into aNullable<int>
has meaning. This is whereSetConstant
has a bug: it fails to take this into account and throws a 'descriptive' error for what isn't actually an error. In lieu of a bugfix from Microsoft, any call toSetConstant
with a nullNullable<>
will have to implement the behavior that's guarded by the incorrect conditional. This means digging intoParameterBuilder
's private methods and fields using reflection. Here's the code I made to handle just this case. The standardSetConstant
function should be used in situations that don't manifest the bug.I have reported the bug to Microsoft. They responded that it wouldn't be fixed in .NET 3.5, but it was added to the internal bug database.
UPDATE:
The bug has been fixed in .NET 4.0.
ParameterBuilder.SetConstant
now has a branch to theconstant == null
conditional that checks to see if a value type is a generic derived fromNullable<>
and only throws the exception if it is not.