Crear una aplicación de Windows para que funcione siempre como Administrador

Los permisos por defecto en cualquier aplicación que uno desarrolla para Windows, toma por defecto el usuario con el que nos hemos autenticado en Windows.  Esto ocurre por razones de seguridad.  Pero algunas veces necesitamos que nuestra aplicación haga actividades en el PC con permisos administrativos... y generalmente esto genera errores en nuestra aplicación.

El usuario final que tiene en sus manos nuestra aplicación (así recién salida del horno de nuestro cerebro), y con SO Windows 7 o superior, puede darle permisos de ejecución para que se ejecute como administrador.  Pero seamos francos... no podemos depender de lo que haga un usuario (así se lo expliquemos con plastilina).

Para crear una aplicación que siempre se ejecute con permisos de administrador, esto es lo que hay que hacer en nuestro código:

1) Crear el archivo de manifiesto.  En El sitio de MSDN hay un tutorial muy claro de cómo generar este archivo (y un poco largo para ser sinceros). Resumiendo: En Propiedades del proyecto, ingresamos en la pestaña de "Aplicación" y pulsamos el botón de "Ver configuración de Windows".  Esto generará un archivo automáticamente llamado app.manifiest

2) Modificando el archivo app.manifiest.  Abrimos el archivo recién generado y cambiamos la configuración de requestedExecutionLevel.  Debe quedar con la siguiente sintaxis: <requestedExecutionLevel  level="requireAdministrator" uiAccess="false" />
En el archivo generado, hay varias opciones de ejemplo de lo que podemos hacer en cuanto a seguridad se trata, pero para nuestro objetivo de éste artículo pondremos el recien mencionado.

 

De esta manera, al ejecutar nuestra aplicación en Windows, sin importar cuál sea el usuario desde el que se está ejecutando la aplicación, tendrá como prioridad la ejecución "como administrador".

Esto es solo la mitad de la solución.  Porque el usuario, puede desde modificar sus permisos administrativos sobre cada aplicación y declarar nuestra aplicación como no apta para ser ejecutada con rol administrativo.  Entonces es necesario hacer una validación a nivel de código:

En VB.NET:

Imports System.Security.Principal

If myPrincipal.IsInRole(WindowsBuiltInRole.Administrator) = false Then

   MsgBox ("Requiere permisos administrativos para ejecutar esta aplicación")

End If 

En C#.NET:

using System.Security.Principal;

If (myPrincipal.IsInRole(WindowsBuiltInRole.Administrator) == false) {

MsgBox ("Requiere permisos administrativos para ejecutar esta aplicación"); 

}

No se puede insertar el valor NULL en la columna 'cualquiera', tabla 'bd.esquema.tabla'. La columna no admite valores NULL. Error de INSERT. Se terminó la instrucción.

Volvemos a las migraciones entre servidores... éste es a veces un problema que se nos presenta cuando ya hemos hecho casi de todo y creíamos que nuestra base de datos quedó bien respaldada y bien montada.

...pues no. No quedó bien respaldada y mucho menos bien montada. Y nos damos totazos contra la pared porque ya no hay marcha atrás y no tenemos acceso al servidor original. ¿Qué hacer?

Primero que todo alejemos al cliente un ratico a que se tome un café para que no nos respire en el cuello y nos remangamos la camisa... esto es lo que hay que hacer:

Entendiendo el problema

Sucede que al respaldar la base de datos de nuestro proyecto, no incluimos sus propiedades extendidas, y al montarla, se perdieron los índices, claves principales y autonuméricos.

Esto puede ser un grave problema si no tienes a la mano un manual de la base de datos (o una formidable memoria), para recordar cuáles campos hay que volver a colocar los índices, claves principales y autonuméricos.

Solucionando poco a poco

La buena noticia, es que hay solución.  La mala, es que es tediosa.  Hay que volver a asignarle los índices y autonuméricos a nuestras tablas de manera manual.

1) Valida que en el nuevo servidor si puedas hacer cambios en la base de datos. ¿Por qué? Es posible que te aparezca un mensaje al momento de guardar un índice que dice literalmente "No se permite guardar. Los cambios que ha realizado requieren que se quiten y vuelvan a crear las siguientes tablas. Quizá ha realizado cambios en una tabla que no se puede volver a crear o ha habilitado la opción Impedir guardar cambios que requieran volver a crear tablas".

El SQL Server Management Studio el viene con la opción "Impedir guardar cambios que requieran volver a crear tablas" habilitada de manera predeterminada, si olvida colocarle un campo, lo nombra mal o deja mal el tipo de dato esto evita que guarde las modificaciones.  Para cambiar esto, simplemente ingresa en el SQL Server Management Studio por Herramientas -> Opciones y en la ventana busca al lado izquierdo del árbol la opción de "Diseñadores" deshabilita esta opción. Así como se ve en la imagen de ejemplo:

2) Acceder a las columnas en las tablas para modificarlas.

Entrar en el diseño de cada una de las tablas para modificarles sus propiedades.  Esto lo haces simplemente con el botón derecho sobre cada tabla y pulsando la opción de "Diseño".

3) Asignar los índices principales en las columnas de las tablas.
Segun cada tipo de dato en tus tablas:

• Uniqueidentifier. 1) Seleccionar la columna del Indice principal. 2) Pulsar el botón de "Establecer clave principal". 3) En la propiedad de "Valor o enlace predeterminado" ponerle el valor de "NEWID()". 4) Guardar. De esta manera, queda lista la columna con llave principal y auto asignación de un nuevo valor:

 

• Int, Bigint. Aplica para los tipos de datos enteros y es muy similar al anterior. 1) Seleccionar la columna del Indice principal. 2) Pulsar el botón de "Establecer clave principal". 3) En la propiedad de "Especificación de Identidad" en el campo de (Identidad) ponerle el valor de "SI". 4) Guardar.

Como decía anteriormente, puede que no todo esté perdido, pero el no haber guardado bien un respaldo de base de datos, nos puede poner en un trabajo un poco más largo.