Come dovrei usare la modalità debug/release in Visual Studio?

Question

Di solito collaudo il mio codice localmente sul mio computer di lavoro, quindi lo trasferisco nell'ambiente di sviluppo e infine nell'ambiente di produzione. Qual è il modo migliore di utilizzare la modalità debug/release per questo scenario? Devo solo preoccuparmi della modalità di debug nella mia macchina? Devo pubblicare la modalità di debug o la modalità di rilascio per lo sviluppo? So che probabilmente dovrei pubblicare utilizzando la modalità di rilascio per la produzione. In realtà non ho prestato molta attenzione a tutto questo, quindi ho continuato a lavorare solo in modalità di debug tutto il tempo, che so che non dovrei.

Modifica: Grazie per le risposte. Sembra che sia una buona idea usare solo la modalità di debug nella mia macchina. Anche se è nella macchina di sviluppo, è fondamentalmente rilasciato al pubblico (collaboratori, qa) quindi dovrebbe essere in modalità di rilascio. E naturalmente dovrebbe essere la modalità di rilascio quando si rilascia a prod.

Answer 1

Quando si rilascia/pubblica un'applicazione, è necessario farlo in modalità di rilascio. La modalità di rilascio è proprio per questo, rilasciando le applicazioni. Il codice prodotto è in genere più performante e molti rimuovono molti controlli che sono più associati alla fase di sviluppo di un'applicazione.

In una giornata tipo, si dovrebbe sviluppare in modalità di debug. La maggior parte delle lingue inserisce controlli extra in un'applicazione in modalità di debug. Questi individuano più bug ma tendono a rallentare leggermente l'applicazione.

Tuttavia, è necessario eseguire anche siginificanti test della modalità di rilascio come parte del processo di sviluppo. I clienti vedranno solo la versione del tuo prodotto in versione Release ed è possibile che i bug siano specifici della modalità debug/release. Le verifiche di bug inserite in modalità debug possono introdurre effetti collaterali che nascondono bug reali nella tua applicazione.

Answer 2

In generale, distribuire SEMPRE le build di Release alla produzione. Il debug si sommerà al peso dell'assieme e ridurrà le prestazioni.

Se si stanno sviluppando applicazioni ASP.NET, la modalità Debug attivata modifica effettivamente la modalità di compilazione delle pagine da parte del compilatore JIT e riduce significativamente le prestazioni per aggiungere una migliore capacità di debug interattivo.

Per quanto riguarda la build da distribuire allo sviluppo ... se si eseguono test unitari contro lo sviluppo, è probabilmente una buona idea distribuire il build di Debug in modo da poter ottenere le informazioni più debug quando i test falliscono o si verificano eccezioni . Tuttavia, si spera che ci sia un ulteriore ambiente di test o di preproduzione in cui è possibile eseguire i test di integrazione e eseguire test manuali. L'ambiente di testing/pre-produzione DEFINITIVAMENTE dovrebbe utilizzare Release builds in modo da poter vedere i veri problemi di perfomance e compilation prima di andare in produzione.

Se non si dispone di questo livello intermedio di test/pre-produzione, suggerirei di eseguire l'ambiente Dev con Release. In altre parole, è necessario eseguire almeno un livello prima della produzione nella configurazione di rilascio.

Per ulteriori informazioni su cosa è possibile fare con le configurazioni, ho un post specifico per Silverlight (http://blog.tonyheupel.com/2009/04/environment-specific-service-references.html). In c'è un collegamento all'articolo più generico di Scott Hanselman sulle configurazioni di build e ambienti diversi.

Answer 3

Per impostazione predefinita, la build di rilascio verrà compilata con più opzioni di ottimizzazione, il che si tradurrà in un codice più veloce e più piccolo, che in genere è quello che si desidera rilasciare ai clienti (da cui il nome). T

Il debug build non esegue quasi nessuna ottimizzazione, il che significa che quando si utilizza il debugger, il codice macchina sottostante corrisponde più strettamente al codice sorgente, che assiste con il debug.Inoltre, la compilazione di debug per impostazione predefinita inserisce controlli extra del codice di runtime che cattureranno errori comuni come l'accesso a membri di array non dotati di tecnologia.

Nota che è possibile creare build di rilascio con i simboli di debug, diventa solo più difficile per il debugger eseguire il mapping dell'istruzione corrente nel codice macchina alla riga di origine appropriata.

Answer 4

seguo questo approccio:

• codice/ciclo di debug sulla mia workstation: DEBUG
• esecuzione di unit test sulla mia workstation: DEBUG
• profilazione sulla mia workstation: RELEASE
• durante la notte costruire e test automatici: RELEASE (esegue un'installazione automatica)
• test pratici da parte del team QA: RELEASE

Tutti i test devono essere eseguiti almeno sulla versione di rilascio, perché è ciò che verrà spedito. Il profiling sulla build di debug è in genere piuttosto inutile (specialmente in C++) perché gli heap di debug hanno molti controlli extra che modificano totalmente il profilo delle prestazioni di un'applicazione tipica.