debug custom assemblies

2 Jul 2006 7:30 AM

Dierk Droth

Hi,

My application provides a feature to load custom assemblies. The application
is build in release mode (/optimize). This is .NET 2.0.

As a user wants to debug his custom assembly be e.g. forcing a debugger
break ("Debugger.Break()"), he experiences that he can not inspect the value
of the public properties of any class, since they are optimized away:
"Cannot evaluate expression because the code of the current method is
optimized."

This is true even as the compiled assembly is built in debug mode using
"/optimize-".

I found something in docs, saying that the /optimize settings of the calling
assembly - which is my app built in release mode - take precedence.

What can be done to make the custom assembly fully debuggable?

Thanks in advance.

Dierk Droth

3 Jul 2006 12:34 PM

William Sullivan

Not sure, but have you considered the simple solution: Give developers of
the custom assemblies a "debug" (/optimize-) version of your program to debug
against? You don't have to give them the symbol (pdb) files for this to
work...

Show quote

"Dierk Droth" wrote:

> Hi,
>
> My application provides a feature to load custom assemblies. The application
> is build in release mode (/optimize). This is .NET 2.0.
>
> As a user wants to debug his custom assembly be e.g. forcing a debugger
> break ("Debugger.Break()"), he experiences that he can not inspect the value
> of the public properties of any class, since they are optimized away:
> "Cannot evaluate expression because the code of the current method is
> optimized."
>
> This is true even as the compiled assembly is built in debug mode using
> "/optimize-".
>
> I found something in docs, saying that the /optimize settings of the calling
> assembly - which is my app built in release mode - take precedence.
>
> What can be done to make the custom assembly fully debuggable?
>
> Thanks in advance.
>
> Dierk Droth
>

3 Jul 2006 1:07 PM

Dierk Droth

Thanks for your reply.

Yes, I'm aware of this option. However this is quite cumersome, since
a) I had to provide a debug version ;-)
b) the user had to restart the app using this debug version. Note: my app
provides .NET scripting, so the user can edit, compile and run within the
app. But then had to start to debug.

I also considered providing a GetXXX() method for any XXX property, since
the optimizer probably won't optimize these methods away (have not yet tested
though). However, clumpsy as well ...

Any other ideas?

Thanks

Dierk Droth

Show quote

"William Sullivan" wrote:

> Not sure, but have you considered the simple solution: Give developers of
> the custom assemblies a "debug" (/optimize-) version of your program to debug
> against? You don't have to give them the symbol (pdb) files for this to
> work...
>
> "Dierk Droth" wrote:
>
> > Hi,
> >
> > My application provides a feature to load custom assemblies. The application
> > is build in release mode (/optimize). This is .NET 2.0.
> >
> > As a user wants to debug his custom assembly be e.g. forcing a debugger
> > break ("Debugger.Break()"), he experiences that he can not inspect the value
> > of the public properties of any class, since they are optimized away:
> > "Cannot evaluate expression because the code of the current method is
> > optimized."
> >
> > This is true even as the compiled assembly is built in debug mode using
> > "/optimize-".
> >
> > I found something in docs, saying that the /optimize settings of the calling
> > assembly - which is my app built in release mode - take precedence.
> >
> > What can be done to make the custom assembly fully debuggable?
> >
> > Thanks in advance.
> >
> > Dierk Droth
> >