TuriTip #27: Gestire diversi app.config in base alla configurazione di compilazione attiva (debug/release)

In ambiente di sviluppo un programmatore è solito usare servizi WCF hostati sulla propria macchina per effettuarne il debug.

Una volta che tali servizi WCF sono considerati “stabili” e quindi pronti per essere deployati su un server, occorre aggiornare le url del web.config o in questo caso, dell’app.config relative ai proxy di tali servizi. Purtroppo però, come spesso capita, il codice può essere soggetto a modifiche, nuove richieste, che richiederebbero un “downgrade” del nostro app.config, per far ri-funzionare il tutto in ambiente di sviluppo.

Di sicuro, l’opzione commenta/decommenta è la più veloce da implementare (ed anche la più pratica!). Ma per gli affezionati alla filosofia “clean-code”, trovarsi di fronte a tali cose nel codice, da quella sensazione di sporco che può essere risolta solo trovando una soluzione migliore al problema.

Ecco di seguito la soluzione che ho testato personalmente.

In particolare, ho una class library, che ha dei riferimenti a servizi WCF. Tali servizi, come ben sappiamo usano l’app.config per storare gli endpoint. Gli endpoint sono differenti in ambiente di debug e release. Mi sono creato quindi 2 app.config:

 image

Il primo è specifico per l’ambiente di debug, il secondo per l’ambiente di produzione.

Ora non ci resta che dire a VS quale usare in base al contesto di compilazione. Per ottenere ciò abbiamo necessità di agire tramite notepad sul file .csproj. In particolare:

   1: <PropertyGroup>
   2:   <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
   3:   <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
   4:   ....
   5:   <appConfig>App.Config</appConfig>
   6:   ....
   7: </PropertyGroup>

Dobbiamo dire in base al tipo di compilazione, quale file di configurazione usare tramite il tag “appconfig”.

Questa è la versione per la Release:

   1: <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
   2:   ....
   3:   <appConfig>App.Release.Config</appConfig>
   4:   ....
   5: </PropertyGroup>

 

Unica pecca è che, se abbiamo tutti i file di configurazione nominati diversamente da “app.config”, e proviamo ad aggiungere un servizio WCF tramite il wizard di VS, ci ricrea in automatico un file di configurazione di nome app.config e non fa il merge del nuovo endpoint nel file di configurazione già presente.

Un suggerimento, (grazie Fabio!) può essere quello di usare l’svcutil.exe per generare il proxy ed impostare le opzioni config e mergeConfig:

   1: svcutil.exe ... /config:nome.config /mergeConfig

In tal modo non sarà ricreato un nuovo file di configurazione ma sarà utilizzato quello passato come parametro all’svcutil.exe.

 

HTH

Published 12 Jan 2011 13:17 da Liccardi Antonio
Inserito sotto: , , ,
Powered by Community Server (Commercial Edition), by Telligent Systems