Domanda

Ogni volta che inizio un nuovo pezzo di software devo andare nella configurazione e spegnere la generazione di file PDB e il Visual Studio che ospita il processo per la build di rilascio. C'è un modo per dire a Visual Studio (2008 in particolare) che voglio farlo per tutti i progetti per il resto del tempo?

È stato utile?

Soluzione

Dopo un po 'scavare intorno, sembra che i file di progetto per C # sono memorizzati in \program files\microsoft visual studio 9.0\common7\ide\projecttemplatescache\csharp\windows\1033. Con l'aggiunta di <UseVSHostingProcess>false</UseVSHostingProcess> alle sezioni corrette (ci sono sezioni separate per Debug e Release configurazioni) dei modelli interessati, è possibile disattivare il processo di hosting per tutti i futuri progetti dei tipi selezionati.

Si dovrebbe essere in grado di gestire il problema PPB in modo simile, ma come ho detto io non raccomandare girando quelli fuori, quindi lascio come esercizio:)

Questo vale per VS2008, ma la mia ipotesi è che altre edizioni hanno uno schema simile. In realtà, VS2010 utilizza lo stesso approccio, ma ovviamente il numero di versione nella directory è 10,0 invece di 9,0.

Altri suggerimenti

In VS 2010 si trova una proprietà di progetto per controllare la generazione PDB in Proprietà del progetto -> Build -> Avanzate ... -> Debug Info

Imposta questo a "nessuno" per sopprimere la generazione PDB.

Perché non aggiungere un fase di post build che elimina i file che non si desidera. Hmm, che ancora un altro passo, non quello che si voleva: - (

Che dire di scrivere una piccola applicazione di supporto che fa un ciclo FindFirstFile e FindNextFile alla ricerca di file shost PPB e nelle directory di rilascio. Quando li trova, li cancella. O li muove meglio ancora da una posizione di archiviazione -. Questo permette di rimuoverli dai problemi di confezionamento di rilascio, ma ancora mantenere i file nel caso in cui ne avete bisogno per l'analisi di bug

Inoltre, perché la sua un'applicazione aiutante si può semplicemente eseguire una volta come parte del vostro pre-handoff per liberare il personale.

Usiamo questa tecnica per un sacco di cose:

  • DLL Garantire siano aggiornati (in pratica un aggiornamento intelligente per l'intero albero build)
  • Pulizia VC costruisce meglio di "build batch" può (rimozione di alcuni di quei file che può mandare in crash Visual Studio)
  • Archiviazione certo in un modo particolare (simile a quello che ho suggerito per voi)
  • etc

Sono con Brian - si dovrebbe tenere questi file. Se è necessario eseguire il debug qualsiasi bug o il fallimento, avrete bisogno di questi file.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top