Estuve en el Lambda World

Escribo estas líneas volviendo en tren desde Cádiz, una ciudad enigmática que me recuerda muchísimo a mi añorada Habana, tal vez porque la segunda se construyera basándose en la primera.

Cádiz, además de ser la ciudad que acogió la firma de la primera Constitución Española en 1812, ha acogido el pasado fin de semana el primer evento internacional de programación funcional celebrado en España, el Lambda World.

En este evento, ponentes de todas partes del mundo han venido a contarnos acerca de características de la programación funcional como mónadas, funciones puras, inmutabilidad, efectos secundarios, o sobre cómo llevar conceptos de programación funcional a programación orientada a objetos.

Para ello, hemos visto ejemplos en lenguajes como F#, C#, Java, Ruby, Swift, y, sobre todo, Scala. He aprendido muchísimo y aquí resumo algunos conceptos que me han llamado la atención y que me toca seguir estudiando.

La inmutabilidad, más complicada pero menos propensa a errores.

En programación orientada a objetos definimos clases con propiedades y comportamiento. Este comportamiento suele implicar un cambio en el estado del objeto.

Sin embargo, es justamente lo que queremos evitar en programación funcional, ya que trabajamos con objetos inmutables, con lo cual una vez creados, no cambia ninguna de sus propiedades.

Esto también se aplica a colecciones, y a los miembros de la misma, con lo cual la acción de añadir un objeto a una colección, o modificar un objeto de la misma requiere crear una nueva colección.

Con estos objetos inmutables lo que conseguimos asegurarnos que su estado no va a cambiar, y que no vamos a tener «sorpresas» cuando pasemos un objeto a un método que de repente modifique alguna de sus propiedades.

Sin embargo, aunque lenguajes como Swift, Scala o F# soportan inmutables por diseño, en el mundo clásico de la orientación a objetos, tanto para Java, C# o Ruby, es justamente al contrario, y queda de nuestra mano utilizar colecciones inmutables y definir manualmente nuestros objetos.

Las funciones puras no generan efectos secundarios, o casi

Otro concepto que se repitió bastante en el evento era el de función pura, que no es más que un método que recibe una entrada y devuelve una salida.

La magia de este concepto es que cuando lo combinamos con los objetos inmutables, conseguimos que para una entrada X tenemos la absoluta seguridad de que la salida será Y, SIEMPRE.

Esto nos permite, entre otras cosas, poder probar de manera rápida nuestras funciones si el lenguaje que estamos utilizando incorpora una consola REPL (Read Evaluate Print Loop), ya que una vez definida la función solamente tenemos que ejecutarla con los valores adecuados.

Los lenguajes funcionales no son algo solamente «académico»

Aunque los conceptos que nos muestren se acerquen bastante más a las matemáticas que a ensamblador, los ejemplos mostrados en aplicaciones móviles, sistemas cliente-servidor, arquitecturas funcionales y videojuegos, me dejaron bastante claro que la programación funcional está aquí para quedarse, y que ya estamos tardando, al menos, en aprender algunos de sus conceptos.

No tengo ni idea de lo que son las monads, creo.

Uno de los conceptos de programación funcional que se me escapa es el de las monads, que al parecer son tipos de datos con propiedades específicas, y uno de los ejemplos que veíamos en el evento era el del monad Either, que tiene dos tipos, Left o Right.

Con este monad podíamos definir el resultado de nuestra función, siendo Left un resultado de éxito, y Right una definición de un error, evitando flujos como captura de excepciones.

Este concepto tiene a su vez conceptos relacionados como monoids o functors… de los cuales tendré que leer, y mucho.

Podemos usar conceptos de programación funcional con lenguajes no puramente funcionales.

Conceptos como funciones puras u objetos inmutables son relativamente fáciles de implementar aunque los lenguajes no lo refuercen nativamente, sin embargo requiere un grado de disciplina mayor.

Sin embargo lenguajes como C# o Java van aportando cada vez más características de la programación funcional a su sintaxis, como las Lambdas y las colecciones inmutables. Aunque no es el escenario ideal para utilizar programación funcional, nos permite usar lo que ya sabemos.

Tenemos muchas maneras de empezar, aunque hay dos muy interesantes:

Por una parte tenemos lenguajes como Scala, en el que podemos desarrollar de la misma manera en la que lo veníamos haciendo hasta ahora, ya que soporta tanto tipos mutables como inmutables, e ir agregando características de la programación funcional a nuestros programas.

Por otra parte tenemos lenguajes F#, que nos permite lanzarnos al vacío, con una sintaxis que nos podría recordar cuando encadenamos la salida de distintos procesos en una shell de unix, que nos permite aprender programación funcional más «pura» y su interoperabilidad con C# nos permite agregar componentes funcionales a nuestro proyecto.

En resumen

Tenemos características como la inmutabilidad y las funciones puras que nos evitan sorpresas en nuestro código, podemos empezar migrando poco a poco a funcional o tirarnos a la piscina con lenguajes que solamente implementan este paradigma, y tenemos algo de soporte en nuestros lenguajes del día a día de algunos conceptos como las lambdas. Ha sido una experiencia muy enriquecedora, y espero veros en la siguiente edición de Lambda World

Mi paso por Frontiers, retrospectiva

Después de casi 10 meses de trabajo y con la vista puesta en un nuevo reto profesional, me despedí de la familia Frontiers como SCRUM recomienda, en una sesión de retrospectiva el pasado 7 de mayo. En este artículo me gustaría comentarte, a modo de resumen, mi experiencia como miembro de este equipo.

¿Qué es Frontiers?

Cuando ví la oferta empecé a investigar, y pude ver que era una empresa suiza, con sede en Laussane, que llevaba desde 2007 y que se dedicaba a la publicación de artículos científicos. La idea de trabajar «para la ciencia» me llamó la atención y decidí intentarlo.

Luego descubriría que la idea no era solamente publicar artículos, sino crear una red social alrededor de los mismos para poner en contacto a investigadores y científicos, en lo que se llamó Loop, y que fue el proyecto en el que estuve involucrado desde que pisé las oficinas.

¿En qué se desarrolla?

Para la red social nos apoyamos en tecnologías Microsoft, contando con un stack que iba desde SQL Server para la base de datos hasta ASP.net MVC y Web API para el frontal, utilizando C# como lenguaje de desarrollo.

Teníamos además cosas chulas como Rabbit MQ para comunicar diferentes sistemas y de lado del navegador, Knockout como framework JavaScript, y QUnit para pruebas unitarias.

Todo esto se coordinaba con diferentes sistemas de integración contínua en los que automatizabamos el despliegue en diferentes entornos de integración y las pruebas. Todo esto, a su tiempo, se iba integrando hasta llegar al ansiado entorno de producción. Esta parte, he de reconocer, que me resultaba particularmente interesante :)

¿Cómo funciona?

Utilizábamos SCRUM como metodología de desarrollo, y sus diferentes «ceremonias», una reunión de planificación antes de cada iteración, demo para mostrar los avances realizados, retrospectivas, y la sesión diaria donde veíamos los avances, y qué nos impedía seguir adelante.

Los equipos estaban formados, además de por los desarrolladores, por una persona de negocio, un QA y un SCRUM master que velaba porque todo estubiera bajo control.

Sin embargo en Frontiers había algo que no contemplaba SCRUM, y eran las comunidades. Una comunidad era un grupo formado por miembros de cada equipo, en los que se tomaban decisiones técnicas que afectaran a todos, para lograr también una sincronización a nivel técnico.

¿Cómo es el día a día?

A excepción de los días en los que teníamos planificación o demo, en los que una buena parte del día se nos iba en reuniones, nos dedicábamos diariamente a escribir código para arreglar bugs o crear características nuevas, mover postits (tareas) a diferentes estados en un panel que teníamos en la oficina o diseñar arquitecturas escribiendo en las paredes, ya que estaban recubiertas por una pintura especial que lo hacía posible.

Todo esto en jornadas que transcurrían entre las 8 de la mañana y las 5 de la tarde, donde la energía la proporcionaba el café proveniente de una máquina Nespresso que nos daba el oscuro brebaje sin coste.

Tras de la jornada laboral, los había que se quedaban para jugar al fútbol en unos campos que había cerca de la zona, otros coordinaban el huerto que teníamos, otros participábamos en carreras populares, los había que esquiaban, en general se promovía un estilo de vida bastante saludable, cervezas mediante una vez al mes :)

Agradecimientos

Mi experiencia en Frontiers no habría sido la misma sin mis compañeros del equipo MadOne, Ángel, nuestro Scrum Master, Iván, Carlos, María, Quique, Axel, que nos dejó para ver mundo, Cristina, nuestra QA, Charlie, Ramón, nuestro Product Owner y Adrián, nuestro Lead Designer, con los que, codo con codo, nos enfrentábamos a bugs, tareas nuevas y adversidades varias.

Además, Paola y Giovanni de Recursos Humanos, siempre estuvieron pendientes del equipo durante mi estancia y de que estuviera cómodo desde la fase de entrevistas hasta el momento de mi salida de la empresa.

Otra mención a los runners, en especial a Felipe, por algunos tips & tricks para poder lograr correr mi primera 10k (por cortesía de la empresa, por cierto!).

Finalmente un agradecimiento a Victor Mendez y Tobías Abarbanel, los responsables técnicos de la compañía y de los cuales he aprendido muchísimo estos meses. Gracias por la oportunidad de haber formado parte de esta familia, me lo pasé en grande.

Por cierto, Frontiers sigue buscando gente.

Nuevo hangout el próximo 10 de febrero: Experiencias del mundo real con Xamarin

Actualización: Aquí tienes el vídeo del evento:

Vuelven los hangouts en 2015! Tras el parón de navidades y la cuesta de enero volvemos con desarrollo móvil usando C# en otras plataforma no Microsoft. Veremos de primera mano algunas experiencias que han tenido nuestso invitados con proyectos y aplicaciones reales.

Además tenemos la suerte de contar no con uno, sino con dos miembros del equipo de desarrollo de Xamarin para darnos su visión desde el otro lado. Dos horas que seguro que se nos quedan cortas.

La cita es el próximo 10 de febrero a las 20:00 GMT+1 en Google Hangouts: https://plus.google.com/events/c8ojlcgbi8gtsseulj331hpu5eo.

Desarrollo móvil multiplataforma con Xamarin

Contamos con el siguiente panel para el debate:

  • Jose Miguel Torres: Desarrollador en Xamarin
  • Rodrigo Moya: Desarrollador en Xamarin y colaborador del proyecto Gnome
  • Francesc Jaumot: Desarrollador y CEO en Clibb
  • Josue Yeray: Desarrollador independiente y MVP de Microsoft
  • Javier Suarez: Desarrollador independiente y MVP de Microsoft
  • Juan Carlos Quijano: Desarrollador independiente
  • Un servidor, que no se pierde una

En esta ocasión nos acompaña una vez más Syncfusion, así que si vienes puedes llevarte una licencia de uno de sus productos de manera completamente gratuita.
Te esperamos allí!

Si no puedes asistir lo dejaremos grabado en cuanto finalice el evento.

Vídeo: ASP.NET vNext en 10 minutos

En este vídeo resumo tres de las características de las que hemos hablado en Hangouts y en eventos como los de MSCoders, que son el Core CLR, la inyección de dependencias y la configuración a través de ficheros JSON.

Para más artículos relacionados, puedes encontrar información con la etiqueta vnext de este blog.

8 preguntas (y respuestas) sobre ASP.NET vNext

Ayer, en las oficinas de Microsoft España estuve en una mesa redonda con el grupo de MSCoders Madrid, continuando la conversación del pasado hangout e intentando resolver las posibles dudas que genera la nueva versión de ASP.NET.

Entre todas las cosas que se plantearon, tomé nota de varias preguntas para intentar responderlas en esta artículo:

¿Qué compatibilidad tengo?

Por una parte hemos de distinguir dos elementos diferentes, el Full .NET CLR, que es como teníamos .NET hasta ahora, y el Core CLR, que es la nueva versión optimizada para web, multiplataforma, y que incluye las dependencias en nuestras aplicaciones.

Por su propia naturaleza, el Core CLR está más limitado (temas como el registro de windows o el acceso al event logger no son posibles con el mismo) pero si usamos el Full .NET CLR podremos utilizar muchas de las ventajas de las ventajas de la nueva plataforma sin perder compatibilidad con proyectos existentes.

¿Qué pasa con Webforms?

La tecnología detrás we WebForms sigue teniendo una dependencia muy fuerte con System.Web, y pese a que se ha anunciado cierto soporte por parte de vNext, lo más probable es que neceitemos el Full CLR para hacer uso de Web Forms, perdiendo las ventajas del Core CLR.

¿Seguro que requiere Mono?

De acuerdo con el equipo de desarrollo, la dependencia de Mono es, de momento, temporal, así comentan en el artículo de introducción a MVC5, Microsoft pondrá a disposición de los desarrolladores una versión del CLR que será independiente del proyecto Mono, como se comenta a continuación:

We will release a cross-platform runtime for Linux and Mac OS X. When released, this runtime will enable you to develop and run .NET apps on Mac and Linux devices. We will work closely with the Mono community on this effort. Until its release, you can use the Mono CLR for cross-platform development. 

¿Significa esto que Mono tal y como lo conocemos deja de existir?

No, además de desarrollo web, Mono permite hacer desarrollo de aplicaciones de consola, y de aplicaciones de escritorio en linux mediante GTK# y en Mad a través de Xamarin. De acuerdo con el artículo publicado en el blog del proyecto Mono la integración permitirá al proyecto avenzar en la parte común.

El resto de adaptación de APIs nativas, como puede ser una abstracción del registro de Windows, o el trabajo hecho hasta la fecha con WinForms, quedan fuera de .NET Core y la comunidad Mono seguirá trabajando en el soporte para los mismos.

¿Qué pasa con CoreCLR y Entity Framework, funciona?

La primera versión compatible con CoreCLR será a partir de Entity Framework 7, que supone un cambio tan radical sobre EF6 como el que hemos visto con ASP.NET, y que está actualmente en fase de desarrollo, como podemos ver en su wiki.

Lo que sí sabemos y podemos comprobar echando un vistazo a las issues reportadas en Github es que se está trabajando en ello, con lo cual podemos estar seguros que tendremos una versión de Entity Framework con CoreCLR.

¿Pero, si los ficheros ahora no pertenecen al proyecto, puedo ocultar carpetas del solution explorer?

En el estado actual de las herramientas, no. A partir de la CTP4 de Visual Studio 14 (ahora Visual Studio 2015) el fichero kProj no guarda registro de los ficheros, sino que se lee directamente el contenido de la carpeta.

Veremos qué ocurre con las siguientes Previews de la herramienta, ya que el soporte para el tooling es bueno, pero tiene aún cierto margen para la mejora.

¿Finalmente, puedo integrar Grunt como parte de mi proceso de release y publicación?

Sí, de hecho los chicos de Microsoft Open Tech tienen un artículo corto pero muy conciso sobre cómo podemos configurar grunt en nuestro TFS

¿Donde puedo encontrar más información?

Hangout: ASP.net vNext, qué cambia y cómo nos afecta

vNext

EL próximo miércoles 19 de noviembre a las 20h (GMT + 1) nos volvemos a juntar Juan Quijano (@jc_quijano), Eduard Tomás (@eiximenis) y un servidor (@rlbisbe), para comentar las novedades de ASP.net vNext.

Durante unas dos horas comentaremos qué cambios trae la nueva version de ASP.net así como las novedades presentadas en el evento Connect que se celebra hoy en Nueva York. Repite como patrocinador Syncfusion, que al igual que en ediciones anteriores, nos ofrece una licencia de uno de sus productos para los asistentes al evento, y como novedad, además de usar Twitter con el hashtag #vienevnext, podrás enviarnos tus dudas y comentarios desde el propio Hangout.

Apúntate ya en: Hangouts on Air: ASP.net vNext, qué cambia y cómo nos afecta

Resumen de atajos de teclado de Visual Studio

Una de las sesiones que me resultaron más interesantes en el pasado TechEd 2014 fue la de Tips and Tricks de Visual Studio con Tarek Madkur.

En ella, comentaba un montón de atajos de teclado que nos proporciona Visual Studio para mejorar nuestra productividad. En este artículo resumo brevemente las que más me han llamado la atención:

Ctrl + Q: Quick Launch

Este menú nos permite acceder, desde el teclado, a todas las ventanas auxiliares, opciones de configuración y elementos del menú del IDE. Ventanas como por ejemplo el «Package Manager Console» de Nuget, o ventanas como el Test Explorer, sin tener que estar buceando por las opciones del IDE.

Ctrl + K, X: Insertar snippet

Una herramienta muy útil cuando queremos reutilizar trozos de código llamados snipets. Este atajo nos muestra la lista de snipets instalados en nuestro sistema, y nos permite insertarlos de manera inmediata.

Alt + Shift + Enter: Pantalla completa

La pantalla completa es una vista que nos permite centrarnos en una (o varias) secciones de código, o cuando queremos mostrar código a alguien (por ejemplo, en una charla).

Ctrl + F4: Cerrar documento

Nos permite cerrar los documentos abiertos dentro del entorno de visual studio.

Shift + Esc: Ocultar ventanas

Nos permite cerrar otras ventanas como Output o Search Results, sin que ello afecte al layout actual.

Ctrl + Alt + O: Convertir en documento normal

Convierte un documento cargado en modo «preview» (el que se activa cuando hacemos click en un documento o cuando estamos navegando usando F12) en un documento normal.

Alt + F12: Peak navigation

El comando F12 nos permite navegar a la definición de un método o una clase, pero podemos perder el contexto, así que con esta opción podemos mantener el contexto y poder navegar a la definición. Lo más curioso es que podemos, dentro del menú de Peak navigation, continuar navegando

Extra! Más atajos de teclado!

El ilustre Gorka Madariaga (@Gk_8) aporta estos tres atajos:

Ctrl+C

En una linea sin seleccionar nada te la copia entera, idem para Ctrl+X o Ctrl+V (te la pega completa en la linea de arriba).

Ctrl+K, C

Comenta la linea en la que estas entera si no seleccionas nada o lo que tengas seleccionado, Ctrl+K, U hace lo inverso del anterior.

Ctrl+K, D

Para dar formato a todo el archivo o a lo que tengas seleccionado.

Conclusiones

Esta es una lista bastante corta de atajos de teclado, Visual Studio cuenta con una opción en el menú para poder listar todos los atajos, las opciones a las que están asignados, y asignarnos nuestros propios atajos (Por ejemplo, yo tengo configurado Ctrl + < para ejecutar mis test de Javascript)

Más información

Si quieres ver estas y más, te recomiendo la charla de Tarek Madkour en el TechEd 2014: https://channel9.msdn.com/Events/TechEd/Europe/2014/DEV-B348

Materiales del evento: Sevilla Mobility Day Strikes Back

El pasado sábado 26 de octubre con motivo de la segunda edición del Sevilla Mobility Day tuve la ocasión de dar una pequeña charla sobre las diferentes opciones de comunicación que tienen nuestras apps con el exterior:

IMG_5474

Slides

Las slides están disponibles a continuación en slideshare:

Demos

Por otra parte, las demos están disponibles en el siguiente enlace de Github:

https://github.com/rlbisbe/demos_charla_conectividad_wp

Enlaces

Y finalmente, la lista de enlaces que usé (entre otros) para preparar la charla:

Gracias los chicos de @cartujadotnet por la invitación, a CampusMVP por el patrocinio, al servicio técnico de Pebble por intentar echarme una mano, a mi querida Patrica Vasco (Patu) por ayudarnos con las fotos y en general a todos los que hicieron el evento posible.

Vídeo: Lo que viene con C# 6

En este evento tuvimos la ocasión de juntarnos varios entusiastas de tecnologías Microsoft para comentar lo que viene con la nueva versión de C# y Visual Studio 14, así como las novedades a nivel de compilador con Roslyn. Además tuvimos la posibilidad de contar con Syncfusion como patrocinador estrella, que ofreció una licencia de su producto Essential Studio Enterprise Edition a un asistente.

Tras una introducción a cómo poner a punto un Visual Studio 14 para empezar a jugar por parte de Juan Quijano (@jc_quijano) usando las máquinas virtuales de Azure, el ilustre Eduard Tomás (@eiximenis) y un servidor nos metíamos en harina para repasar algunas de las características que trae esta nueva versión del lenguaje.

Entre las novedades destacan la propagación de nulos, los constructores principales, o la inicialización de variables dentro de bloques, y por otro lado, de manera un tanto negativa también para los asistentes, de la importación de métodos de clases estáticas.

En el segundo bloque, de mano de Juan Manuel Servera (@jmservera) vimos cómo podemos extender las capacidades de Visual Studio a través de Roslyn, para agregar más capas o reglas a nuestro propio código, ofreciendo además la posibilidad de dar sugerencias a los desarrolladores, y todo esto en un paquete nuget que puede formar parte de nuestro código fuente.

Se avecinan tiempos muy interesantes en el desarrollo de IDEs.

Antes de terminar, no quería dejar de compartir algunas estadísticas del evento:

  • 10 +1s en la página del evento
  • 24 asistentes de máxima
  • 32 personas han visto el evento, de acuerdo con su estatus en la página de Google Plus.
  • 85 tweets (incluyendo retweets) con el hashtag #vienecsharp6, «oficial» del evento, de acuerdo con las estadísticas de Topsy
  • 108 visitas a la página del evento, de acuerdo con las estadísticas de Karmacracy.
  • 124 visualizaciones del vídeo en Youtube en este momento.

Finalmente, en el vídeo comentamos algunos enlaces que se muestran a continuación:

Muchas gracias a los ponentes por hacer el evento posible, a nuestro patrocinador por el apoyo y finalmente a todos los asistentes.

Editando las connection strings «en caliente» de un proyecto ASP.net

Un problema peculiar con el que me he encontrado recientemente tiene que ver con dos equipos con la misma base de código y un punto de sincronización común, que en este caso es o bien dos bases de datos distingas del mismo servidor, o a la misma base de datos con diferentes credenciales, en un gráfico como el que se muestra.

Capture

Para guardar la configuración de la base de datos recurrimos habitualmente al apartado connectionStrings de nuestro fichero web.config. Dicho fichero cuenta además con diferentes transformaciones según la configuración de build seleccionada, como muestra la siguiente imagen:

Capture_debug

Pero… las transformaciones solamente se ejecutan al desplegar un proyecto…

El hecho de no poder ejecutar las transformaciones en tiempo de compilación no nos permite depurar nuestra solución con las cadenas de conexión necesarias, y, aunque existe una manera de transformar el fichero web.config durante la compilación, quería buscar una aproximación diferente.

Editando el objeto ConnectionStrings

Dentro del código de nuestra aplicación disponemos del objeto ConfigurationManager.ConnectionStrings que nos da una colección de solo lectura en la que podemos acceder a los datos. Si intentamos escribir en dicha colección obtenemos la siguiente excepción:

An exception of type 'System.Configuration.ConfigurationErrorsException' occurred in System.Configuration.dll but was not handled in user code

Additional information: The configuration is read only.

Sin embargo si vamos al código fuente de ConnectionStrings veremos que el atributo connectionString tiene setter, con lo cual en teoría podemos fijar el valor:

public string ConnectionString {
    get {
        return (string)base[_propConnectionString];
    }
    set {
        base[_propConnectionString] = value;
    }
}

Si vamos un poco más abajo nos encontraremos con la clase ConfigurationElement, cuyo método IsReadOnly() se comprueba al intentar fijar un valor.

protected void SetPropertyValue(ConfigurationProperty prop, object value, bool ignoreLocks) {
if (IsReadOnly()) {
    throw new ConfigurationErrorsException(SR.GetString(SR.Config_base_read_only));
}

public virtual bool IsReadOnly() {
    return _bReadOnly;
}

Este valor IsReadOnly lee una variable _bReadOnly, y no sería maravilloso que pudiéramos editar esa variable y editar nuestras cadenas de conexión? Pues gracias a Reflection podemos hacerlo!:

ConnectionStringSettings connectionString = ConfigurationManager.ConnectionStrings[0];
var field = typeof(ConfigurationElement).GetField("_bReadOnly", BindingFlags.Instance | BindingFlags.NonPublic);
field.SetValue(connectionString, false);
connectionString.ConnectionString = "CustomConnectionString";
field.SetValue(connectionString, true);

Tras nuestra edición podemos volver a establecer el atributo _bReadOnly a true restaurando el bloqueo de la escritura. Hemos de tener en cuenta que este proceso ha de realizarse lo antes posible en nuestra aplicación, así que yo usaría Startup.cs o Global.asax.cs (recordemos que este último desaparece con ASP.net vNext).

Cargando nuestras connection strings personalizadas

Una vez que sabemos que podemos cargar las connection strings en caliente, el siguiente paso es cargar el fichero que contiene las transformaciones:

string path = HostingEnvironment.MapPath("~/Web.TEAM1.config");
XmlDocument doc = new XmlDocument();
doc.Load(path);
XmlNodeList list = doc.DocumentElement.SelectNodes(string.Format("connectionStrings/add[@name='{0}']", "Title"));
XmlNode node = list[0];
string connectionStringToReplace = node.Attributes["connectionString"].Value;

En este caso cargamos el fichero de TEAM1, buscamos la cadena de conexión con la clave especificada y la asignamos a la variable connectionStringToReplace.

Código completo

private void ReplaceConnectionStrings(string team)
{
    string path = HostingEnvironment.MapPath(string.Format("~/Web.{0}.config", team));
    XmlDocument doc = new XmlDocument();
    doc.Load(path);

    foreach (ConnectionStringSettings connectionString in ConfigurationManager.ConnectionStrings)
    {
        XmlNodeList list = doc.DocumentElement.SelectNodes(string.Format("connectionStrings/add[@name='{0}']", connectionString.Name));
        if (list.Count == 0) continue;

        XmlNode node = list[0];

        var field = typeof(ConfigurationElement).GetField("_bReadOnly", BindingFlags.Instance | BindingFlags.NonPublic);
        string connectionStringToReplace = node.Attributes["connectionString"].Value;

        field.SetValue(connectionString, false);
        connectionString.ConnectionString = connectionStringToReplace;
        field.SetValue(connectionString, true);
    }
}

Este código recorre todas las Connection Strings, y si encuentra una en nuestro fichero de transformaciones, la reemplaza.

Finalmente, directivas de preprocesador

Las configuraciones de Build nos permiten fijar ciertas directivas a nuestros proyectos, y estas directivas se aplicarán en tiempo de compilación. De esta manera si alguna de las dos claves está presente se sustituirán, en caso de que ninguna esté presente no se realizará una sustitución.

#if TEAM1
    ReplaceConnectionStrings("TEAM1");
#elif TEAM2
    ReplaceConnectionStrings("TEAM2");
#endif

A continuación se pueden ver dos ejemplos para los diferentes equipos.

Capture_team1

Capture_team2

Conclusiones

Esta solución nos da una manera efectiva de poder depurar nuestro código sin afectar el ciclo de vida del fichero web.config, sus transformaciones, y el comportamiento por defecto. El código agregado solamente se ejecutaría en caso de que alguna de las dos directivas se cumpliese, con lo cual podemos tener diferentes configuraciones para diferentes equipos.

Reflection es una característica que nos permite sacar mucho más de lo que un objeto nos ofrece públicamente, a costa de un impacto en rendimiento y requerir un mayor conocimiento de lo que estamos haciendo, de ahí a que se use con moderación.

Enlaces adicionales