WCF4 – Configuración simplificada

Creo que muchos de los que hemos trabajado con Windows Communication Foundation podemos estar de acuerdo en que, en mayor o menor medida, no resulta una tecnología fácil de configurar. Es cierto que aporta una gran flexibilidad en el desarrollo, pero a la hora de hacer el despliegue hay que ser cuidado con el web.config/app.config de turno, si no queremos llorar.

Seguramente esto ya había sido identificado por Microsoft como punto negro del framework, pues muchas de las mejoras que para el lanzamiento de .NET 4 va a haber respecto a WCF, se centran en simplificar dicha configuración, tirando sobretodo de valores por defecto.

En el próximo post vamos a ver las diferencias que habría entre configurar un servicio “típico” de WCF en 3.5 y hacerlo en 4.0.

Hola Mundo en 3.5

Vamos a empezar por hacernos un servicio sencillo con .NET 3.5 y Visual Studio 2008. No me detendré mucho en ello, porque el proceso es bien conocido por todos. Empezamos por el contrato de servicio:

/// <summary>
/// Service that says hello world.
/// </summary>
[ServiceContract]
public interface IHelloWorld
{
    /// <summary>
    /// Gets "Hello Word from X", where X is the name parameter.
    /// </summary>
    /// <param name="name">Who says hello.</param>
    /// <returns>String with hello world message.</returns>
    [OperationContract]
    string GetHelloWord(string name);
}

La implementación para este servicio podría ser algo como lo siguiente:

/// <summary>
/// Implementation of the IHelloWorld service contract.
/// </summary>
public class HelloWorld : IHelloWorld
{
    /// <summary>
    /// Gets "Hello Word from X", where X is the name parameter.
    /// </summary>
    /// <param name="name">Who says hello.</param>
    /// <returns>String with hello world message.</returns>
    public string GetHelloWord(string name)
    {
        return string.Format("Hello world from {0} - Request from {1}", name, OperationContext.Current.Channel.LocalAddress);
    }
}

Por último, lo que realmente nos ocupa en este post, la configuración. Digamos que necesitamos desplegar este servicio de forma que pueda ser consumido mediante un binding lo más interoperable posible (BasicHttpBinding es nuestro hombre) y otro que sea más específico para aplicaciones .NET y que nos dé más rendimiento (vamos a tirar por NetTcpBinding). Además, todavía necesitamos información sobre errores que haya en el servidor, puesto que no está totalmente terminado, y no nos vendría mal un punto MEX para poder crear nuestros proxies.

<system.serviceModel>
  <services>
    <service behaviorConfiguration="HelloWordService.ServiceBehavior"
             name="HelloWordService.HelloWorld">
      <!-- Binding para peticiones HTTP -->
      <endpoint address=""
                binding="basicHttpBinding"
                contract="HelloWordService.IHelloWorld" />
      <!-- Binding para peticiones TCP -->
      <endpoint address=""
                binding="netTcpBinding"
                contract="HelloWordService.IHelloWorld" />
      <!-- Binding para obtener metadatos -->
      <endpoint address="mex"
                binding="mexHttpBinding"
                contract="IMetadataExchange" />
      <host>
        <baseAddresses>
          <add baseAddress="http://localhost:9999/HelloWorldService"/>
          <add baseAddress="net.tcp://localhost:9998/HelloWorldService"/>
        </baseAddresses>
      </host>
    </service>
  </services>
  <behaviors>
    <serviceBehaviors>
      <behavior name="HelloWordService.ServiceBehavior">
        <!-- Activar la generación de metadatos para el binding MEX -->
        <serviceMetadata httpGetEnabled="True"/>
        <!-- Incluir información detallada para excepciones -->
        <serviceDebug includeExceptionDetailInFaults="False" />
      </behavior>
    </serviceBehaviors>
  </behaviors>
</system.serviceModel>

Con esta configuración tendríamos a nuestro servicio escuchando en las dos direcciones base definidas, una para TCP y otra para HTTP. También tendríamos funcionando un endpoint MEX para poder generar nuestros proxies y consultar el fichero WSDL. Este servicio podríamos desplegarlo bien en IIS o bien hostearlo mediante una aplicación de consola. El resultado sería parecido, con la salvedad de que las baseAddress no son tenidas en cuenta por IIS, sino que se toma la ruta en la que se haga el despliegue de la aplicación. Recordad que es necesario configurar los bindings del Site que aloja a la aplicación web para poder tener funcionando el endpoint sobre net.tcp.

Para terminar esta parte, si nos creáramos un cliente de este servicio en su versión hosteada en IIS, en la parte de la configuración podríamos ver un fragmento como éste:

<client>
    <endpoint address=http://localhost/HelloWorldService binding="basicHttpBinding"
        bindingConfiguration="BasicHttpBinding_IHelloWorld" contract="RemoteServices.IHelloWorld"
        name="BasicHttpBinding_IHelloWorld" />
    <endpoint address="net.tcp://localhost/HelloWorldService"
        binding="netTcpBinding" bindingConfiguration="NetTcpBinding_IHelloWorld"
        contract="RemoteServices.IHelloWorld" name="NetTcpBinding_IHelloWorld">
        <identity>
            <userPrincipalName value=j.holguera@xxx.local />
        </identity>
    </endpoint>
</client>

Con estos dos endpoints definidos, podríamos consumir el servicio mediante los dos protocolos (HTTP y TCP), como muestra la siguiente imagen.

using (RemoteServices.HelloWorldClient proxy = new RemoteServices.HelloWorldClient("BasicHttpBinding_IHelloWorld"))
{
    Console.WriteLine("HelloWorld using HTTP: " + proxy.GetHelloWord("Javier"));
}

using (RemoteServices.HelloWorldClient proxy = new RemoteServices.HelloWorldClient("NetTcpBinding_IHelloWorld"))
{
    Console.WriteLine("HelloWorld using TCP: " + proxy.GetHelloWord("Javier"));
}

El resultado sería sendas cadenas de texto en las que, además de aparecer el mensaje de saludo, se nos indica la dirección desde la que se ha recibido la petición en el servicio, útil para ver que efectivamente consumimos la funcionalidad mediante los dos protocolos.

 ConsoleClient35

Como se puede ver, la única parte que realmente existe un buen  puñado de líneas es la configuración del servicio. Veamos cómo quedaría usando WCF 4.

Hola Mundo en WCF 4

Partamos de la base de que hemos creamos un proyecto WCF con Visual Studio 2010 y hemos replicado el servicio anterior, es decir, el contrato de servicio IHelloWorld y su implementación HelloWorld. Sólo nos quedaría, por tanto, configurar el servicio en el fichero app.config. Empezamos definiendo los bindings para HTTP y TCP. La configuración necesaria sería ésta:

<configuration>
</configuration>

¿No hay configuración? ¿Cómo es posible? Pues gracias a los Default Endpoints. Son endpoints “preconfigurados” que se cargan automáticamente para cada dirección base creada. Al llamarse al método Open del ServiceHost, ya sea automáticamente por parte de IIS o manualmente cuando se hostea el servicio en una aplicación de consola, se crean estos bindings predeterminados haciendo uso del método AddDefaultEndpoints. Un par de cuestiones a tener en cuenta:

  • Si se configura un endpoint en el fichero de configuración, ya no se hace efectiva la llamada a AddDefaultEndpoints.
  • Si aún así quisiéramos tener esos endpoints por defecto, siempre es posible llamar explícitamente al método AddDefaultEndpoints y añadir, a los endpoints definidos en el fichero de configuración, los que crea él por defecto.

Los bindings traen una configuración por defecto que se considera como más habitual. Por ejemplo, con una dirección base con protocolo http, el binding por defecto es basicHttpBinding. Esta nueva técnica ha sido bautizada como Default Protocol Mapping. En cualquier caso, este mapeo también es configurable; si quisiéramos que, por defecto, la direcciones con protocolo se resolvieran con un binding de tipo wsHttpBinding, sería necesario configurar lo siguiente en el app.config/web.config:

  <system.serviceModel>
    <protocolMapping>
      <add scheme="http" binding="wsHttpBinding"/>
    </protocolMapping>
  </system.serviceModel>

En este punto, tendríamos nuestro servicio hosteado en IIS. Nos quedaría activar los metadatos del servicio para generar el fichero WSDL y enviar información detallada en caso de error. Ambas no son configuraciones por defecto del servicio, por lo que tendríamos que editar el fichero app.config/web.config e introducir lo siguiente:

  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

Si nos fijamos, veremos que no ha sido necesario ni darle un nombre al nuevo behavior del servicio, ni tampoco definir el servicio y asociarle el behavior, como hacíamos en 3.5. Esto se conoce como Default Behavior Configurations, configuraciones sin nombre que se van a aplicar a cualquier servicio que definamos. Tienen su contrapartida en los Default Binding Configurations, que realizan la misma función pero asociados a un tipo de binding.

 

Como se ha podido ver a lo largo del post, la configuración en WCF4, al menos la más habitual, se ha simplificado enormemente. Los nostálgicos de la sencillez de los servicios ASMX han perdido la principal razón para no dar el paso a WCF.

 

Bibliografía:

A Developer's Introduction to Windows Communication Foundation 4

Descargas:

Instalar Windows 7 en Windows Virtual PC

Después de buscar un rato en Google Bing, no he visto ningún post sobre cómo instalar Windows 7 en una máquina con Windows Virtual PC. Puede resultar contradictorio puesto que Windows Virtual PC sólo funciona en Windows 7, pero ¿a quién no le ha hecho falta una máquina virtual con la que trastear? Prácticamente para eso se crearon las máquinas virtuales, ¿no? ;)

Pues bien, yo necesito una máquina con Windows 7 para instalar sobre ella Visual Studio 2010. Esto es lo que he hecho para tenerla.

Descarga e instalación

La descarga la he hecho de esta dirección: http://www.microsoft.com/windows/virtual-pc/. De los dos ficheros que indicaba que era necesario descargar, sólo lo he hecho con “Windows Virtual PC”, puesto que no me iba a hacer falta el “Windows XP Mode”.

Una vez bajado, la instalación es un simple doble click –> next –> next. Eso sí, es necesario reiniciar y tanto al apagarse como al volverse a arrancar, está un tiempo configurando esta nueva instalación.

Al volver a arrancar, podremos ver en el menú de inicio un nuevo enlace de nombre “Windows Virtual PC”. Pulsarlo nos llevará una ventana como la que aparece en la siguiente imagen.

VirtualMachinesWindow

Nueva máquina virtual

Ya tenemos la aplicación instalada, es momento de crear la primera máquina virtual. El proceso no puede ser más sencillo. Lo primero es pulsar el botón “Create Virtual Machine”, que aparece en la ventana anterior. Esto nos lanzará un cuadro de diálogo para crear una nueva máquina virtual, que comienza con darnos la opción de definir el nombre de esta nueva máquina, como se muestra en la siguiente imagen.

VirtualMachineName

El siguiente paso es indicar la cantidad de memoria RAM que queremos que tenga disponible la máquina virtual. Mucho ojo con esto porque, en el momento de lanzar la máquina virtual, tendrá que estar libre dicha cantidad de memoria RAM, pues de lo contrario no arrancará la máquina. La siguiente imagen muestra este paso en el cuadro de diálogo.

VirtualMachineMemory

Por último, debemos indicar qué clase de disco duro vamos a manejar. Las opciones principales son crear uno nuevo o elegir uno ya existente, en caso de que, por ejemplo, estuviéramos creando esta máquina virtual a partir de una ya existente. Elegimos la primera opción como se muestra en la siguiente figura.

VirtualMachineHardDisk

Con esto ya tendríamos terminada nueva máquina virtual. Para empezar con la instalación de Windows 7, bastaría con introducir en el DVD de instalación, volver a la ventana de Windows Virtual PC, seleccionar la nueva máquina “Windows7” y pulsar el botón “Open”. De este modo la máquina empieza a ejecutarse y, como cualquier máquina, arrancaría con el DVD la instalación. El final del proceso sería la pantalla con la que Windows 7 nos da la bienvenida para empezar la instalación, seleccionando la configuración de idioma como muestra la siguiente imagen.

Windows7InVirtualPC

El resto es next-> next-> next, puesto que para Windows 7 la instalación se está haciendo sobre una máquina real y los pasos a seguir son los mismos.

Para terminar, es muy recomendable instalar los Integration Components. Se puede hacer desde el menú Tools que aparece en la propia ventana de la máquina virtual y nos permitirá, entre otras cosas, tener sonido, acceso a USBs y, lo que me parece más importante, poder sacar el ratón de dentro de la máquina virtual sin tener que recurrir a la combinación ALT+CONTROL+RIGHT, lo que aumenta considerablemente la sensación de integración.

Debugger in Silverlight

Este fin de semana perdí una cantidad considerable de tiempo porque no me funcionaba el debugger en Silverlight. Básicamente, me salían esos simpáticos mensajes que aparece en Visual Studio cuando un breakpoint no se va a ejecutar:

The break point currently will not be hit , no symbols have been loaded to this document

¿Por qué? ¡¿Por qué?! Me preguntaba yo, intentando depurar una aplicación que estaba comportándose de forma incorrecta. Pues bien, la solución es tan sencilla, de esas que por suerte no se olvidan. Basta con activarlo dirigiéndose a las propiedades del proyecto ASP.NET que estará hosteando nuestro control Silverlight.

En las propiedades, bajo la pestaña Web, en la parte inferior de la pantalla se puede ver un menú como el de la siguiente imagen. Basta activar el checkbox correspondiente a Silverlight para que nuestro depurador favorito funcione de nuevo correctamente.

SilverlightDebugger

Espero que esto le sirva a alguien para perder menos tiempo del que perdí yo.

Code Coverage (II): Uso

Una vez que tenemos activado el Code Coverage para un ensamblado y tras lanzar los correspondientes tests, ver los resultados es una mera cuestión de abrir la pestaña de “Code Coverage Results”, que si no es visible se puede activar en el menú “Test – Windows – Code Coverage Results”.

CodeCoverageResults

En la ventana de ejemplo se puede ver cómo los resultados se gestionan, en primer lugar, por ensamblado ; y dentro del ensamblado , cómo se pueden ir expandiendo los diferentes espacios de nombres, clases y, por último, métodos. Sin duda, una gran granularidad que nos permite saber con precisión dónde estamos quedándonos cortos en el testeo.

Pero, si esta ayuda es buena, tener el código coloreado indicando qué partes han sido ejecutadas durante el testeo y cuáles no, sería aún mejor, ¿verdad? Basta con pulsar el botón “Show Code Coverage Coloring”, el tercero por la derecha en la ventana de “Code Coverage Results”, para obtener algo como la siguiente imagen.

ColoredCode

¡Genial! Ahora no sólo sé la cantidad de código que me falta por testear, sino que incluso sé qué para qué código necesito escribir nuevos tests. Vale, esto se salta totalmente los principios de TDD, pero la vida no siempre es maravillosa…

Un último apunte para terminar: he comprobado (en mis carnes) que algunos proyectos dan problemas al intentar configurar los ensamblados a los que se les va a calcular la cobertura de código.

Los síntomas son sencillos: abrimos el .testrunconfig, pinchamos en “Code Coverage”, y la ventana se cierra sin emitir ningún error. No soy el primero al que le pasa y aunque está reportado como bug, aparentemente sigue sin solucionarse.

La forma de evitarlo es tan chapucera como útil: simplemente hay que hacer el unload de algunos proyectos que son los que dan problemas. A mí, personalmente, me ha ocurrido exclusivamente con los proyectos de base de datos, pero parece ser que también existen problemas con proyectos WSSF. Avisados quedáis.

Code Coverage (I): Activación

Voy a decirlo aquí en alto y con vergüenza: hasta esta semana, no había usado nunca el Code Coverage. Y como ocurre con todas las buenas herramientas, ahora pienso: “¿cómo he podido estar sin esto hasta ahora?”.

Empezar a usarlo es sencillo, aunque tiene una pequeña peculiaridad: sólo funciona cuando los tests se ejecutan, no si se depurar. ¿Qué quiere decir esto? Que a la hora de seleccionar el conjunto de tests que queramos lanzar, deberemos utilizar la opción “Run Selection” en lugar de “Debug Selection”, en la ventana de “Test View”.

TestViewWindow

Como ya sabemos, el problema de esto es que cualquier punto de depuración que tengamos en el código no va a ejecutarse, pero parece un mal menor comparado con las posibilidades que tiene Code Coverage. Además, uno de los principios de testeo unitario es precisamente evitar la necesidad de depurar el código, así que no hay de qué quejarse.

Para poder ver la pestaña que muestra los resultados de cobertura de código existen dos posibilidades: pulsar el último de los botones que parecen en la ventana de “Test Results” o bien acceder a la opción de menú “Test – Windows – Code Coverage Results”.

Sin embargo, de poco nos servirá esto si no activamos previamente el Code Coverage para que se calculen sus resultados. Esto se configura en el fichero .testrunconfig que existe en la carpeta “Solution Items”.

TestRunConfig

Una vez abierto, hay pulsar en la opción de “Code Coverage” y seleccionar los assemblies sobre los que vamos a calcular la cobertura de código. Este punto es más importante de lo que podría pensarse, puesto que lo normal será tener dos versiones para cada uno: la versión de Debug y la versión de Release (podemos tener más si existen más configuraciones del proyecto). La clave es que no podemos elegir las dos a la vez, por lo que seleccionemos la que seleccionemos, tendrá que estar “sincronizada” con la configuración actual del proyecto. De lo contrario, tendremos un problema: la cobertura se calculará sobre un assembly que no tiene porqué estar actualizado con los últimos cambios que hemos hecho en el código.

Un ejemplo: digamos que hemos elegido la versión de Debug del assembly, pero tenemos configurado el proyecto en modo Release. Tenemos un 100% de cobertura de código, pero introducimos nuevas líneas en un método y compilamos (en Release). El assembly de Debug, sobre el que se va a pasar la cobertura, no ha cambiado, por lo que nos seguirá marcando 100% de cobertura aún cuando sabemos que no tenemos tests para el código que acabamos de añadir. Puede ser todo un problema, ¿verdad?

Por hoy es suficiente. Otro día, cómo interpretar los resultados y el coloreado del código.

Orden de campos del DataContract

Cuando estaba preparándome la certificación de WCF, descubrí algo que es conveniente tener apuntado, pues puede dar bastantes quebraderos de cabeza: el orden en que aparecen los campos de información en los mensajes WCF una vez serializados. Estas son las reglas:

  • Si el contrato hereda de otro tipo, aparecen en primer lugar los elementos de ese tipo base.
  • Después, los elementos del propio contrato que no tengan la propiedad Order de DataMemberAttribute, ordenados alfabéticamente.
  • Por último, los elementos que tengan la propiedad Orden, según el valor asignado.

Me ha resultado curioso que aparezcan primero los elementos sin la propiedad Order. Seguramente haya una razón que desconozco para que éste sea el comportamiento, pero entiendo que puede llevar a error fácilmente. ¿Por qué? Pues porque si seleccionas un elemento que quieres que vaya primero, y le das la propiedad Order = 1, probablemente, de desconocer estas reglas, esperarás que con esto sea suficiente para que aparezca en primer lugar en el mensaje WCF.

Pero no, será necesario que asignes valores a todos los otros elementos, para que no se antepongan al que has elegido tú, por aquello de no tener propiedad Order.

Por último, destacar que estas reglas aplican también al orden en que aparecen los elementos que añadamos a un MessageContract con el atributo MessageBodyMemberAttribute.

Algún día tengo que buscar porqué la gente de .NET decidió esto así.

WCF: Validación de certificados

Cuando se está en un entorno de desarrollo, es bastante común utilizar certificados “auto-firmados” (self-signed) para bindings que requieran seguridad.

Sin embargo, WCF no acepta este tipo de certificados, lanzando una excepción de tipo SecurityNegotiationException, con un mensaje acompañando del estilo a “Could not establish trust relationship for the SSL/TLS secure channel with authority 'localhost:8732'”. ¿Qué hacer? Es fácil, simplemente hay que “engañar” al cliente para que acepte este certificado que el servidor nos está ofreciendo para realizar la conexión SSL, aunque esté firmado por sí mismo.

Para ello, en el cliente, es necesario introducir el siguiente código:

   1: static void Main(string[] args)
   2: {
   3:     using (DemoService.GetHeadersClient proxy = new DemoService.GetHeadersClient())
   4:     {
   5:         ServicePointManager.ServerCertificateValidationCallback += 
   6:             new System.Net.Security.RemoteCertificateValidationCallback(ValidateCertificate);
   7:  
   8:         // Do stuff with proxy object
   9:     }            
  10: }
  11:  
  12: public static bool ValidateCertificate(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors errors)
  13: {
  14:     return true;
  15: }

El método definido será invocado por WCF en el momento de la validación del certificado, asegurándonos que el cliente va a aceptarlo en cualquier caso.

Por supuesto, esto es algo totalmente desaconsejado en cualquier entorno de producción. Pero para salir del paso en desarrollo, viene muy bien.

Respuesta original vista aquí.

Petición POST con C#

Dicen que nunca te acostarás sin aprender algo nuevo. Yo he tenido mi ración diaria con la forma de realizar una petición POST desde .NET. Probablemente sea una simpleza que todo el mundo sabe, pero yo lo desconocía.

El proceso es bastante intuitivo, salvo en la forma de añadir parámetros a la petición, que a mí me ha dejado algo más sorprendido. Pasos:

  1. Instanciar una URI con la dirección a la que se quiere hacer la petición, pero sin parámetros.
  2. Crear el objeto Request. Castearlo directamente a HttpWebRequest, puesto que el Create, aunque devuelva un WebRequest, en realidad es un objeto HttpWebRequest (que es un subtitpo de WebRequest).
  3. Configurar la request, indicando que se va a usar POST (obligatorio), el content-type (opcional), la longitud (obligatorio) y la versión del protocolo HTTP (opcional).
  4. Obtener un steam de la petición. Se va a añadir los parámetros como si fueran bytes, que al fin de cuentas es el contenido de la petición.
  5. Terminamos haciendo una llamada a GetResponse para obtener la respuesta.

El código de todo este proceso sería algo parecido a lo siguiente:

   1: HttpWebRequest httpRequest = 
   2:     HttpWebRequest.Create("http://direccion.com/pagina") as HttpWebRequest;            
   3: httpRequest.Method = "POST";
   4: httpRequest.ProtocolVersion = HttpVersion.Version11;
   5: // Parameters es un string que contiene todos los parametros en 
   6: // formato param1=value&param2=&param3=value
   7: httpRequest.ContentLength = Encoding.ASCII.GetByteCount(parameters);
   8: httpRequest.ContentType = "application/x-www-form-urlencoded";            
   9:  
  10: using (Stream requestStream = httpRequest.GetRequestStream())
  11: {
  12:     byte[] parametersBuffer = Encoding.ASCII.GetBytes(parameters);
  13:     requestStream.Write(parametersBuffer, 0, parametersBuffer.Length);
  14: }
  15: WebResponse httpResponse = httpRequest.GetResponse();

Añadir assemblies a Visual Studio

Muchas veces necesitamos que un assembly esté en el GAC para no estar preocupados de incluirlo en cada proyecto. Simplemente, lo seleccionamos de la ventana “Add Reference” de Visual Studio, y somos felices con ello. Sin embargo, esta semana pasada me surgió la necesidad de añadir un assembly al GAC por mí mismo.

AddReferenceWindow

No es que sea demasiado difícil, basta con copiarlo a c:windowsassembly. Hasta un tecnicoless podría hacerlo. Sin embargo, no apareció mágicamente en la ventana de Add Reference. ¿Qué había hecho mal? ¿Qué me faltaba? Buceando un poco por Internet encontré a un tipo explicando cómo hacerlo de 3 formas distintas.

Huelga decir que elegí la más sencilla: copiar mi assembly a C:Program FilesMicrosoft Visual Studio 9.0Common7IDEPublicAssemblies

Rearrancar el Visual Studio fue suficiente para ver mi assembly en la pestaña .NET. ¿Fácil no?

Usuarios, permisos y SQL Server

Recientemente me encontré ante la situación de tener que configurar, en un proyecto de Database de Visual Studio 2008, una serie de usuarios, permisos y roles.

En concreto, necesitaba crear un rol que pudiera ejecutar procedimientos almacenados y hacer SELECTs sobre un determinado esquema. A este rol, a su vez, pertenecería un usuario que también debía crearse dinámicamente en el script. Tras una mañana de investigación, estas son mis conclusiones.

Logins y Users

En SQL Server hay que distinguir entre Logins y Users. Los Logins se crean a nivel de servidor de base de datos. Pueden crearse como Logins de SQL Server, o pueden crearse a partir de una cuenta Windows, lo que en general es más seguro por utilizarse la autenticación integrada. En mi caso era precisamente eso lo que pretendía hacer, crearlos a partir de una determinada cuenta Windows. Esto es muy sencillo de hacer, basta un comando como el que se puede ver a continuación:

USE [yourdb]
GO
CREATE LOGIN [YourDomainYourUser] FROM WINDOWS
GO

Sin embargo, esto tiene una pega: no se puede hacer en los proyectos de base de datos de Visual Studio 2008, o al menos yo no he encontrado el modo. Tiene su sentido, de todas formas, puesto que estos proyectos no dejan de ser la creación de una base de datos concreta, y no debería afectar a la configuración del servidor en sí.

Una vez creado el Login, ya podemos crear un usuario y asociarlo a él. Esta parte sí se puede añadir al proyecto de BD de VS2008, en concreto en la carpeta Users dentro de Security. El TSQL necesario sería algo así:

CREATE USER [YourDomainYourDbUser] FROM LOGIN [YourDomainYourUser]
GO

Bien, con esto ya tendríamos nuestro usuario concreto de la base de datos creado, asociado a un Login a nivel del servidor.

Roles y permisos

El siguiente paso es crear el rol al que vamos a asociar el usuario que recién hemos creado. Este rol va a pertenecerle a dbo. No podemos darle sus permisos directamente en el script que se crea en la carpeta Database Roles de Security, esa parte tendremos que añadirla en un script de Post-deployment. Así que en el script de creación del rol simplemente tendríamos la siguiente sentencia TSQL:

CREATE ROLE [YourNewRole] AUTHORIZATION [dbo]
GO

Quedarían dos pasos por ejecutar: darle los permisos al rol que necesite y asociarle el usuario que creamos al principio.

La primera parte se completa con una sentencia parecida a ésta. Sería necesario indicar qué esquema de los existentes en la base de datos, va a poder el rol ejecutar sus SPs.

GRANT EXECUTE ON SCHEMA ::[YourSchema] TO [YourNewRole]
GO

En cuanto a la segunda, bastaría algo como lo que sigue, apoyándonos en uno de los procedimientos almacenados del sistema:

EXEC sp_addrolemember N'YourNewRole', N'YourDomainYourUser'
GO

Bibliografía: