C'è un modo semplice per passare tra un progetto e la sua dll

Spesso abbiamo un set di librerie di base comuni che per alcuni dei nostri sviluppi vogliamo pensarle come riferimenti a dll e quindi basta fare riferimento alle dll e non includere il file di progetto.C'è un modo semplice per passare tra un progetto e la sua dll

Altre volte abbiamo bisogno di tutti i progetti per una sessione di debug intimo. Non posso semplicemente avere Uber.sln e Core.sln come i riferimenti sono nei file di progetto. Ho avuto questa domanda per diversi anni su diversi progetti, ma non ho altra soluzione se non quella di avere un Uber.sln con i 50 progetti.

Eventuali idee/suggerimenti/indicazioni benvenuto!

fonte

2010-10-08 Squirrel

Finché le DLL sono compilate con Debug e si dispone dei PDB, non è necessario averlo incluso come "riferimento del progetto".

Viene richiesto il codice sorgente oppure è sufficiente aprire il codice sorgente nella soluzione e impostare un punto di interruzione.

How to show source code in debug when using .lib and dll

fonte

2010-10-08 16:22:58 Nix

+1, sì. Raramente ha problemi a trovare il file .pdb, purché si trovi ancora nella cartella di generazione originale. –

Develop DLL in un proprio progetto o di progetti condivisi. Compilali e aggiungili a una cartella lib nei tuoi progetti che li fanno riferimento.
Creare un albero dev come questo:

/lib 
shareddlls go here 
/src 
solution.sln 
/projectfolder 
    project.proj 
/tools 
testing frameworks

Durante il debug in VS e andare nelle proprie DLL si dovrebbe comunque essere in grado di vedere il codice in modo non c'è bisogno di aggiungere le DLL condivise per un progetto uber. Se non riesci a vedere il codice, gestiscilo come una scatola nera. Esegui il debug di ciò che accade e di ciò che viene fuori. Se non è quello che ti aspetti, il problema è nelle dll condivise. Vai e fai il debug nei loro progetti.

Utilizzare un framework di test per verificare le DLL condivise nel proprio progetto. -----

fonte

2010-10-08 16:23:18 skyfoot

In alcuni casi si desidera sviluppare funzionalità che attraversano le DLL condivise e le DLL dell'applicazione. A quei tempi avere un'unica soluzione paga i dividendi. Sembra essere un modo di lavorare che non è supportato dalla MS. – Squirrel

@Squirrel Per me è un cattivo design. Ogni classe dovrebbe essere responsabile di una cosa e progetti simili (DLL) dovrebbero raggruppare funzionalità simili. Cerca di rimuovere le dipendenze. – skyfoot

Lasciatemi riformulare che, molto spesso, hai bisogno di una sessione di debug in cui devi seguire una richiesta dal livello più alto del tuo server nelle DLL "componente". Ti rendi conto che c'è un problema nel componente che deve essere riparato, ma per farlo quando il componente è una DLL devi attivare la soluzione del componente, ricostruire il componente e poi prendere quelle DLL e aggiornare le DLL che la soluzione/il progetto dell'applicazione è puntando a. Tutto sommato è un po 'falso, quindi abbiamo un'unica soluzione. nessuna opzione è l'ideale - questo scenario sembra familiare o è solo io? – Squirrel

Penso che la risposta più vicina che ho trovato sia quella di includere tutti i progetti nella soluzione e anche un progetto dll che, una volta compilato, avrebbe inviato la prod/dll in scatola alla directory di output.

Quindi, utilizzando diverse configurazioni, è possibile passare dalla configurazione di Debug ai progetti in fase di costruzione alla configurazione di rilascio con il solo progetto dll in costruzione.

Ci provo e ci riporto ...

fonte

2011-02-08 09:48:50 Squirrel

Ciao scoiattolo, come è andata a finire? Ho lo stesso problema di te stesso. Grazie. – toddmo

C'è un modo semplice per passare tra un progetto e la sua dll

risposta

Problemi correlati