Any way to tell if you are in the designer from a static function?

[Michael Bray]

We have a control that is throwing an exception in a static initializer
when viewed in VS2005 designer as a subcontrol on a form. The exception
doesn't get thrown when designing the control itself, nor does it get
thrown in normal run-time, so it must have something to do with the fact
that the control is being loaded in the designer.

I know there is a 'this.DesignMode' available, but I can't use it from the
static contructor (since I don't have access to 'this'). I don't want to
simply catch and throw away the exception. Is there some other way that I
can determine if I'm in the designer?

-mdb

[Ben Voigt [C++ MVP]]

"Michael Bray" <mb*****************@you.figure.it.out.comwrote in message
news:Xn****************************@207.46.248.16. ..

We have a control that is throwing an exception in a static initializer
when viewed in VS2005 designer as a subcontrol on a form. The exception
doesn't get thrown when designing the control itself, nor does it get
thrown in normal run-time, so it must have something to do with the fact
that the control is being loaded in the designer.

I know there is a 'this.DesignMode' available, but I can't use it from the
static contructor (since I don't have access to 'this'). I don't want to
simply catch and throw away the exception. Is there some other way that I
can determine if I'm in the designer?

Fix the error instead of bypassing/working around it. You will have to load
Visual Studio itself in the debugger, to do that set the debug executable
for the control library to the visual studio exe and then debug with that
startup project. Visual Studio will start, and when you open the designer
and cause the exception, you'll get to debug through your type initializer
and see exactly what goes wrong.

>
-mdb

[Michael Bray]

"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in
news:u5**************@TK2MSFTNGP03.phx.gbl:

Fix the error instead of bypassing/working around it. You will have
to load Visual Studio itself in the debugger, to do that set the debug
executable for the control library to the visual studio exe and then
debug with that startup project. Visual Studio will start, and when
you open the designer and cause the exception, you'll get to debug
through your type initializer and see exactly what goes wrong.

I know exactly where the problem is, because the designer actually tells me
the exact file and line number that caused the control to not be able to
load (and thus I can't view the hosting control.)

But the real problem is that it is with an instance call to
Assembly.GetTypes(), so the exception is being thrown from the .NET
Framework itself... Obviously I can't fix that... so am I back to trying
to determine if I'm in design mode, or can you suggest anything else?

-mdb

[Chris Shepherd]

Michael Bray wrote:

We have a control that is throwing an exception in a static initializer
when viewed in VS2005 designer as a subcontrol on a form. The exception
doesn't get thrown when designing the control itself, nor does it get
thrown in normal run-time, so it must have something to do with the fact
that the control is being loaded in the designer.

I know there is a 'this.DesignMode' available, but I can't use it from the
static contructor (since I don't have access to 'this'). I don't want to
simply catch and throw away the exception. Is there some other way that I
can determine if I'm in the designer?

Look into LicenseManager.UsageMode
Chris.

[Michael Bray]

Chris Shepherd <ch**@nospam.chsh.cawrote in
news:#L**************@TK2MSFTNGP03.phx.gbl:

Look into LicenseManager.UsageMode

Ahhh sweet bliss. That works perfectly! Thanks much!

-mdb

[Chris Shepherd]

Michael Bray wrote:

Chris Shepherd <ch**@nospam.chsh.cawrote in
news:#L**************@TK2MSFTNGP03.phx.gbl:

>Look into LicenseManager.UsageMode

Ahhh sweet bliss. That works perfectly! Thanks much!

You are very welcome.

Chris.

[Ben Voigt [C++ MVP]]

"Michael Bray" <mb*****************@you.figure.it.out.comwrote in message
news:Xn****************************@207.46.248.16. ..

"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in
news:u5**************@TK2MSFTNGP03.phx.gbl:

>Fix the error instead of bypassing/working around it. You will have
to load Visual Studio itself in the debugger, to do that set the debug
executable for the control library to the visual studio exe and then
debug with that startup project. Visual Studio will start, and when
you open the designer and cause the exception, you'll get to debug
through your type initializer and see exactly what goes wrong.

I know exactly where the problem is, because the designer actually tells
me
the exact file and line number that caused the control to not be able to
load (and thus I can't view the hosting control.)

The information shown by the designer is worthless. I'd guess you're seeing
the TypeLoadException caught by the designer. It's the InnerException
property that contains the useful information. Run the design environment
in the debugger.

But the real problem is that it is with an instance call to
Assembly.GetTypes(), so the exception is being thrown from the .NET
Framework itself... Obviously I can't fix that... so am I back to trying
to determine if I'm in design mode, or can you suggest anything else?

No, the framework is catching an exception thrown inside your code and
wrapping it in a TypeLoadException.

>
-mdb

[Michael Bray]

"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in
news:e9**************@TK2MSFTNGP04.phx.gbl:

The information shown by the designer is worthless. I'd guess you're
seeing the TypeLoadException caught by the designer. It's the
InnerException property that contains the useful information. Run the
design environment in the debugger.

I wouldn't say it is worthless - it told me where the problem was... But
here's a strange twist - I can't get it to fail now. I was finally able to
at least get it to load in the designer by inserting a call to
System.Diagnostics.Debugger.Break() in the static method, but there is no
sign of the error that was causing the original issue, despite the fact
that the code hasn't changed. Unfortunately, neither was I able to notice
any factor which would have caused the original problem even as I debugged
the environment. And, once I was done debugging, my original VS process
was unresponsive and I had to kill it.

Interesting process, though.

-mdb