Edición manual del archivo * .designer.cs

Soy consciente de que el archivo .designer.cs contiene datos generados por el diseñador de formularios visuales en Visual Studio. Sin embargo, tengo algunos métodos adicionales, que también quiero incluir en el archivo .designer.cs , porque estos son responsables del manejo de formularios de nivel inferior (por ejemplo, elementos de mi administrador de estado visual).

El método InitializeComponent dentro del archivo .designer.cs tiene un comentario que indica que se genera automáticamente y no debe ser modificado por el usuario. ¿Esta restricción se aplica solo a ese método o el archivo .designer.cs no debe ser editado por el usuario en absoluto? Me di cuenta de que, entre otros, contiene el método Dispose() , que el usuario podría querer modificar, lo que sugiere la primera opción. Sin embargo, quiero estar seguro.

Nunca debe modificar .designer.cs . Período. Sus cambios serán sobrescritos sin piedad.

Actualización: Para ser un poco más útil, C # desde v3 (VS 2008) ha incluido métodos parciales, que muchos diseñadores ahora usarán para permitirle implementar un comportamiento personalizado.

esta instrucción se aplica al archivo designer.cs completo. Como todo el código escrito en él se genera automáticamente.

No debe hacer ninguna modificación en este archivo, ya que puede recrearse en cualquier momento … esto eliminará sus métodos …

Si desea mantener el código separado del archivo de código del formulario, le sugiero que cree otro archivo que contenga una clase parcial donde puede poner todos esos métodos …

Espero eso ayude…

Creo que las otras respuestas se están simplificando demasiado.

En primer lugar, estoy totalmente de acuerdo en que casi siempre es una mala idea editar un archivo .designer, pero hay algunos casos en los que lo he hecho, siento que fue bueno y correcto, y no me quemé.

  1. Digamos que creo una etiqueta y accidentalmente hago doble clic. Diseñador crea un método en mi archivo .cs principal que luego elimino:

     private void label1_Click(object sender, EventArgs e) { } 

    Bueno, ahora el código no se comstackrá a menos que también elimine lo siguiente de mi archivo .designer:

     this.label1.Click += new System.EventHandler(this.label1_Click); 
  2. Con menos frecuencia, el orden en que se agregan cosas a un formulario o panel (¡o menú!) Es importante, y puede ser más fácil cambiar este orden en el código que en la GUI del Diseñador. En mi experiencia VS 2010 siempre retoma esto, actualiza la información de su GUI y vuelve a dibujar su vista previa. Solo recuerda enfocarte en los métodos Add() ; las variables de orden que se declaran generalmente no importan.

  3. Lo mismo ocurre si establece una propiedad que hace que se agregue una línea al archivo .designer, la eliminación de la línea se recoge rápidamente y Designer se actualiza. Tal vez sea más prudente / seguro usar la GUI para cambiar la propiedad, pero creo que eliminar la línea es más limpio.

  4. El código que no está dentro de esta región, #region Windows Form Designer generated code , solo se generará una vez. Es seguro moverse, y como otros han recomendado en otro lugar ( https://stackoverflow.com/a/6527072/1593924 ), mover el método Dispose(bool) en realidad puede tener mucho sentido, si lo estás modificando o agregar un método Dispose() que idealmente debería estar junto a Dispose(bool) .

     protected override void Dispose(bool disposing) { if (disposing && (components != null)) { components.Dispose(); } base.Dispose(disposing); 

DESCARGO DE RESPONSABILIDAD:

  1. Dicho esto, solo he probado VS 2010 Ultimate; su millaje puede variar entre 1 y 3, pero 4 debe ser seguro siempre que el diseñador sea una clase parcial con Dispose(bool) fuera de esa #region . También me aseguro de que la última buena versión de un archivo .designer se haya enviado al repository fuente antes de jugar con él.

  2. Al admitir haber seguido el patrón Dispose(bool disposing) , no pretendo promover ese enfoque. Parece haber buenas razones para simplemente usar Dispose() en la mayoría de los casos, y solo hacer más por los recursos no administrados, cada uno de los cuales se encapsula uno a uno en un objeto Desechable dedicado.

Dejar en paz a designer.cs no solo evita que se sobrescriban los cambios, sino que también ayuda a otros desarrolladores al decir que nada inesperado debe surgir. Dicho esto, hay al menos una excepción que puedo pensar y que es la mencionada por el autor de la publicación: extensión del método Dispose() . Que yo sepa, este código, una vez generado, no se sobrescribirá.

Sin embargo, en mi opinión, una solución mucho mejor es anular el método Dispose y llamar a la base. base.Dispose() , de modo que dejemos limpio a designer.cs.

Parcialmente la clase de formulario de diseñador es utilizada por Visual Studio para colocar todo el código necesario para construir el control.

El método InitializeComponent () no se puede sobrescribir: ¡es utilizado por el editor de diseño para representar una vista previa de tu formulario! Pruebe con un nuevo proyecto: cambie el tamaño de su formulario, agregue una etiqueta y un botón y cambie el nombre del método InitializeComponent () + vuelva a comstackr. ¡Tu formulario vuelve al tamaño predeterminado!

Si necesita llamar al código mediante la carga de formularios, simplemente anule el método virtual OnLoad (), si necesita llamar al código mostrando el formulario, anule el método virtual OnShown ().

Recuerde llamar al método base.Método () al principio de anular.

Espero que este pequeño mi experiencia pueda ayudar!