file specifici app.config/web.config per sviluppatori in Visual Studio

Question

Abbiamo diversi progetti .NET in cui vengono archiviate determinate impostazioni nei file di configurazione. Ora ogni sviluppatore avrà i propri file di configurazione che si differenziano un po '(diverse stringhe di connessione per la connessione a db locale, diversi endpoint WCF ecc)

Al momento si tende a controllare i file app/web.config e modificare loro per soddisfare i nostri bisogni. Questo porta a molti problemi poiché di tanto in tanto qualcuno controlla le proprie impostazioni o perde la configurazione personalizzata quando ottiene l'ultima versione da tfs.

La mia domanda è: come affrontare situazioni come questa? O non hai questo problema?

Answer 1

Utilizziamo machine.config per evitare differenze di web.config tra gli ambienti.

Answer 2

Come ignorare il file, quindi non viene mai archiviato? Ho riscontrato un problema simile e ho aggiunto web.config all'elenco di ignora in Subversion.

In TFS, tuttavia, è un po 'più difficile, vedere this post su come farlo.

Answer 3

Un modo per farvi fronte consiste nell'avere un sistema con token e utilizzare uno script rake per modificare i valori.

Un metodo più rudimentale potrebbe essere quella di avere un collegamento a un file AppSettings.config per tutti AppSettings nel web.config (simile con connessioni) cioè

<appSettings configSource="_configs/AppSettings.config" /> 

Poi avere una cartella con ciascuno dei vostri sviluppatori avere una versione in una sottocartella (es./_configs/dave /). Quindi, quando uno sviluppatore sta lavorando sul proprio codice, copia dalla sottocartella alla radice della cartella collegata.

È necessario accertarsi di comunicare le modifiche a questi file (a meno che non si chiami). Se si mantiene il file AppSettings.config fuori dal controllo del codice sorgente e si controllano solo le singole cartelle degli sviluppatori (tutte), saranno costretti a copiare quello corretto.

Preferisco la tokenizzazione ma può essere più difficile alzarsi e correre se questo è solo pensato per essere una soluzione rapida.

Answer 4

Nella vostra fonte utilizzo web.config da altri file

<configuration> 
    <connectionStrings configSource="ConnectionStrings.config" /> 
... 
</configuration> 

Tenere il web.config in controllo di versione e non farlo per ConnectionStrings.config. Ora tutti gli sviluppatori hanno un file per la stringa di connessione.

È possibile eseguire questa operazione per tutte le impostazioni dipendenti da locale.

Answer 5

Ignora i file e dispone di un Commom_Web.Config e Common_App.Config. Utilizzo di un server di integrazione continuo con attività di compilazione che rinominano questi due nomi normali in modo che il server di generazione possa svolgere il proprio lavoro.

Answer 6

Utilizziamo un sistema che combina diverse delle risposte esistenti in questa pagina, oltre a disegni su this suggestion by Scott Hanselman.

In breve, ciò che abbiamo fatto è stato avere un app.config/web.config comune e avere la maggior parte delle impostazioni specifiche in singoli file, come suggerito da altre risposte qui. per esempio. per le nostre impostazioni SMTP, l'app.config contiene

<system.net> 
    <mailSettings> 
    <smtp configSource="config\smtp.config" /> 
    </mailSettings> 
</system.net> 

Questo file è nel controllo del codice sorgente. Tuttavia, i singoli file, come questo, non lo sono:

<?xml version="1.0" encoding="utf-8" ?> 
<smtp deliveryMethod="Network"> 
    <network host="127.0.0.1" port="25" defaultCredentials="false" password="" userName ="" /> 
</smtp> 

Non è proprio questo il punto in cui finisce la storia. Che dire dei nuovi sviluppatori o di una nuova installazione di origine? La maggior parte della configurazione non è più nel controllo del codice sorgente, ed è complicato costruire manualmente tutti i file .config di cui hanno bisogno. Preferisco avere una sorgente che si compili almeno immediatamente.

Pertanto manteniamo una versione dei file .config nel controllo del codice sorgente, denominata .config.default file. Un albero sorgente fresca si presenta quindi come questo:

Eppure, non proprio alcuna utilità per lo sviluppatore, dal momento che per Visual Studio sono solo i file di testo senza senso. Da qui il file batch, copy_default_config.bat, si occupa di creare un set iniziale di file config dai file .config.default:

@echo off 
@REM Makes copies of all .default files without the .default extension, only if it doesn't already exist. Does the same recursively through all child folders. 
for /r %%f in (*.default) do (
    if not exist "%%~pnf" (echo Copying %%~pnf.default to %%~pnf & copy "%%f" "%%~pnf" /y) 
) 
echo Done. 

Lo script è tranquillamente ri-eseguibile, in quanto gli sviluppatori che hanno già la loro config i file non verranno sovrascritti. Pertanto, si potrebbe concepire questo file batch come evento pre-compilazione. I valori nei file .default potrebbero non essere esattamente corretti per una nuova installazione, ma sono un punto di partenza ragionevole.

In definitiva quello che ogni sviluppatore finisce con è una cartella di file di configurazione che sembra qualcosa di simile:

Può sembrare un po 'contorto, ma è sicuramente preferibile il fastidio di sviluppatori calpestare l'un l'altro le dita dei piedi.

Answer 7

Abbiamo lo stesso problema e quello che stiamo facendo è

• Verificare nel web.config con i valori testserver/produzione
• Developer va a Windows Explorer e cambiare la modalità di sola lettura del file
• Modifica la configurazione in base al loro ambiente.
• Il check in nel web.config si verifica solo quando i valori di distribuzione cambiano o qualsiasi voce di configurazione viene aggiunta o eliminata.
• questo ha bisogno di una buona quantità di commento per ogni voce di configurazione in quanto deve essere cambiato da ogni dev

Answer 8

Supponendo che si utilizza Visual Studio, perché non si utilizzano diverse configurazioni della soluzione? Ad esempio: è possibile avere una configurazione di debug che utilizza Web.config.debug e una configurazione di rilascio che utilizza Web.config.release. Web.config.debug dovrebbe avere qualcosa di simile

<appSettings file="C:/Standard_Path_To_Configs/Standard_Name_For_Config.config"> 

con il file Standard_Name_For_Config.config che GOTS tutte le impostazioni di sviluppo personali, mentre il Web.config.release ha sempre le impostazioni di produzione. È possibile memorizzare le configurazioni di default in una cartella controllata da fonte e farne un nuovo utente da lì.

Answer 9

Ecco una soluzione per i file web.config e Visual Studio 2010:

1) Modificare manualmente il file dell'applicazione Csproj web per aggiungere un target AfterBuild come questo:

<Project> 
    ... 
    <Target Name="AfterBuild"> 
     <Copy SourceFiles="web.config" DestinationFiles="obj\$(Configuration)\tempweb.config" /> 
     <TransformXml Source="obj\$(Configuration)\tempweb.config" 
        Transform="web.$(USERNAME).config" 
        Destination="obj\$(Configuration)\tempweb2.config" /> 
     <ReadLinesFromFile File="obj\$(Configuration)\tempweb2.config"><Output TaskParameter="Lines" ItemName="TransformedWebConfig"/></ReadLinesFromFile> 
     <ReadLinesFromFile File="web.config"><Output TaskParameter="Lines" ItemName="UnTransformedWebConfig"/></ReadLinesFromFile> 
     <Copy Condition=" @(UnTransformedWebConfig) != @(TransformedWebConfig) " SourceFiles="obj\$(Configuration)\tempweb2.config" DestinationFiles="web.config" OverwriteReadOnlyFiles="True" /> 
    </Target> 
    </Project> 

Questo obiettivo trasformerà il file Web.config corrispondente allo sviluppatore corrente loggato - da cui la variabile $(USERNAME) -, con il file corrispondente creato in 1). Sostituirà il web.config locale solo se il contenuto è stato modificato (per evitare il riavvio) ad ogni build, anche se il web.config locale è controllato all'origine, ecco perché lo OverwriteReadOnlyFiles è impostato su True. Questo punto in effetti è discutibile.

2) Creare un file denominato Web.[developer windows login].config per ogni sviluppatore nel progetto. (Ad esempio nei seguenti screenshot Ho due sviluppatori di nome SMO e smo2):

Questi file (1 per sviluppatore) può/deve essere fonte controllata. Non dovrebbero essere contrassegnati come dipendenti dal Web.config principale perché vogliamo essere in grado di controllarli singolarmente.

Ciascuno di questi file rappresenta una trasformazione da applicare al file Web.Config principale. La sintassi di trasformazione è descritta qui: Web.config Transformation Syntax for Web Application Project Deployment. Riutilizziamo questa fantastica attività di trasformazione dei file Xml che viene fornita con Visual Studio. Lo scopo di questa attività è unione elementi Xml e attributi invece di sovrascrivere l'intero file.

Per esempio, ecco un campione web.[dev login].config che cambia una stringa di connessione denominata 'MyDB', a prescindere dal resto del file web.config:

<?xml version="1.0"?> 
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> 
    <connectionStrings> 
     <add name="MyDB" 
     connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True" 
     xdt:Transform="SetAttributes" xdt:Locator="Match(name)" /> 
    </connectionStrings> 
</configuration> 

Ora, questa soluzione non è perfetta perché:

• dopo la costruzione, gli sviluppatori possono avere un web.Config diversa a livello locale rispetto al sistema di controllo del codice sorgente
• che possono avere per forza di scrittura locale quando ottenere una nuova web.Config dalle sys controllo del codice sorgente tem
• gli sviluppatori non dovrebbero effettuare il check out nel web.config principale. Dovrebbe essere riservato a poche persone.

Almeno, è sufficiente mantenere un unico web.config principale più un file di trasformazione per sviluppatore.

Un approccio simile potrebbe essere utilizzato per i file App.config (non Web) ma non ho elaborato ulteriormente.