Dce2 introduccion win_forms

Notas del editor

• #3: En el presente curso de entrenamiento se introduce al desarrollo de aplicaciones Windows, presentando .NET 2.0 como framework de desarrollo, para que el alumno pueda conocer y aprovechar al máximo el potencial de esta tecnología. Esta sección incluye tanto las características nuevas, como aquellas que han sido modificadas, y permite aplicar lo aprendido en los cursos anteriores del programa Desarrollador 5 Estrellas. Acompañan al presente material teórico una serie de ejercicios de ejemplo y guías, desarrollados en Visual C# y en Visual Basic .NET, que sirven de apoyo al alumno en el proceso del aprendizaje. Se recomienda la realización de los ejercicios propuestos, la lectura del material adicional de referencia asi como también la lectura y ejecución de los ejemplos para lograr una formación completa en el tema.
• #8: Las clases proporcionadas por el framework .NET incluyen una gran cantidad para la creación y administración de aplicaciones Windows, y como con el resto de los objetos de .NET, los objetos de Windows Forms pueden ser heredados y de esa manera extender su funcionalidad. Si no es suficiente con los controles que expone el NameSpace System.Windows.Forms y los NameSpaces asociados, es posible crear nuestras propias clases que hereden de algunas de la propuestas por las librerías de clases base y así lograr la funcionalidad requerida.
• #9: Los formularios no escapan al modelo de objetos del framework .NET. Un formulario Windows no es más que una instancia de la clase System.Windows.Forms.Form . Puede crearse utilizando cualquier editor de texto, pero es obviamente mucho más sencillo hacerlo utilizando el diseñador de formularios de Visual C# Express Edition o Visual Basic .NET Express Edition. Estas son las herramientas que se utilizarán para el armado de los ejercicios y guías paso a paso de este módulo. Para una mayor información, por favor consulte el material de referencia del módulo.
• #10: Al crear un proyecto de aplicación Windows, además de generarse automáticamente un formulario por defecto, se crean una serie de archivos y clases que complementan la aplicación. Entre ellos tenemos: Program.cs (o .vb): Contiene una clase estática ( Program ) con un método Main() que constituye el punto de entrada de la aplicación. AssemblyInfo.cs (o .vb): Es parte de cada proyecto y sirve para personalizar datos importantes acerca del ensamblado (Assembly) Settings.cs (o .vb): Es el encargado del acceso a la configuración de usuario de la aplicación (se profundizará más adelante en esta presentación) References: Por defecto ya se incluyen algunas referencias a otros assemblies de .NET. Desde esta carpeta se pueden agregar o quitar las que se requieran para el caso particular.
• #12: El diseñador de formularios es básicamente un potente generador de código. Cada vez que se establece un valor para una de las propiedades del formulario, se coloca un nuevo control, o se asocia un método manejador a alguno de los eventos de esos controles o del propio formulario, el diseñador está escribiendo una o varias líneas de código C# o Visual Basic .NET que reflejan esos cambios. Este código está encerrado en una región (#region) llamada Windows Form Designer generated code . Esto es así desde las primeras versiones de .NET, pero en la versión 2.0 se lleva un paso más allá. Valiéndose del concepto de Partial Class, el código generado ahora está separado en un archivo físico diferente cuyo nombre respeta la sintaxis [NombreFormulario].Designer.cs (o .vb).
• #14: Como se mencionaba anteriormente, a través de las propiedades y métodos del objeto Form definiremos la forma en que se va a comportar un formulario. Estableciendo en true el valor de la propiedad IdMdiContainer estaremos creando una interfaz de múltiples documentos (MDI). Si un formulario MDI se cierra, se cerrarán previamente todos los formularios hijos (child) que de él dependan. Para visualizar un formulario como hijo de un formulario contenedor MDI, se debe asignar una referencia a ese formulario padre a través de la propiedad MdiParent. A través la propiedad AutoValidate (que el objeto form hereda de la clase ContainerControl y que es nueva en .NET 2.0) se puede controlar la forma en que se comportan los controles al momento de perder el foco y permite controlar la validación de los datos que contienen.
• #15: Siguiendo con las propiedades del formulario, existen algunas de ellas que reciben datos que son objetos .NET en sí mismos. Esto nos da una mayor flexibilidad, ya que a una misma propiedad de diferentes controles es posible asignarles una referencia a un mismo objeto, por ejemplo: Código en C# Font fuenteGrande = new Font(“Arial”, 24); Font fuenteChica = new Font(“Arial”, 12); this.Font = fuenteGrande; this.botonAceptar.Font = fuenteChica; this.botonCancelar.Font = fuenteChica ; Código en VB.NET Dim fuenteGrande As New Font(“Arial”, 24) Dim fuenteChica As New Font(“Arial”, 12) Me.Font = fuenteGrande Me.botonAceptar.Font = fuenteChica Me.botonCancelar.Font = fuenteChica
• #16: Visualizar un formulario especificando su owner (dueño), usando la sobrecarga correspondiente del método Show(), permite imitar el comportamiento típico que, por ejemplo, tienen las ventanas contenedoras de herramientas (toolbox) de los programas de edición de imágenes. Estas tipo de ventanas, sin importar que otro formulario de la aplicación esté activo (tenga foco), se muestran siempre por sobre el resto de las demás. Los cuadros de diálogos (aquellas ventanas visualizadas en forma modal ) no permiten continuar con el proceso hasta que el usuario responda a sus requerimientos y los cierre, ya que no dejan que ninguna otra ventana de esa misma aplicación tome foco.
• #17: Cada evento administra una colección de métodos manejadores que responderán a dicho evento. Es por esto que se puede vincular varios métodos al mismo evento. El orden en que se irán invocando cada uno de estos métodos es el mismo orden en que fueron vinculados al evento. Vincular diferentes eventos (que pueden pertenecer también a diferentes objetos) a un mismo método manejador, permite conseguir una funcionalidad centralizada. Mediante el objeto sender que reciben como parámetro los manejadores, es posible saber qué objeto disparó ese evento. Deberá considerarse que abusar de esta técnica, donde un mismo método se encarga de controlar eventos disparados por fuentes muy diferentes, puede llegar a generar código difícil de mantener.
• #18: Estos ejemplos (en C# y Visual Basic .Net) demuestran las dos técnicas para manejar eventos vistas en la diapositiva anterior: - Varios manejadores para un mismo evento. En este caso el evento Click de un formulario es atendido por dos métodos: MetodoManejador1 y MetodoManejador2; estos métodos pertenecen a la colección de métodos que puede administrar el evento. - Un mismo manejador para diferentes eventos. En este caso los eventos Load y Activated de un formulario, son atendidos por el mismo método, así es posible tener un control centralizado.
• #19: El modelo de eventos que expone el objeto Form es muy amplio, por lo que inicialmente hay que conocer bien al momento de decidir qué evento vamos a suscribir para escribir nuestro código. Algunos de los eventos detallados se disparan más de una vez durante el ciclo de vida de un formulario. El ciclo de vida de un formulario es el tiempo en que la instancia del formulario permanece en memoria. Pongamos como ejemplo el evento Activated . Este evento se dispara cuando el formulario se vuelve activo (recibe foco). Si escribiéramos en el manejador de ese evento código que muestre un cuadro de diálogo modal (por ejemplo un MessageBox, que se verá más adelante en esta presentación), al momento de cerrar ese diálogo modal se dispararía nuevamente el evento Activated provocando una iteración infinita. Otro de los eventos que se dispara más de una vez durante el ciclo de vida del formulario es el evento Paint . El evento Load también es un buen punto para la inicialización de los diferentes controles que se encuentren en el formulario, tener en cuenta que en este punto todos los controles están inicializados pero el formulario es aún invisible. El evento FormClosing es el punto ideal para mostrar un mensaje de confirmación al usuario que permita cancelar el cierre del formulario. El evento FormClosed es utilizado para la liberación de recursos que hubieran podido inicializarse en el evento New.
• #20: Como se indica en la diapositiva, a través de los argumentos que recibe el manejador de los eventos relacionados con el Mouse (argumentos de la clase MouseEventArgs ) se recibe gran cantidad de información. La propiedad Buttons contiene un enumerado que puede controlar hasta 5 botones. La propiedad Clicks permite conocer la cantidad de clicks que se produjeron desde el evento anterior. La propiedad “Delta” permite controlar el uso de la rueda del mouse. Un valor positivo indica que la rueda se movió hacia delante. Un valor negativo indica movimiento hacia atrás, por ejemplo: Código en C# private void Form1_MouseMove(object sender, MouseEventArgs e) { if (e.Delta > 0) MoverArriba(); else MoverAbajo(); } Código en VB.NET Private Sub Form1_MouseMove(ByVal sender As System.Object, _ ByVal e As System.Windows.Forms.MouseEventArgs) _ Handles MyBase.MouseMove If e.Delta > 0 Then MoverArriba() Else MoverAbajo() End If End Sub
• #21: Como cualquier otro manejador de eventos del framework .NET, aquellos relacionados con el manejo del teclado reciben dos parámetros: Sender: Es una referencia al objeto que disparó el evento. e: Es un objeto de tipo KeyPressEventArgs que expone dos propiedades: KeyChar : Es el caracter correspondiente a la tecla presionada Handled : Es un valor de tipo lógico (boolean) al cuál se le puede asignar “true” para informarle al motor de procesamiento de teclado que la tecla ha sido controlada y que el evento ha sido procesado. Ejemplo: Este código utiliza el evento KeyPress de un control TextBox para convertirlo en un control que sólo acepta números. Esto se consigue verificando el código de la tecla presionada. Código en C# private void txtNumero_KeyPress(object sender, KeyPressEventArgs e) { if (!char.IsDigit(e.KeyChar) || char.IsControl(e.KeyChar)) { e.Handled = true; } } Código en VB.NET Private Sub TextBox1_KeyPress(ByVal sender As System.Object, _ ByVal e As System.Windows.Forms.KeyPressEventArgs) _ Handles TextBox1.KeyPress If Not (Char.IsDigit(e.KeyChar) Or Char.IsControl(e.KeyChar)) Then e.Handled = True End If End Sub
• #22: En el diseño de formularios es fundamental conseguir una buena navegabilidad entre los diferentes controles de ese formulario. En procesos donde el ingreso de datos por parte del usuario es intensivo, hacer un mal uso del manejo del foco en los controles puede derivar en el fracaso de la aplicación. Se dice que un control tiene foco cuando es el control que está activo y es quien recibe los mensajes que envía el sistema operativo al presionar una tecla. En el caso de un cuadro de texto (TextBox), el que tiene foco será el que tenga el cursor de escritura (I). El diseñador de formularios dispone de una muy práctica herramienta para establecer el orden de tabulación de los controles del formulario (el orden en el que los controles irán tomando foco al presionar la tecla Tab ). Teniendo abierto el formulario con el diseñador, si seleccionamos la opción Tab Order del menú View, aparecerá en la esquina superior izquierda de cada uno de los controles una etiqueta de color azul con un número. Ese número es el que determina el orden. Haciendo click con el mouse en cada uno de los controles en el orden en que queremos establecer el flujo del foco, esos números irán cambiando y podremos determinar así el orden en que los controles irán recibiendo foco al momento de ejecutar la aplicación. El orden de tabulación está representado por la propiedad TabIndex que poseen todos los controles que pueden recibir foco. Un menor valor en la propiedad TabIndex de un control indica que ese control tomará foco antes que otro control que posea un valor mayor. Es posible que más de un control tenga el mismo valor en su propiedad TabIndex. En ese caso, tomará primero foco aquel que esté “más cerca del usuario”, es decir, un mayor Z-order (en caso que dos controles estuvieran superpuestos, es decir, que compartan parte de la superficie del formulario, el que tiene mayor Z-order es el que aparece por sobre el otro).
• #23: No es posible crear una instancia de la clase MessageBox. Para mostrar los mensajes simplemente se debe invocar al método (estático) Show. La manera en que se visualizará el mensaje (el título, el propio mensaje, los íconos, cantidad y tipo de botones que se mostrarán, etc.) se determinan por los parámetros que se pasen a ese método. El método Show devuelve un valor de tipo DialogResult que deberá ser evaluado para saber en qué botón presionó el usuario en caso de haberse indicado mostrar más de uno. Para mayor referencia, consultar el ejemplo Menu, controles, diálogos comunes que acompaña a esta presentación.
• #26: Desde las versiones anteriores del framework .NET han sido agregados varios nuevos controles, y a los ya existentes, se les ha incorporado muchas mejoras. Nuevos controles como MenuStrip / ToolStrip , Splitter , Panel , TableLayoutPanel y FlowLayoutPanel permiten crear complejas interfaces de usuario, con espacios que se reacomodan automáticamente al redimensionar la ventana, sin escribir una sola línea de código. BindingSource , BindingNavigator y DataGridView son controles que aprovechan las mejoras que incorpora .NET 2.0 en relación al enlace a datos (binding) provenientes de muy diferentes fuentes, como ser, bases de datos, colecciones .NET u objetos de negocio. BrackgroundWorker es un nuevo control que encapsula funcionalidad que permite ejecutar tareas que consumen mucho tiempo de manera asincrónica. Para mayor información, ver el ejemplo WindowsControls que acompaña a esta presentación.
• #27: Algunas características más: DataGridView : Soporta el modelo de enlace a datos estándar de Windows Form, pero además puede enlazarse a cualquier clase que implemente la interfaz IList (incluso arrays unidimensionales), IListSource (tales como DataSet o DataTable), IBindingList (como la clase BindingList), IBindingListView (como la clase BindingSource). Puede manejar datos de un modo desconectado, es decir, sin enlace a una fuente de datos (utilizando el método Add de la colección Rows del control DataGridView) Pude personalizarse la forma en que se muestran los datos con estilos predefinidos. Si las necesidades van más allá de lo que propone la clase DataGridViewCellStyle es posible extender su capacidad creando celdas, columnas y filas propias. TreeView Es posible mostrar cuadro de selección (check boxes) al lado de cada nodo (propiedad CheckBoxes ). También es posible seleccionar o deseleccionar nodos programáticamente (propiedad Checked ). A través de las propiedades ImageList , ImageIndex y SelectedImageIndex es posible asignar una imagen a cada nodo, tanto para el modo normal, como para cuando el nodo está seleccionado.
• #28: Como se menciona en la diapositiva, cada control contenedor maneja una colección de referencias a los controles que contiene. Dado que sólo es posible acceder a los elementos de primer nivel, se requerirá de una función recursiva para recorrer todos los controles que contiene un formulario cuando entre ellos exista al menos un control contenedor. Por ejemplo, si un formulario contiene dos controles GroupBox y a su vez, cada uno de ellos, contiene tres controles TextBox, la expresión: miFormulario.Controls.Count devolverá un valor de 2 cuando en realidad existe un total de 8 controles en el formulario.
• #29: Con el agregado de controles de menú en una aplicación Windows, surgen una serie de necesidades. Aquí detallamos cómo llevar a cabo algunas de las más comunes: Para mostrar una marca (check) en un comando de menú se debe asignar true a la propiedad Checked . Para mostrar una marca (check) en un comando de menú que cambie de estado con cada click se debe asignar true a la propiedad CheckOnClick . Es posible agregar una imagen (normalmente un icono) a un comando de menú. Para ello se debe asignar el nombre de la imagen a la propiedad Image . Para mostrar una línea de separación entre dos comandos de menú, se debe insertar (con el método Add o utilizando el diseñador de formularios) un menú item de tipo ToolStripSeparator . En aplicaciones del tipo MDI (Multiple Document Interface o Interfase de documentos múltiples) el tipo de ventanas hijas podría ser diferente de la ventana MDI padre . Por ejemplo, la ventana MDI podría contener una planilla de cálculo y la ventana hija podría contener un gráfico estadístico. En tal caso, si se quieren actualizar las opciones del menú principal (el de la ventana MDI) con las opciones que contiene el menú de la ventana hija cuando ésta esté activa se deben seguir los siguientes pasos: Establecer la propiedad AllowMerge del menú principal en true . Establecer la propiedad AllowMerge del menú de la ventana hija en true . Establecer la propiedad MergeAction de cada uno de los elementos del menú de la ventana hija en Append .
• #30: Para mayor referencia de utilización de los eventos de este control, ver el ejemplo que acompaña a esta presentación denominado Menu, controles, diálogos comunes .
• #32: Cuando un control es colocado en el formulario en tiempo de diseño, el diseñador muestra una serie de líneas para ayudar en la alineación de esos controles. Estas líneas generalmente incluyen bordes, márgenes y alineamiento a la base del texto de los controles. En Windows Forms .NET 2.0 todos los controles tienen una propiedad Margin . Es la distancia que existe alrededor del control. Cuando dos controles son movidos uno cerca de otro y cuando la distancia es igual a la suma de sus márgenes se muestra una línea snapline roja. Esta es la distancia que las guías de diseño de interfaces de usuario recomiendan. Los controles contenedores tienen una nueva propiedad llamada Padding . Es la distancia interna desde el borde del control contenedor al borde del control que está siendo ubicado dentro de suyo. Una línea snapline también se muestra cuando se alcanza esta distancia. Es posible definir snaplines personalizadas para controles propios. Se encontrará mayor información en las referencias a las clases SnapLines y ControlDesigner .
• #33: Desde la ventana Document Outline , además de ver claramente en forma jerárquica la disposición de controles del formulario, es posible también cambiar el nombre de los mismos, por lo que se vuelve una utilidad interesante que sirve para asignar nombres a los controles de manera visual y rápida.
• #34: Estos controles no están destinados en sí mismo para ser mostrados en pantalla, sino para aplicar lógica de distribución de los controles que contienen. Utilizando un control FlowLayoutPanel , los controles se irán colocando uno a continuación de otro hasta ocupar el ancho del formulario, el control siguiente se colocará en una línea inferior. Si en tiempo de diseño el formulario es redimensionado reduciendo su ancho, los controles se irán reacomodando hacia abajo para no ocupar un espacio mayor al nuevo ancho del formulario. El control TableLayoutPanel permite dar una distribución tabular a los controles, es decir, es posible crear “columnas” bajo las cuales se alinearan los controles. Estas columnas podrán tener anchos absolutos (un tamaño fijo en píxeles) o relativos (un porcentaje del tamaño de su contenedor). De esta manera, al redimensionar el formulario, los controles también se irán reacomodando pero respetando la estructura tabular.
• #35: Anchor : Sin escribir código, un TextBox anclado a los cuatro bordes del formulario se redimensionará automáticamente cuando lo haga su contenedor. Docking : El control ocupará entonces todo el ancho de ese borde elegido. También es posible pegarlo a los cuatro bordes simultáneamente, con lo que el control pasará a ocupar la superficie completa de su contenedor. Estas propiedades, junto con las herramientas que se ha visto en las diapositivas anteriores, hacen que diseñar complejas interfaces sea casi un juego de niños. No hay entonces que preocuparse por escribir complejas funciones de cálculo de coordenadas y tamaños para poder hacer que los controles de un formulario se reacomoden automáticamente al momento de redimensionarlo.
• #39: La herencia visual es una poderosa herramienta que permite estandarizar el diseño y el comportamiento de los formularios a lo largo del proyecto, o inclusive, en diferentes proyectos. Dado que, como se ha mencionado anteriormente, un formulario no es más que una instancia de una clase llamada System.Windows.Forms.Form, nada impide crear un formulario con los controles básicos. Podría crearse un formulario con un par de botones predeterminados (Aceptar y Cancelar por ejemplo), aplicarle algún diseño de tipos de letras y colores, agregar métodos con funcionalidad predeterminada (traducción automática, seguridad, etc.) para finalmente utilizarlo como un formulario base a partir del cuál se heredarán todos los demás formularios de la aplicación. Este formulario base podría formar parte del proyecto Windows en el que estamos trabajando o inclusive ser encapsulado en un proyecto Librería de Clases (.dll) para ser reutilizado luego en otros muchos proyectos.
• #41: Utilizando esta funcionalidad, incorporada en .NET 2.0, es posible personalizar aplicaciones Windows con propiedades tales como Color de Fondo, Imagen de Fondo, Nombre de la compañía, Domicilio de la compañía, cadenas de conexión a bases de datos, nombre del servidor, etc. El método InitializeComponent utiliza la clase System.Configuration.AppSettingsReader para cargar el valor de esas propiedades en tiempo de ejecución. Entorno de desarrollo de Visual Studio Express crea automáticamente la clase Settings que es utilizada para leer y grabar esos valores en tiempo de ejecución con pocas o ninguna línea de código.
• #44: El enlace a datos (o “DataBinding”) es la acción de asociar de manera automática o semi-automática datos de una fuente de datos con el contenido de controles gráficos que se mostrará a los usuarios. La fuente de datos de un databinding puede ser un objeto de ADO.NET (DataSet, XxxDataReader), un documento XML proveniente de un servicio web o una colección de objetos propios (Ilist, ArrayList, etc).
• #45: Se describe aquí, línea por línea, el código de ejemplo mostrado en la diapositiva (para ambos lenguajes): Línea 1: Se declara e instancia una colección de tipo ArrayList. Línea 2, 3 y 4: Se agregan nuevos elementos a la colección. Línea 5: Se enlaza el control Combo Box a la colección (ArrayList). Es posible este tipo de enlace ( binding ) porque como se mencionó para el caso del DataGridView (ver diapositiva 26), el control ComboBox soporta enlaces a clases que implementen la interfaz IList (como el ArrayList entre otros). Otra posibilidad es crear un ArrayList donde cada uno de sus miembros sea un objeto de una clase propia (por ejemplo llamada MiClase que simplemente contenga dos atributos : Codigo y Descripcion , y eventualmente un constructor parametrizado que asigne estas propiedades automáticamente). De esta manera asignando el ArrayList a la propiedad DataSource , Código a la propiedad ValueMember y Descripcion a la propiedad DisplayMember , el ComboBox manejará internamente el código del elemento seleccionado. Para recuperar ese código únicamente debemos verificar el valor de la propiedad SelectedValue en el manejador del evento SelectedIndexChanged . Código en C# ArrayList p aises = new ArrayList (); paises.Add( new MiClase(1, "Argentina")) ; paises.Add( n ew MiClase(1, "Brasil")) ; paises.Add( n ew MiClase(1, "Uruguay")) ; ComboBox1.DataSource = paises ; ComboBox1.ValueMember = "Codigo“ ; ComboBox1.DisplayMember = "Descripcion“ ; Código en VB.NET Dim paises As New ArrayList paises.Add(New MiClase(1, "Argentina")) paises.Add(New MiClase(1, "Brasil")) paises.Add(New MiClase(1, "Uruguay")) ComboBox1.DataSource = paises ComboBox1.ValueMember = "Codigo" ComboBox1.DisplayMember = "Descripcion"
• #46: El componente BindingSource tiene dos propósitos. Primero, provee una capa de abstracción cuando se enlazan los controles de un formulario a datos. Esto se consigue enlazando el componente BindingSource a la fuente de datos (Database, WebService y objeto de negocio) y luego enlazando los controles del formulario al componente. Toda interacción con los datos, incluyendo navegación, ordenamiento, filtrado y actualización, se realiza con llamadas al componente BindingSource. Segundo, el componente BindingSource puede actuar como una fuente de datos fuertemente tipada. Al enlazar un control a este componente, se crea automáticamente una lista de instancias de ese tipo. Si se asocia un control BindingNavigator al componente BindingSource, se pueden automatizar las tareas que se mencionaban más arriba.
• #47: Para mayor información sobre ADO.NET 2.0 refiérase al material de la Estrella 1.
• #50: La instalación de las aplicaciones Windows de escritorio en varios puestos de trabajo, siempre presentaron inconvenientes. El framework .NET 2.0 incorpora la tecnología ClickOnce que permite la fácil distribución de estas aplicaciones Una vez que la aplicación ha sido desarrollada y testeada, se publica en un servidor de distribución. Este paso involucra simplemente copiar todos los archivos de la aplicación previamente compilada en una carpeta en un servidor Web o un servidor de archivos. Junto con estos archivos se debe copiar el manifiesto de distribución ( deployment manifest ) que describe el proceso de distribución para ClickOnce. Una vez que los archivos han sido publicados, se suministra al usuario un enlace (hipervínculo URL o atajo) que apunta al manifiesto de distribución. Cuando un usuario hace click en ese enlace, el CLR de la máquina cliente reconoce la extensión del archivo manifiesto y ejecuta una distribución de ClickOnce de la aplicación, descargando (download) y ejecutando la aplicación en la máquina del usuario. La próxima vez que se ejecute la aplicación, si no hay una nueva versión en el servidor, el CLR la ejecutará directamente desde su copia local, caso contrario se encargará de descargar los componentes necesarios para actualizar localmente la nueva versión de aplicación. ClickOnce está pensado para distribuir aplicaciones Windows que constituyan simplemente la capa de presentación del usuario (UI). No es un reemplazo de Windows Installer (MSI), ni es conveniente para todo los tipos de aplicaciones. Si en el proceso de instalación de una aplicación se necesitan privilegios especiales que pueden afectar a otras aplicaciones de la máquina en la que se quiere instalar, o se requieren permisos irrestrictos al sistema de archivos, o accesos al registro de Windows, la aplicación no es candidata a ser distribuida mediante ClickOnce.