Knowing when in design mode

Question

From within a class library, I'd like to know if it is being accessed during design mode as opposed to normal runtime.

I tried using System.ComponentModel.LicenseManager.UsageMode but it seemed to have a value of Runtime even when I was editing a form.

UPDATE: To clarify, I want to know if I am in design mode not from within a component, but rather from within a separate class that happens to be called by other items from within a form or control. I have a Utility class which is being called indirectly from a control and it is there that I need to know if I am in design mode or not.

Answer 1

I don't think Component.DesignMode will help in this case. What if the component or control is not loaded on the forms designer ? What you may try in this case is, create an enum that only sets the one value at normal startup which otherwise remains to another value by default. You can now check the value of the enum instance and decide if it's a design-time or runtime.

Answer 2

You can use Component.DesignMode to check this. However, be aware that this will always report false inside the constructor of the component, so it needs to be checked later. For details, see Debugging Design-Time Controls.

---

Edit in response to comments and edit:

Unfortunately, the LicenseMananger, as well as most other services which provide information about whether you're in Design Time (including Component.DesignMode and DesignerProperties.IsInDesignMode) as specifically geared at handling user interface elements. This makes sense, as they're intended to tell you when your item is being "designed" on a designer surface, which requires the component to be registered in the designer.

There is no single property that will cleanly tell you this from within an arbitrary class.

I could see two options, both of which are less than ideal:

1. Pass the required information into your class (ie: a Component or DependencyObject), so the methods above can be used to check for design-time access correctly. This is probably a more maintainable approach, and will likely work properly in more situations.
2. Resort to the "hack" of checking the current process name and looking for "devenv" - this is pretty awful, as it assumes Visual Studio only, relies on the executable name, etc... In general, I'll mention it because you'll find it with enough searching, but wouldn't recommend it, as it's very easy to circumvent and has many limitations and flaws.