Usa la trasformazione web.config di Visual Studio per il debug

Possibile duplicato:
Come posso utilizzare Web.debug.config nel server di debugger di Visual Studio integrato?

Voglio usare la trasformazione Web.config che funziona bene per pubblicare anche per il debug.

Quando pubblico un’app Web, Visual Studio trasforma automaticamente Web.config in base alla configurazione del mio currenctbuild. Come posso dire a Visual Studio di fare lo stesso quando avvio il debug? All’avvio di debug utilizza semplicemente Web.config predefinito senza trasformazione.

Qualche idea?

OK, con la consapevolezza che web.debug.config e web.release.config sono solo per pacchetto / pubblicazione. Ho trovato un modo per abilitare ciò che stai cercando di fare. Ne ho parlato su http://sedodream.com/2010/10/21/ASPNETWebProjectsWebdebugconfigWebreleaseconfig.aspx . Ecco il riassunto.

Ora vediamo come possiamo abilitare ciò che il richiedente chiede.

Per ricapitolare, quando costruisce su una particolare configurazione, vuole che una specifica trasformazione sia applicata a web.config . Quindi ovviamente non si vuole mantenere un file web.config , perché verrà sovrascritto.

Quindi quello che dobbiamo fare è creare un nuovo file web.template.config , che è solo una copia di web.config . Quindi basta eliminare web.config usando Windows Explorer (non eliminare usando Visual Studio perché non vogliamo cancellarlo dal progetto).

Nota: se si utilizza un provider di controllo del codice sorgente integrato in Visual Studio, è probabile che si desideri eliminare web.config dal controllo del codice sorgente.

Inoltre con questo non vogliamo usare web.debug.config o web.release.config perché questi hanno già un ruolo ben definito nella Pipeline di Pubblicazione Web, quindi non vogliamo disturbarlo. Quindi, invece, creeremo due nuovi file, nella stessa cartella del progetto e web.template.config , web.dev.debug.config e web.dev.release.config .

L’idea è che queste saranno le trasformazioni applicate quando esegui il debug o esegui la tua applicazione da Visual Studio. Ora dobbiamo agganciare il processo build / package / publish per ottenere tutto ciò cablato. Con Web Application Projects (WAP) esiste un punto di estensibilità che è ansible creare un file di progetto nella stessa cartella con il nome {ProjectName}.wpp.targets dove {ProjectName} è il nome del progetto. Se questo file si trova su un disco nella stessa cartella del WAP, verrà automaticamente importato nel file di progetto. Quindi ho creato questo file. E ho inserito il seguente contenuto:

         $(PrepareForRunDependsOn); UpdateWebConfigBeforeRun;                

Lascia che ti spieghi un po ‘. Ho creato la destinazione CopyWebTemplateConfig che copierà sempre web.template.config su web.config su build, anche se non esegui il debug dell’applicazione in Visual Studio.

Questo è necessario perché dobbiamo ancora supportare il processo package / publish di Visual Studio. Quindi ho esteso la proprietà PrepareForRunDependsOn per includere la destinazione UpdateWebConfigBeforeRun . Questa proprietà viene utilizzata per identificare l’elenco di target che deve essere eseguito prima che qualsiasi progetto gestito venga eseguito da Visual Studio.

In questo objective sto utilizzando l’attività TransformXml per trasformare web.template.config , utilizzando il file di web.dev.***.config corretto di web.dev.***.config . Successivamente, l’app si avvia utilizzando il web.config corretto in base alla configurazione di build. Dopo di che ho un altro objective ExcludeCustomConfigTransformsFiles , che io ExcludeCustomConfigTransformsFiles nel processo package / publish tramite l’attributo BeforeTargets=”ExcludeFilesFromPackage” . Questo è necessario perché non vogliamo che questi file vengano inclusi quando l’applicazione è pacchettizzata o pubblicata. Quindi questo è davvero tutto quello che c’è da fare.

Per spiegare il processo pacchetto / pubblicazione un po ‘di più per questo scenario. Quando si impacchetta / pubblica web.debug.config o web.release.config , a seconda della configurazione di build, verrà comunque utilizzato. Ma alla fine il file che sta trasformando è web.template.config , quindi potrebbe essere necessario modificare a seconda di ciò che si ha in quel file. Domande / Commenti?

Andrew è sulla strada giusta. Quando si utilizza questa funzione, ecco come è stata progettata per essere utilizzata.

web.config Questo è il file di configurazione che gli sviluppatori dovrebbero usare localmente. Idealmente dovresti ottenere questo standardizzato. Ad esempio potresti usare localhost per le stringhe DB, e cosa no. Dovresti cercare di farlo funzionare su macchine di sviluppo senza modifiche.

web.debug.config Questa è la trasformazione che viene applicata quando si pubblica l’applicazione nell’ambiente di gestione temporanea di sviluppo. Ciò renderebbe le modifiche a web.config che sono richieste per l’ambiente di destinazione.

web.release.config Questa è la trasformazione che viene applicata quando si pubblica l’applicazione nell’ambiente di “produzione”. Ovviamente dovrai stare attento con le password a seconda della tua applicazione / squadra.

Il problema con la trasformazione di web.config attualmente in esecuzione è che una trasformazione può eseguire azioni distruttive su web.config. Ad esempio, può cancellare attributi, eliminare elementi, ecc.

Si potrebbe semplicemente usare il web.config ‘default’ come versione di sviluppo / debug, e quindi web.release.config ovviamente continuerà ad essere la versione di rilascio, dal momento che le sue trasformazioni vengono applicate al momento della pubblicazione.

Nella configurazione di debug, aggiungi un passaggio post-build e usalo per sostituire / trasformare il tuo web.config

Anche se sono d’accordo sul fatto che l’approccio più semplice è solitamente il migliore, posso facilmente immaginare una circostanza in cui per un certo periodo di tempo si desidera colbind l’IDE a un database di test anziché al database di sviluppo. Sebbene sia ansible specificare lo sviluppo di stringhe di connessione nel proprio file web.config predefinito, sarebbe davvero bello avere un file Web.Test.config in modo che quando si scambiasse la configurazione della build in “Test”, si otterrebbero automaticamente le nuove impostazioni mentre sei ancora nel tuo IDE.

L’alternativa storica sta commentando un insieme di stringhe di connessione per un altro, ma queste nuove trasformazioni di configurazione hanno tenuto la speranza di mettere finalmente un palo nel cuore di quella brutta pratica. Sebbene un file predefinito per lo sviluppo e una trasformazione per la release possano funzionare molto del tempo, aggiungere una fase post-build per trasformare il file web.config è la risposta più completa a mio parere.