Transformando web.config (o app.config) para depuración

Una de las características más interesantes de los ficheros web.config, es que al publicarlos podemos aplicar una serie de transformaciones a los mismos, de tal manera que ciertos datos que estén en depuración no lleguen en modo release, y viceversa.

Sin embargo, hay casos en los que nos puede ser útil tener varios ficheros config para las diferentes configuraciones de build. En mi caso, desarrollando RealPoll, me di cuenta que esto podría ser interesante, y he creado tres configuraciones:

Debug_FakeDB
Debug_LocalDB
Debug_RemoteDB

Para cada una de las opciones tengo un fichero web.config diferente. El problema es que la transformación solamente se aplica al publicar, y no en el proceso de depuración, por lo tanto son poco útiles estos perfiles. Sin embargo, buscando un poco en internet encontré este artículo en CodeProject en cuyos comentarios estaba la respuesta a mi problema, modificar (a mano) el fichero csproj y agregar la siguiente directiva tras la compilación (tenemos un ejemplo comentado al final de nuestro proyecto):

<Target Name="AfterBuild">
   <TransformXml Source="Web.Base.config" Transform="Web.$(Configuration).config" Destination="Web.config" StackTrace="true" />
 </Target>

Una vez agregada, deberemos entonces duplicar la información de nuestro web.config (o app.config si desarrollamos una aplicación de escritorio) en un fichero llamado web.base.config (por ejemplo), ya que tras cada compilación el fichero web.config se regenerará.

Dentro de cada fichero de configuración, tenemos diferentes opciones. En el caso de debug_fakedb se agrega una clave a appsettings, que luego consulto al inicializar mi código:

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <appSettings>
    <add xdt:Transform="Insert" key="FakeDB" value="true" />
  </appSettings>
</configuration>

Esta clave luego la consulto a la hora de inicializar el código:

if (string.IsNullOrEmpty(ConfigurationManager.AppSettings["FakeDB"]) == false)
    Current.Bind<IQuestionRepository>().To<FakeQuestionRepository>();

else
    Current.Bind<IQuestionRepository>().To<DBQuestionRepository>();

Lo bueno de dejar estos valores en claves de configuración es que nos permite hacer cambios «en caliente» sin tener que recompilar la aplicación, como bien recomendaban Andy Hunt y Dave Thomas en su «Pragmatic Programmer».

En el caso de localDB agregamos la información de Entity Framework (que ya sabrá que hacer):

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <entityFramework xdt:Transform="Insert">
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
      <parameters>
        <parameter value="v11.0" />
      </parameters>
    </defaultConnectionFactory>
  </entityFramework>
</configuration>

Finalmente, para el caso de remoteDB, agregamos la información de Entity Framework, así como la cadena de conexión (que más adelante se sustituye en azure):

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <connectionStrings xdt:Transform="Insert">
      <add name="QuestionContext"
           connectionString="YOUR_CONNECTION_STRING_HERE"
           providerName="System.Data.SqlClient" />
  </connectionStrings>
  <entityFramework xdt:Transform="Insert">
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework"/>
    <providers>
      <provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" />
    </providers>
  </entityFramework>
</configuration>

Para mí supone un ahorro considerable de tiempo y esfuerzo, además de que me permite probar las diferentes configuraciones sin recompilar.

Si quieres verlo en ejecución, echa un vistazo al código de Realpoll en github del que hablaré muy, muy pronto.