visual tutorial temas studio para mejores las iconos extensiones español configurar code brackethighlighter visual-studio gui-designer

tutorial - Cómo saber si el código de.NET está siendo ejecutado por el diseñador de Visual Studio



temas para visual studio code (24)

Al ejecutar un proyecto, su nombre se agrega con ".vshost".

Entonces, uso esto:

public bool IsInDesignMode { get { Process p = Process.GetCurrentProcess(); bool result = false; if (p.ProcessName.ToLower().Trim().IndexOf("vshost") != -1) result = true; p.Dispose(); return result; } }

Esto funciona para mi.

Recibo algunos errores en mi código cuando abro un formulario de Windows Forms en el diseñador de Visual Studio. Me gustaría ramificar en mi código y realizar una inicialización diferente si el diseñador abre el formulario que si se ejecuta de forma real.

¿Cómo puedo determinar en tiempo de ejecución si el código se está ejecutando como parte del diseñador que abre el formulario?


Aquí hay una forma flexible que se adapta al lugar de compilación, así como a si le importa o no en qué modo se encuentra.

string testString1 = "//bin//"; //string testString = "//bin//Debug//"; //string testString = "//bin//Release//"; if (AppDomain.CurrentDomain.BaseDirectory.Contains(testString)) { //Your code here }


Aqui hay otro más:

//Caters only to thing done while only in design mode if (App.Current.MainWindow == null){ // in design mode } //Avoids design mode problems if (App.Current.MainWindow != null) { //applicaiton is running }


Después de probar la mayoría de las respuestas aquí, lamentablemente nada funcionó para mí (VS2015). Así que agregué un pequeño giro a la respuesta de JohnV , que no funcionó de la caja, ya que DesignMode es una Propiedad protegida en la clase Control.

Primero hice un método de extensión que devuelve el valor de propiedad de DesignMode a través de Reflection:

public static Boolean GetDesignMode(this Control control) { BindingFlags bindFlags = BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Static; PropertyInfo prop = control.GetType().GetProperty("DesignMode", bindFlags); return (Boolean)prop.GetValue(control, null); }

y luego hice una función como JohnV:

public bool HostedDesignMode { get { Control parent = Parent; while (parent != null) { if (parent.GetDesignMode()) return true; parent = parent.Parent; } return DesignMode; } }

Este es el único método que funcionó para mí, evitando todo el desastre de ProcessName, y aunque la reflexión no se debe usar a la ligera, en este caso ¡hizo toda la diferencia! ;)

EDITAR:

También puede hacer que la segunda función sea un método de extensión como este:

public static Boolean IsInDesignMode(this Control control) { Control parent = control.Parent; while (parent != null) { if (parent.GetDesignMode()) { return true; } parent = parent.Parent; } return control.GetDesignMode(); }


El enfoque devenv dejó de funcionar en VS2012 ya que el diseñador ahora tiene su propio proceso. Aquí está la solución que estoy usando actualmente (la parte ''devenv'' queda allí para el legado, pero sin VS2010 no puedo probar eso) .

private static readonly string[] _designerProcessNames = new[] { "xdesproc", "devenv" }; private static bool? _runningFromVisualStudioDesigner = null; public static bool RunningFromVisualStudioDesigner { get { if (!_runningFromVisualStudioDesigner.HasValue) { using (System.Diagnostics.Process currentProcess = System.Diagnostics.Process.GetCurrentProcess()) { _runningFromVisualStudioDesigner = _designerProcessNames.Contains(currentProcess.ProcessName.ToLower().Trim()); } } return _runningFromVisualStudioDesigner.Value; } }


El enfoque más confiable es:

public bool isInDesignMode { get { System.Diagnostics.Process process = System.Diagnostics.Process.GetCurrentProcess(); bool res = process.ProcessName == "devenv"; process.Dispose(); return res; } }


Encontré la propiedad DesignMode con errores, al menos en versiones anteriores de Visual Studio. Por lo tanto, hice mi propio uso de la siguiente lógica:

Process.GetCurrentProcess().ProcessName.ToLower().Trim() == "devenv";

Es un truco, lo sé, pero funciona bien.


Es hack-ish, pero si está utilizando VB.NET y cuando se ejecuta desde Visual Studio My.Application.Deployment.CurrentDeployment será Nothing, porque aún no lo ha implementado. No estoy seguro de cómo verificar el valor equivalente en C #.


La forma más confiable de hacer esto es ignorar la propiedad DesignMode y usar su propia marca que se establece en el inicio de la aplicación.

Clase:

public static class Foo { public static bool IsApplicationRunning { get; set; } }

Program.cs:

[STAThread] static void Main() { Foo.IsApplicationRunning = true; // ... code goes here ... }

Luego, solo revisa la bandera donde la necesites.

if(Foo.IsApplicationRunning) { // Do runtime stuff } else { // Do design time stuff }


La propiedad Control.DesignMode es probablemente lo que estás buscando. Te dice si el padre del control está abierto en el diseñador.

En la mayoría de los casos, funciona muy bien, pero hay casos en los que no funciona como se esperaba. Primero, no funciona en el constructor de controles. En segundo lugar, DesignMode es falso para los controles de "nieto". Por ejemplo, DesignMode en los controles alojados en un UserControl devolverá falso cuando el UserControl esté alojado en un principal.

Hay una solución bastante fácil. Es algo parecido a esto:

public bool HostedDesignMode { get { Control parent = Parent; while (parent!=null) { if(parent.DesignMode) return true; parent = parent.Parent; } return DesignMode; } }

No he probado ese código, pero debería funcionar.


No estoy seguro de si ejecutar en modo de depuración cuenta como real, pero una forma fácil es incluir una declaración if en su código que compruebe System.Diagnostics.Debugger.IsAttached .


Para resolver el problema, también puede codificar de la siguiente manera:

private bool IsUnderDevelopment { get { System.Diagnostics.Process process = System.Diagnostics.Process.GetCurrentProcess(); if (process.ProcessName.EndsWith(".vshost")) return true; else return false; } }


Para saber si estás en "modo de diseño":

  • Los componentes (y controles) de Windows Forms tienen una propiedad DesignMode .
  • Los controles de Windows Presentation Foundation deben usar la propiedad adjunta IsInDesignMode .

Si creó una propiedad que no necesita en absoluto en el momento del diseño, puede usar el atributo DesignerSerializationVisibility y configurarlo en Hidden. Por ejemplo:

protected virtual DataGridView GetGrid() { throw new NotImplementedException("frmBase.GetGrid()"); } [DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)] public int ColumnCount { get { return GetGrid().Columns.Count; } set { /*Some code*/ } }

Detuvo mi bloqueo de Visual Studio cada vez que realicé un cambio en el formulario con NotImplementedException() y traté de guardarlo. En cambio, Visual Studio sabe que no quiero serializar esta propiedad, por lo que puede omitirla. Solo muestra una cadena extraña en el cuadro de propiedades del formulario, pero parece que es seguro ignorarla.

Tenga en cuenta que este cambio no tendrá efecto hasta que reconstruya.


Si tiene un formulario o control, puede usar la propiedad DesignMode:

if (DesignMode) { DesignMode Only stuff }


Tuve el mismo problema en Visual Studio Express 2013. Probé muchas de las soluciones sugeridas aquí pero la que funcionó para mí fue la respuesta a un hilo diferente , que repetiré aquí en caso de que el enlace se rompa alguna vez:

protected static bool IsInDesigner { get { return (Assembly.GetEntryAssembly() == null); } }


Usamos el siguiente código en UserControls y hace el trabajo. El uso exclusivo de DesignMode no funcionará en su aplicación que utiliza sus controles de usuario personalizados como lo señalaron otros miembros.

public bool IsDesignerHosted { get { return IsControlDesignerHosted(this); } } public bool IsControlDesignerHosted(System.Windows.Forms.Control ctrl) { if (ctrl != null) { if (ctrl.Site != null) { if (ctrl.Site.DesignMode == true) return true; else { if (IsControlDesignerHosted(ctrl.Parent)) return true; else return false; } } else { if (IsControlDesignerHosted(ctrl.Parent)) return true; else return false; } } else return false; }


Verifica la propiedad DesignMode de su control:

if (!DesignMode) { //Do production runtime stuff }

Tenga en cuenta que esto no funcionará en su constructor porque los componentes aún no se han inicializado.


if (System.ComponentModel.LicenseManager.UsageMode == System.ComponentModel.LicenseUsageMode.Designtime) { // Design time logic }


/// <summary> /// Whether or not we are being run from the Visual Studio IDE /// </summary> public bool InIDE { get { return Process.GetCurrentProcess().ProcessName.ToLower().Trim().EndsWith("vshost"); } }


/// <summary> /// Are we in design mode? /// </summary> /// <returns>True if in design mode</returns> private bool IsDesignMode() { // Ugly hack, but it works in every version return 0 == String.CompareOrdinal( "devenv.exe", 0, Application.ExecutablePath, Application.ExecutablePath.Length - 10, 10); }


System.ComponentModel.Component.DesignMode == true


System.Diagnostics.Debugger.IsAttached


using (System.Diagnostics.Process process = System.Diagnostics.Process.GetCurrentProcess()) { bool inDesigner = process.ProcessName.ToLower().Trim() == "devenv"; return inDesigner; }

Probé el código anterior (agregué una declaración de uso) y esto fallaría en algunas ocasiones para mí. Prueba en el constructor de un control de usuario colocado directamente en un formulario con el diseñador cargando al inicio. Pero funcionaría en otros lugares.

Lo que funcionó para mí, en todas las ubicaciones es:

private bool isDesignMode() { bool bProcCheck = false; using (System.Diagnostics.Process process = System.Diagnostics.Process.GetCurrentProcess()) { bProcCheck = process.ProcessName.ToLower().Trim() == "devenv"; } bool bModeCheck = (System.ComponentModel.LicenseManager.UsageMode == System.ComponentModel.LicenseUsageMode.Designtime); return bProcCheck || DesignMode || bModeCheck; }

Tal vez un poco exagerado, pero funciona, por lo que es lo suficientemente bueno para mí.

El éxito en el ejemplo mencionado anteriormente es bModeCheck, por lo que probablemente el DesignMode sea excedente.