When I run the following code I would suspect a null reference exception to
be thrown:
param1 = null;
int x = param1.Length;
However, when I compile this code dynamically into a class and method a null
reference exception is ONLY thrown if the debugger is attached???? Otherwise
no exception is thrown. Can someone please explain this? I included the
code below - create a console application and overwrite the existing class
with the code below.
CODE TO REPRODUCE:
using System;
using System.CodeDom.Compiler;
using System.Reflection;
using Microsoft.CSharp;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Assembly a = CreateAssembly();
object o = a.CreateInstance("ConsoleApplication1.TestClass");
MethodInfo info = o.GetType().GetMethod("RunMe");
info.Invoke(o, new object[] { null });
}
private static Assembly CreateAssembly()
{
string src = @"
namespace ConsoleApplication1
{
using System;
public class TestClass
{
public virtual void RunMe(string param1)
{
int x = param1.Length;
}
}
}";
CodeDomProvider provider = new CSharpCodeProvider();
CompilerParameters compilerParameters = new CompilerParameters();
compilerParameters.GenerateInMemory = true;
compilerParameters.IncludeDebugInformation = false;
compilerParameters.GenerateExecutable = false;
CompilerResults results =
provider.CompileAssemblyFromSource(compilerParameters,
src);
return results.CompiledAssembly;
}
}
}
Mike Miller - 05 Jan 2006 00:37 GMT
Forgot to mention it: VS.NET 2005 / .NET 2.0
> When I run the following code I would suspect a null reference exception to
> be thrown:
[quoted text clipped - 57 lines]
> }
> }
Jon Skeet [C# MVP] - 05 Jan 2006 04:11 GMT
> When I run the following code I would suspect a null reference exception to
> be thrown:
[quoted text clipped - 7 lines]
> code below - create a console application and overwrite the existing class
> with the code below.
<snip>
Interesting. It looks like optimization is deciding that as you don't
use the value of x, it shouldn't bother calculating it. Definitely
looks like a bug to me.

Signature
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Richard Hale Shaw (C# MVP) - 05 Jan 2006 23:40 GMT
Try changing the following line (change "false" to "true"):
compilerParameters.IncludeDebugInformation = true;
And you'll get the usual exception information when the program aborts.
Regards,
RHS
> When I run the following code I would suspect a null reference exception to
> be thrown:
[quoted text clipped - 57 lines]
> }
> }
Mike Miller - 06 Jan 2006 04:23 GMT
So the behavior is suppose to be different??? This doesn't make any sense -
so when I compile with debugging information I get different behavior then
when I compile without it? Isn't optimization a change in performance, not
behavior? Thanks for the response, I guess what I am getting at is how does
one troubleshoot optimized code if when you debug it the problem disappears?
Maybe we should go back to using lots of write lines instead of the debugger
;)
> Try changing the following line (change "false" to "true"):
>
[quoted text clipped - 65 lines]
> > }
> > }
Richard Hale Shaw (C# MVP) - 06 Jan 2006 12:03 GMT
Mike,
Sorry to have been terse before. Ben Day suggested I take a look at this for
you.
I think someone else suggested that it was optimization related; I noticed
that the you'd turned off debugging in the generated assembly and noticed
that the results changed considerably.
Wanted to make you at least aware of that, since it did generate all the
exception information that way.
BTW--I find it easier to debug CodeDom related problems by having the
assembly written to disk and then executing it, so you can run it standalone
if appropriate.
Hope this helps.
Regards,
RHS
> So the behavior is suppose to be different??? This doesn't make any sense -
> so when I compile with debugging information I get different behavior then
[quoted text clipped - 73 lines]
> > > }
> > > }
Mike Miller - 06 Jan 2006 18:33 GMT
I appreciate you taking the time to answer and thanks for the information -
it was helpful at least for hacking around the problem.
> Mike,
> Sorry to have been terse before. Ben Day suggested I take a look at this for
[quoted text clipped - 92 lines]
> > > > }
> > > > }