Visual Studio and .NET Framework Home
DesignMode property doesn't behave as anticipated
as By Design
11/12/2007 5:53:30 PM
User(s) can reproduce this bug
The DesignMode property is frequently used to prevent the designer from running code the should only be executed at runtime. This works fine for both forms and user controls.
After adding a usercontrol to a form, the story changes. Opening the form in the IDE continues to produce the expected behavior, however the usercontrol now behaves as if it is runtime. The code that is supposed to be runtime-only is now executing in the designer anyway. This can lead to a number of performance issues and bizarre IDE errors, particularly when the code accesses a database (and has to wait for a connection to timeout) or tries to access an object (that may or may not have been instantiated).
Restructuring the code is always an option, however this type of code is almost impossible to find unless it does something that is either time consuming or error-prone at runtime. Most developers would simply overlook it as the cause of their IDE crashes because of the designmode block anyway.
Visual Studio 2005 (All Products and Editions) Service Pack 1
Windows XP Professional
Operating System Language
Steps to Reproduce
1) Create a form and a usercontrol designmode blocks ("if not designmode then...") in the new constructors.
2) Add message boxes in both blocks
Open each in the designer to confirm that the message boxes are not displayed.
3) Drop the usercontrol on the form
From this point on, the usercontrol's message box will be displayed every time the form is opened in the designer.
The message box from the usercontrol is displayed at design time.
The form should open in the designer without any messages since both message boxes are in designmode blocks. The code should only be executed at runtime.
TAP Code (if applicable)
You can indicate your satisfaction with how Microsoft handled this issue by completing this quick
3 question survey
to post a comment.
Please enter a comment.
on 5/27/2008 at 8:51 PM
Thanks for your feedback on the .NET Framework!
We are able to reproduce this issue in our environment and consider rolling in a fix to this issue in next release.
Many customers have found it useful to discuss issues like this in the forums (http://forums.microsoft.com/msdn/default.aspx?siteid=1) where Microsoft and other members of the community can suggest workarounds.
Please keep the feedback comming.
on 11/14/2007 at 8:29 AM
Thanks to Stephan Smetsers for the work-around. After overriding the designmode property in my base usercontrol to implement his code, everything behaves as expected.
on 11/13/2007 at 8:01 PM
Thanks for your feedback.
We are escalating this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Visual Studio Product Team
on 11/13/2007 at 5:50 PM
Thank you for your feedback. We are currently investigating. The investigation process normally takes 7-14 days. If this issue is urgent, please contact support directly (see http://support.microsoft.com).
If at any time your issue is closed unsatisfactorily, you may edit your issue via Connect and change the status to “Active.”
Visual Studio Product Team
to post a workaround.
Please enter a workaround.
on 4/22/2010 at 10:42 AM
Something less hackish (from the comments of this page http://decav.com/blogs/andre/archive/2007/04/18/1078.aspx ):
/// The DesignMode property does not correctly tell you if
/// you are in design mode. IsDesignerHosted is a corrected
/// version of that property.
public bool IsDesignerHosted
Control ctrl = this;
while (ctrl != null)
if ((ctrl.Site != null) && ctrl.Site.DesignMode)
ctrl = ctrl.Parent;
on 11/13/2007 at 12:59 AM
This problem also occurs when you want to have designtime/runtime specific behaviour in the constructor of a control. Because the Site property (that holds the DesignMode property) is assigned after the control is being created; one cannot use it in the constructor code.
I always use the following code to check whether we are in designmode:
if (System.Diagnostics.Process.GetCurrentProcess().ProcessName == "devenv")
// we are in designtime
// we are in runtime
A big advantage is that this code also works at places where one cannot get a reference to the Site property of a visual control.
Using this technique it is no longer required to pass the designmode-flag as a parameter in all methods that need this information.
Although this workaround works ok, I would like Microsoft to create a static .NET class holding the DesignMode property, so we can access this information at all times, at all places we like.
© 2014 Microsoft