27 Jul 2010
Últimamente me he tenido que pelear un poco con Moles. Para los que no sepan qué es Moles, pueden consultar este post mío de hace un tiempo (ya me parezco a Enrique Dans autocitándome). Para los perezosos, resumir en que es un framework para testing que permite inyectar código en cualquier llamada al framework .NET. El ejemplo que suele verse en la mayoría de vídeos y textos demuestra cómo se puede “configurar” lo que queremos que devuelva DataTime.UtcNow, algo que sin Moles resulta imposible, pues UtcNow no tiene método set.
Bien, si en una librería que estás intentando “molear” tienes un tipo rebelde que se te rompe la generación, o bien prefieres limitar el número de clases que se molean a sólo aquellas que van a utilizar, esto te puede ser de utilidad. En cada mole tendremos un fichero XXX.moles, donde XXX es el ensamblado que hemos moleado. En dicho fichero podemos configurar algunas de las características del mole, lo que hará que se vuelva a generar teniendo en cuenta nuestra configuración.
Si quisiéramos evitar que se generara código para la clase DateTime en el ensamblado System, deberíamos añadir algo parecido a esto en nuestro fichero .moles:
<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
<Assembly Name="System" />
<CodeStyle DisableUniqueAlias="true" />
<StubGeneration>
<Types>
<Remove Namespace="System" TypeName="DateTime" />
</Types>
</StubGeneration>
<MoleGeneration>
<Types>
<Remove Namespace="System" TypeName="DateTime" />
</Types>
</MoleGeneration>
</Moles>
El fragmento es bastante autoexplicativo: le estamos indicando que, tanto de la generación de Stubs como de Moles, nos elimine la clase DateTime dentro del espacio de nombres System. Podremos introducir tantas entradas dentro de las etiquetas Types, como tipos queramos evitar “molear”.
Visto en los Foros de social.msdn.microsoft.com
27 Jul 2010
El atributo InternalsVisibleTo puede resultarnos muy útil en situaciones en las que tengamos la necesidad de acceder, desde un ensamblado, a los miembros Internal de las clases de otro ensamblado.
Un ejemplo que me he encontrado últimamente de su uso es en el testeo de aplicaciones Silverlight. Por desgracia, Silverlight no tiene ningún framework de testeo que sea capaz de generar accessors, probablemente porque Reflection no funciona para campos privados en Silverlight.
Para sustituir esta carencia, en algunos casos podremos marcar la visibilidad de miembros que queramos testear como Internal en lugar de Private y, haciendo uso de InternalsVisibleTo, acceder a ellos desde los correspondientes tests. ¿Cómo lo lograríamos? Son unos pocos pasos:
Primer paso: obtener la clave pública
Necesitamos conocer la clave pública de firmado del ensamblado al que queremos conceder el privilegio de poder acceder a los miembros internal. Para ello, en una consola de Visual Studio, deberemos introducir el siguiente comando:
sn -Tp c:UsersjavierprojectsMyProjectDllToGrantAccessToInternals.dll
De la salida que nos genera este comando, nos la copiamos para hacer el siguiente paso.
Segundo paso: definir el atributo
Ahora que ya conocemos la PublicKey del ensamblado (no confudir con la PublicKeyToken que aparece en los qualified names), necesitamos definir el atributo en el fichero AssemblyInfo del proyecto. En dicho fichero deberemos añadir algo como lo siguiente:
[assembly: InternalsVisibleTo("DllToGrantAccessToInternals.dll, PublicKey=0024000004…)]
¿Sencillo no? Con esto ya podríamos ver los miembros Internal del ensamblado en que hemos definido el atributo, desde el ensamblado DllToGrantAccessToInternals.
26 May 2010
No sé si es debido a un bug o simplemente es algo a lo que no hay modo sencillo de dar soporte, pero el caso es que los accessors que podemos utilizar en los proyectos de testing en Visual Studio 2008, no son capaces de invocar métodos que sean privados, estáticos y genéricos (a la vez).
Una posible solución (desconozco si hay más y más sencillas) es la invocación de estos métodos en nuestros tests mediante Reflection. Con este tipo de fragmentos de código vuelves una y otra vez a por ellos según vas pasando de proyecto en proyecto, aquí queda para el futuro.
1: // Obtener el MethodInfo asociado al metodo a invocar
2: MethodInfo methodInfo = typeof(ClassToInvoke).GetMethod(
3: "MethodToInvoke", System.Reflection.BindingFlags.Static | BindingFlags.Public);
4:
5: // Bindear el tipo con el metodo que queremos invocar
6: Type[] genericArguments = new Type[] { genericType };
7: MethodInfo genericMethodInfo = methodInfo.MakeGenericMethod(genericArguments);
8:
9: // Invocar el metodo y pasarle los parametros necesarios
10: // El parametro null es el objeto desde el que se invoca el metodo.
11: // Al ser un estatico, debe ser null
12: try
13: {
14: genericMethodInfo.Invoke(null, new object[] { value1, value2 });
15: }
16: catch (TargetInvocationException ex)
17: {
18: // Cualquier excepción lanzada por el método irá wrappeada dentro
19: // de una TargetInvocationException
20: if (ex.InnerException != null)
21: {
22: throw ex.InnerException;
23: }
24: else
25: {
26: throw;
27: }
28: }
19 May 2010
Actualización: He añadido al artículo original una explicación de porqué es más seguro utilizar usuarios de IIS en lugar de cuentas Windows, así como los problemas que podemos tener con el certificado a la hora de realizar los despliegues. Gracias desde aquí a Fernando Guillot por sus sugerencias.
Son muchas las novedades que han aparecido en Visual Studio 2010, entre ellas varias relacionadas con el despliegue de aplicaciones. A partir de ahora, en el menú contextual de cada proyecto web en VS2010 tendremos tres nuevas opciones, como se muestra en la siguiente imagen: generar un paquete de despliegue (un archivo zip), publicar utilizando alguna de las tecnologías disponibles y establecer la configuración del empaquetamiento/publicación.
Respecto a la publicación, sin duda la principal novedad es poder utilizar la tecnología de Web Deploy, presente en IIS (Internet Information Services) y que ayudará a administradores a simplificar la migración, gestión y despliegue de servidores web IIS. A continuación, vamos a ver cómo instalar y configurar esta tecnología en un servidor Windows Server 2008 R2. Al final del post se detallará cómo configurar Visual Studio 2010 para poder hacer uso de esta nueva forma de despliegue.
Instalación
Vamos a partir de una instalación en limpio de Window Server 2008 R2 Standard.
Añadir rol de servidor web
El primer paso es añadir el rol de servidor web a nuestra máquina Windows Server. Lanzamos la herramienta “Server Manager” y pulsamos en la opción “Roles”, en el árbol de la parte izquierda. En el centro de la ventana podremos ver una opción para añadir un nuevo rol, como a continuación.
En el asistente que nos aparece, pulsamos el botón “Siguiente” hasta que nos aparezca la lista de roles que podemos instalar. Seleccionamos el rol “Web Server (IIS)” tal como muestra la imagen bajo estas líneas.
Completaremos la instalación del rol indicando que queremos instalar también el servicio de Management, como se puede ver en la siguiente figura. Después, sólo queda esperar a que la instalación termine.
Instalar Web Deploy Tool
Ya tenemos instalado nuestro servidor IIS. Ahora debemos “ampliarlo” instalando la herramienta de Web Deploy. Lo primero será descargarnos el instalable y ejecutarlo.
Una vez ejecutado el fichero que acabamos de descargar, sólo tenemos que seguir el asistente pulsando el botón “Siguiente” hasta que nos ofrezca elegir qué tipo de instalación queremos realizar. Debemos instalar la versión completa si queremos tener a nuestra disposición el servicio “Web Deployment Agent”.
Tras terminar la instalación, será necesario arrancar a mano este servicio, puesto que está configurado por defecto como manual y parado. Lo haremos abriendo una consola y ejecutando el siguiente comando.
net start msdepsvc
Configuración del Web Deployment Handler
Ya tenemos Web Deploy instalado. Con esto podríamos generar paquetes de instalación con Visual Studio 2010 y desplegarlos en nuestra máquina destino utilizando IIS Manager. Sin embargo, para poder utilizar un perfil de despliegue desde el menú correspondiente de Visual Studio 2010, aún tenemos que dar algunos pasos más.
Lo primero será activar las conexiones remotas al servicio de Management. Para ello, utilizando el IIS Manager, debemos seleccionar el nodo del servidor y, dentro de la vista de Features, hacer doble click en el icono de “Management Service”. Una vez en la pantalla correspondiente, tal como muestra la siguiente imagen, podremos habilitar las conexiones remotas e indicar que será posible autenticarse tanto con cuentas Windows como con credenciales del IIS Manager.
El siguiente paso a ejecutar es conceder privilegios sobre la carpeta en la que se van a hacer los despliegues. En este punto tenemos dos estrategias posibles a seguir:
- Concederle permisos a la cuenta sobre la que corre el servicio de Management, por defecto “Local Service”. Es la opción más sencilla, puesto que no tendremos que crear cuentas extra y, además, más adelante al definir las distintas reglas de despliegue, nos simplificará uno de los pasos.
- La otra opción es crear una cuenta específica y concederle a ella esos privilegios. También podemos optar por crear un grupo y concederle a dicho grupo los permisos. De este modo, permitir a más usuarios poder realizar el despliegue sería tan sencillo como añadirlos al grupo.
Sea cual sea el enfoque que tomemos, es importante aclarar que los mismos permisos que se asignan aquí, se deberán conceder más adelante sobre el fichero applicationHost.config, por lo que la decisión tiene claras implicaciones de seguridad.
Por simplicidad, aquí vamos a concederle los privilegios a “Local Service”. Lo haremos sobre la carpeta donde vamos a desplegar las aplicaciones web, es decir, sobre Inetpubwwwroot, tal como se puede ver en la imagen.
El siguiente paso sería crear el usuario de IIS al que queremos conceder la posibilidad de hacer despliegues remotos de aplicaciones. Podríamos crear, en su lugar, una nueva cuenta Windows y realizar todo el proceso con ella. Sin embargo, tendremos un nivel extra de seguridad si utilizamos un usuario de IIS puesto que, en caso de ser comprometido, este usuario no sería reconocido por el sistema ni por ninguna otra aplicación de la máquina. Para ello, de nuevo es necesario utilizar IIS Manager, pulsar sobre el nodo del servidor y, en la ventana de Features, hacer doble click, esta vez sobre el icono de “IIS Manager Users”. En la parte derecha de la pantalla encontraremos un enlace para añadir nuevos usuarios. Tras pulsar en él, podremos introducir en la ventana emergente un nombre para el usuario y una contraseña.
Debemos dar permisos al usuario que acabamos de crear sobre el sitio web en el que va a realizar sus despliegues. Para ello, todavía en IIS Manager, pulsamos sobre el nodo que corresponde al sitio web. Sobre la ventana de Features, en este caso correspondiente al sitio web, debemos hacer doble click en el icono de “IIS Manager Permissions”. En la parte derecha de la pantalla podremos ver un enlace para añadir un usuario, que nos mostrará una ventana como la que se ve el imagen que sigue. Esta pantalla permite elegir entre cuentas Windows o cuentas de IIS Manager. Puesto que el usuario que hemos añadido en el paso anterior es del segundo tipo, usaremos el segundo botón para elegirlo de la lista de usuarios de IIS Manager y añadirlo.
Reglas de delegación
Recapitulando, en este punto tenemos correctamente creado nuestro usuario IIS y asignados permisos sobre el sitio web. Necesitamos ahora crear diferentes reglas relacionadas con el despliegue de aplicaciones. Vamos a crear un total de tres, siempre utilizando IIS Manager.
Para crear cada una de las reglas, debemos lanzar IIS Manager si no lo tenemos todavía abierto y pinchar sobre el nodo del servidor. Como en pasos anteriores, pulsaremos en la vista de Features y haremos doble click sobre uno de sus iconos: el que corresponde a “Management Service Delegation”. Pulsando en la parte derecha de la pantalla sobre “Add Rule” aparecerá una ventana emergente como la que muestra la siguiente imagen. Seleccionaremos una regla de tipo “Deploy Applications with Content”. Quedémonos con la secuencia de pasos que nos ha llevado a esta ventana de selección de reglas, puesto que volveremos a ella dos veces más.
Aceptamos la configuración por defecto para la regla pulsando OK y en la ventana que aparece despues introducimos el nombre que hayamos dado a nuestro usuario IIS. El resultado que veríamos sería parecido a la siguiente imagen.
Hay más reglas que podemos configurar, como se ha visto en la pantalla anterior. Otra de las reglas permite al usuario configurar las listas ACL (Access Control Lists) de los ficheros que componen la aplicación web. Para añadirla, es preciso seguir los pasos anteriores y seleccionar en la pantalla de tipos de regla, la denominada “Set Permissions”. Pulsaremos OK en la ventana que aparecerá para crear la regla con sus valores por defecto, y de nuevo introduciremos el nombre del usuario IIS que creamos varios pasos antes.
La última regla que vamos a añadir permite al usuario la creación de aplicaciones en el servidor IIS. La regla a seleccionar de entre los distintos tipos que aparecen en la ventana tras pulsar el botón de “Add Rule” se llama “Mark Folders as Applications” y presenta una pequeña diferencia con las anteriores: no podemos aceptar la configuración por defecto, puesto que tenemos que seleccionar como cuenta de usuario para ejecutar la regla, la cuenta actual (“Local Service”). Para que la regla funcione correctamente, es necesario que la cuenta sobre la que se ejecuta tenga permisos de escritura sobre el fichero c:windowssystem32inetsvcconfigapplicationHost.config. Por tanto, lo primero será dirigirnos a la carpeta que contiene ese fichero y concederle privilegios de escritura a la cuenta “Local Service”.
Una vez hecho eso, añadiremos la regla siguiendo los pasos anteriores. En la ventana que nos aparece tras pulsar “Add Rule”, debemos seleccionar la opción CurrentUser
Una vez modificada la regla, tras pulsar el botón de OK, la asociaremos con el usuario de IIS como hemos hecho con las anteriores reglas. Con esto, podemos dar la configuración por terminada.
Conexión desde IIS Manager
Para comprobar si hemos completado correctamente todo el proceso, podemos descargar la herramienta de administración remota de IIS y tratar de conectarnos al servidor que acabamos de configurar.
Una vez instalada y arrancada, es posible probar si nuestra configuración es correcta intentando conectarnos al sitio con el usuario IIS que creamos. Para ello, tendremos que pulsar en el menú “File” y seleccionar la opción “Connect to a Site”.
En el asistente que va a aparecer tendremos que meter los siguientes datos en la primera pantalla:
- Server name: dirección IP o nombre de la máquina que hemos configurado.
- Site name: nombre del sitio. Si es el sitio por defecto de IIS, será “Default Web Site”.
En la siguiente pantalla del asistente, tendremos que introducir las credenciales de nuestro usuario IIS. Si todo es correcto, tras conectarse nos solicitará confirmación de que confiamos en el certificado con el que se está cifrando la conexión.
Este error nos aparece puesto que el nombre del servidor no coincide con la máquina para la que se ha emitido este certificado. Si pulsamos sobre el botón “View Certificate” para ver más información del mismo, podremos comprobar que en el campo “Issued to” aparecerá siempre “WMSvc-“ seguido del nombre de la máquina. Sin embargo, si generamos un nuevo certificado en IIS con el nombre de la máquina, configuramos el servicio de Management para usarlo con la conexión SSL y especificamos el nombre de la máquina en lugar de su dirección IP para conectarnos a ella, recibiremos este otro aviso.
En este caso, si pinchamos sobre “View details…” nos encontraremos con un poco útil mensaje indicándonos que ha habido un error desconocido. Si las máquina servidor y cliente estuvieran en un dominio en el que ambas confiaran en una máquina con autoridad certificadora, podríamos generar un certificado de dominio y resolver el problema. Sin embargo, en instalaciones de prueba como la de este ejemplo, bajo grupos de trabajo, no resulta práctico y es más productivo instalar el certificado para poder completar el proceso.
Tras conectarnos y darle un nombre a la nueva conexión, podremos ver información sobre el servidor IIS remoto en nuestra ventana de IIS Manager. Ahora que sabemos que está listo para conectarse a él, nos queda utilizarlo desde Visual Studio 2010.
Conexión desde Visual Studio 2010
Ya estamos donde queríamos estar. Tenemos listo Web Deploy en el servidor donde vamos desplegar nuestras aplicaciones web, y ahora sólo nos resta configurar Visual Studio para empezar a disfrutar de las ventajas de esta tecnología.
En cualquier proyecto web que queramos desplegar, sobre el nombre del proyecto, con el botón derecho del ratón, haremos aparecer el menú que veíamos en la primera imagen de este artículo. Debemos pulsar sobre la opción “Publish” para que se muestre una ventana como la siguiente.
Los datos a introducir serían:
- Un nombre para el nuevo perfil de publicación. En el ejemplo, “WebDeploy DevIIS”.
- Seleccionar un método de publicación: Web Deploy.
- La dirección del servicio, que será, por defecto, http://servidor:8172/MsDeploy.axd
- La aplicación web a crear. Puesto que estamos creando sobre el sitio “Default Web Site”, deberá aparecer antes de la barra. Al otro lado, podemos dar el nombre de una aplicación existente o crear una nueva.
- Si marcamos el checkbox que viene inmediatamente después, estaremos indicando que queremos crear una aplicación en IIS al hacer el despliegue.
- Necesitamos activar el checkbox relacionado con las credenciales si tenemos un certificado de desarrollo, como en este ejemplo.
- Por último, introducimos las credenciales del usuario IIS que definimos varios pasos antes en este artículo.
Una vez configurado correctamente el perfil de despliegue, sólo necesitaremos pulsar el botón de Publish para ver cómo, de forma rápida, limpia y segura, tenemos desplegada nuestra aplicación web en nuestro servidor.
Conclusiones
Puede que el proceso inicial de configuración del servidor resulte laborioso, pero una vez completados los pasos, la ganancia que en tiempo, facilidad y seguridad de despliegue van a obtener tanto administradores como desarrolladores, bien merece la inversión. Desde el punto de vista de los administradores, la granularidad a la hora de controlar qué tareas se permiten para cada usuario, independizando las cuentas del sistema de las cuentas únicamente destinadas a la gestión del servidor web, justifican el esfuerzo.
Y desde el punto de vista de los desarrolladores, resulta toda una gozada poder desplegar nuestras aplicaciones a entornos de desarrollo, preproducción y producción con en tres clicks. De este modo, pasar de unos entornos a otros dejará de ser la tarea complicada a y propensa a errores que es actualmente.
Bibliografía
