Posizione di Dll di terze parti in Controllo versione per .NET Progetto

Quale sarebbe la posizione ideale (directory) per il controllo di dll di riferimento di terze parti per un progetto .NET in un sistema di controllo versione. In genere ho visto la maggior parte delle persone metterle sotto bin, in modo che il runtime possa prelevare automaticamente questi file. Comunque è quella la strada giusta da percorrere.Posizione di Dll di terze parti in Controllo versione per .NET Progetto

Originariamente volevo avere una directory separata parallela a bin chiamata lib che conterrà tutte le DLL di terze parti, ma ciò richiede modifiche al file di configurazione delle applicazioni in modo che la directory lib venga rilevata dal tempo di esecuzione. La mia idea qui è che lib conterrà dll di terze parti mentre bin conterrà i progetti Binary (potrebbe essere Dll o Exe)

Qual è il modo preferito, La concentrazione è la posizione nel controllo versione e non solo il File system fisico.

fonte

2009-04-18 Dinesh Manne

Perché è una preoccupazione? "Originariamente volevo avere una directory separata parallela a bin chiamata lib che conterrà tutte le DLL di terze parti, ma questo richiede modifiche al file di configurazione delle applicazioni in modo che la directory lib venga rilevata dal tempo di esecuzione" –

sembra che non tutti sappiano che è possibile eseguire un runtime vincolante per le directory e dal momento che il mio obiettivo finale è quello di far sì che il team lo usi, è piuttosto complesso per loro. –

Usiamo la seguente struttura di directory (maggiori dettagli disponibili on my blog):

Solution\ 
    Libraries\ 
    third-party DLLs here 
    Source\ 
    Project1\ 
    Project2\

Ogni riferimenti del progetto (utilizzando la scheda "Sfoglia" nella finestra di dialogo Aggiungi riferimento) le assemblee nella cartella "Biblioteche". Questi vengono automaticamente copiati nella cartella "bin" di ciascun progetto in fase di compilazione. (La cartella "Librerie" è, ovviamente, impegnata per il controllo della versione.)

fonte

2009-04-18 15:59:11

Una ragione per cui volevo avere una dir separata per la lib, è che non mi piace il modo in cui VS copia su dll a bin dir, quindi volevo che il percorso di riferimento e il percorso di runtime della dll fossero lo stesso percorso relativo. Cordiali saluti, questo è il modo in cui abbiamo già a livello di soluzione. –

Cosa succede se ci sono DLL da altri progetti all'interno dell'azienda o open-source per i quali si genera DLL di terze parti dal codice? Quel progetto pubblica la sua DLL. Quindi quel progetto commette la propria DLL ogni volta che il suo codice cambia? –

@Munish Goyal: dipende.Se il codice sta cambiando frequentemente ed è facile per tutti gli sviluppatori del team da costruire, di solito impegniamo la sua origine al controllo della versione e lo facciamo costruire come parte della soluzione. Se il codice cambia di rado, è difficile o richiede molto tempo per essere compilato (ad esempio, è C++ ma tutti gli altri progetti sono C#) quindi nominiamo uno sviluppatore come manutentore di quel progetto di terze parti e per il commit delle DLL aggiornate ogni volta che c'è un cambiamento significativo; tutti gli altri sviluppatori fanno semplicemente riferimento alle DLL predefinite. Il flusso di lavoro dipende in realtà da cosa è facile consumare quel progetto. –

Fare in modo che la directory separata contenga gli assembly di terze parti (ciò semplifica le operazioni di manutenzione nel controllo del codice sorgente) e quindi creare riferimenti nel progetto a quegli assembly. Quindi, durante la compilazione, i tuoi gruppi di terze parti verranno copiati nel tuo \bin e non dovrai apportare alcuna modifica alla configurazione.

fonte

2009-04-18 11:32:04

Sì, questo è il metodo che vedo quasi sempre. La directory "Librerie" nella directory principale da cui fai riferimento a tutte le DLL nel tuo progetto è la strada da percorrere. – Noldorin

Suppongo che quelle DLL di terze parti vengano utilizzate in più di un progetto. Quindi mettere la DLL direttamente sotto il bin di ogni progetto significa che si ottengono così tante copie DLL (nel VCS) perché ci sono progetti che non sono eleganti. Come ha detto Andrew H., se le DLL sono veramente comuni, dovrebbero essere inserite in una directory comune a cui faranno riferimento tutti gli altri progetti che ne hanno bisogno. L'unico problema qui è essere in grado di distinguere le diverse versioni della stessa DLL: nel corso del tempo, si può finire con qualcosa di simile:

/common/ThirdPartyLibrary.dll (version 1.2)  
/common/ThirdPartyLibrary.dll (version 1.3)

Il modo migliore che conosco (per ora) in giro che si rinomina il 3 ° party DLL con un numero di versione esplicito e fare riferimento a quel nuovo nome nel progetto, in modo tale che il tuo progetto si riferisca sempre alla versione corretta. Ad esempio:

/common/ThirdPartyLibrary_v1.2.dll  
/common/ThirdPartyLibrary_v1.3.dll

fonte

2009-06-26 18:40:50 SClark

Posizione di Dll di terze parti in Controllo versione per .NET Progetto

risposta

Problemi correlati