Ho appena eseguito l'aggiornamento a Visual Studio 2010 e MVC 2.0 e ho notato che Web.config ha due file aggiuntivi allegati? Questi file vengono utilizzati per specificare impostazioni specifiche di debug e rilascio, in modo da non ingombrare il Web.config principale?
Ha anche senso inserire una stringa di connessione nel file Web.config radice se ne ho uno locale e uno remoto rispettivamente nel debug e nel rilascio Web.configs?
Grazie!
Risposte:
È la nuova funzionalità di trasformazione Web.config di Visual Studio 2010. Ulteriori informazioni qui .
Modificare:
Questi file vengono utilizzati per specificare impostazioni specifiche di debug e rilascio, in modo da non ingombrare il web.config principale?
Non è limitato a tre file, potresti (in teoria) avere tanti file quanti sono gli ambienti. Il Web.config "di primo livello" fornisce un modello della configurazione web. I file sottostanti forniscono valori di sostituzione specifici per quell'ambiente (come se si dispone di stringhe di connessione diverse per locale / stage / test / qualunque cosa).
Ha anche senso inserire una stringa di connessione nel file root web.config se ne ho uno locale e uno remoto rispettivamente nel debug e nel rilascio web.configs.
Avrebbe senso solo se non cambiasse tra gli ambienti. Sembra che nel tuo caso lo faccia, nel tuo caso no, non avrebbe senso lasciarlo nel Web.config.
Questi sono i file di trasformazione Web.config. Dalla distribuzione Web ASP.NET utilizzando Visual Studio: Web.config File Transformations :
Esistono due modi per automatizzare il processo di modifica delle impostazioni del file Web.config: trasformazioni Web.config e parametri di distribuzione Web. Un file di trasformazione Web.config contiene markup XML che specifica come modificare il file Web.config quando viene distribuito. È possibile specificare modifiche diverse per configurazioni di build specifiche e per profili di pubblicazione specifici. Le configurazioni di build predefinite sono Debug e Release ed è possibile creare configurazioni di build personalizzate. Un profilo di pubblicazione corrisponde in genere a un ambiente di destinazione.
Nel caso qualcuno sia interessato, ecco qualcosa che ho scritto per avere una stringa di connessione dinamica per ambiente. Volevo distribuire il codice a qualsiasi ambiente (Dev, Test, Pre-Prod, Prod ...) senza doversi preoccupare di cambiare le stringhe di connessione. Non sono riuscito a trovare un buon modo per farlo con Asp.Net MVC 4, quindi ho trovato il mio modo di fare affidamento su un file delle proprietà per ambiente.
Potrebbe esserci una soluzione migliore, vengo da un background Wicket / Java e di recente ho iniziato a sviluppare con MVC 4, quindi è possibile che esista una soluzione migliore. Ma ecco un collegamento alla mia domanda e risposta per una stringa di connessione dinamica:
Era qualcosa di molto necessario in VS. Purtroppo sembra esserci un problema con l'implementazione. Ad esempio, considera questo scenario (VS.2010 Ultimate, tutti gli SP):
web.Config
Web.Release.Config
Web.Debug.Config
Quando si esegue l'applicazione dà il seguente errore:
Il nome della connessione "test" non è stato trovato nella configurazione delle applicazioni o la stringa di connessione è vuota.
In altre parole, poiché gli elementi della stringa di connessione si trovano nei file di progettazione di rilascio / debug e utilizzati dagli elementi di configurazione nel file principale (Web.config), non è in grado di risolverlo.
testsia nel file di configurazione di debug che in quello di rilascio, dovrebbe essere solo nel web.config principale con le sezioni appropriate basate su modelli. Così com'è, stai duplicando il codice, che è qualcosa che il modello dovrebbe risolvere per te.
xsltcomandi di sostituzione espliciti . Complimenti per aver ottenuto 5 voti positivi per qualcosa che aggiunge confusione su questi file di trasformazione :)