Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / New Users / January 2006

Tip: Looking for answers? Try searching our database.

Strange behavior with dynamic code compilation and VS.NET debuggin

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Mike Miller - 05 Jan 2006 00:31 GMT
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]
> > > >     }
> > > > }

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.