Come si condividono le dipendenze esterne tra le soluzioni di Visual Studio?

Question

Ho uno sfondo Java, quindi & # 8217; m ero abituato a far gestire a Maven tutti i problemi relativi al download e all'aggiornamento delle dipendenze. Ma nell'ambiente .NET non ho ancora trovato un buon modo per gestire tutte queste dipendenze esterne.

Il problema principale qui è che produco in serie soluzioni e tutte tendono a dipendere dalla stessa dll di terze parti & # 8217; s. Ma non voglio conservare copie separate di ciascun componente in ciascuna soluzione. Quindi ho bisogno di un modo per collegare tutte le diverse soluzioni allo stesso set di dll & # 8217; s.

Mi sono reso conto che una soluzione potrebbe essere quella di includere le librerie esterne in un & # 8221; progetto di libreria & # 8221; che è incluso in tutte le soluzioni e lascia che gli altri progetti le facciano riferimento. (Oppure assicurati di fare riferimento alla dll esterna & # 8217; s dallo stesso posto per tutti i progetti.)

Ma ci sono modi migliori per farlo? (Preferibilmente usando una sorta di plug-in per Visual Studio.)

I & # 8217; ho guardato il Visual Studio Dependency Manager e sembra un perfetto partita ma qualcuno l'ha provato davvero? Ho anche visto le porte .NET di Maven, ma sfortunatamente non sono stato molto colpito dallo stato di quelle. (Ma per favore, vai avanti e raccomandali a tutti se pensi che dovrei provarli di nuovo.)

Quindi quale sarebbe il modo più intelligente per affrontare questo problema?

Aggiornamento:

Mi sono reso conto che dovevo spiegare cosa intendevo con collegamento allo stesso set di dll & # 8217; s .

Una delle cose che sto cercando di ottenere qui è evitare che le diverse soluzioni facciano riferimento a versioni diverse di ciascun componente. Se aggiorno un componente a una nuova versione, dovrebbe essere aggiornato per tutte le soluzioni al prossimo build. Questo mi costringerebbe ad assicurarmi che tutte le soluzioni siano aggiornate con gli ultimi componenti.

Aggiornamento 2: Nota che questa è una vecchia domanda posta prima di strumenti come NuGet o OpenWrap esisteva. Se qualcuno è disposto a fornire una versione più aggiornata, vai avanti e cambierò la risposta accettata.

Answer 1

1. Trova un posto dove riporre gli assiemi. Ad esempio, memorizzo gli assembly core .Net in questo modo:

   • <branch gt &; \ Netfx \ 2,0527 \ *
   • <=> gt &; \ Netfx \ 3.0 <=> *
   • <=> gt &; \ Netfx \ 3.5 <=> *
   • <=> > \ NetFX \ Silverlight 2 <=> *
   • <=> > \ NetFX \ Silverlight 3 <=> *

2. Utilizzare la proprietà ReferencePath in MSBuild (o AdditionalReferencePath in Team Build) per indirizzare i progetti verso i percorsi appropriati. Per semplicità e facilità di manutenzione, ho 1 * .targets file che conosce ogni directory di questo tipo; tutti i miei progetti Importa quel file.

3. Assicurati che la tua strategia di controllo della versione (diramazione, unione, < locale - - > mappature del server) mantenga i relativi percorsi tra i tuoi progetti & amp; costante dei percorsi di riferimento.

Modifica

In risposta all'aggiornamento nella domanda, vorrei aggiungere un altro passaggio:

4) Assicurati che ogni riferimento di assieme in ogni file di progetto usi il nome sicuro .Net completo e nient'altro .

Bad:

<Reference Include="Microsoft.SqlServer.Smo">
  <SpecificVersion`>False</SpecificVersion>
  <HintPath>..\..\..\..\..\..\..\Program Files (x86)\Microsoft SQL Server\100\Shared\Microsoft.SqlServer.Smo.dll</HintPath>
</Reference>

Buono:

<Reference Include="Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" />

Vantaggi di quest'ultimo formato:

• L'uso di HintPath in un ambiente di sviluppo collaborativo porterà inevitabilmente a situazioni in cui " funziona per me " ma non altri. Soprattutto il tuo server di build. Se lo si omette, si ottengono i percorsi di riferimento corretti o non verranno compilati.
• L'uso di un nome debole invita alla possibilità di " DLL hell. " Dopo aver utilizzato nomi sicuri, è sicuro disporre di più versioni dello stesso assembly nei percorsi di riferimento poiché il linker caricherà solo quelli che soddisfano tutti i criteri. Inoltre, se decidi di aggiornare alcuni assembly sul posto (invece di aggiungere copie), riceverai una notifica di eventuali interruzioni al momento della compilazione anziché ogni volta che iniziano a presentarsi i bug.

Answer 2

Aggiungendo ciò che dicono tutti gli altri, si riduce sostanzialmente a due cose:

1. Assicurarsi che tutti gli sviluppatori abbiano le stesse versioni di librerie esterne
2. Assicurarsi che tutti gli sviluppatori abbiano le librerie esterne situate nello stesso posto (almeno, relativamente al codice sorgente)

Come sottolinea Richard Berg, puoi usare ReferencePath e / o AdditionalReferencePath per risolvere il problema n. 2. Se stai usando msbuild nel tuo processo di compilazione (nel nostro caso, stiamo usando CruiseControl invece di MS Team Build), puoi anche passare ReferencePath ad esso dalla riga di comando. Per risolvere il problema n. 1, ho scoperto che svn: externals essere utile (se stai usando SVN).

La mia esperienza con Maven è che è eccessivo per la maggior parte degli scopi.

Answer 3

Di solito ho una struttura di cartelle separata sul controllo del codice sorgente per dipendenze esterne o interne e questi filder hanno gli assembly in base al numero di build o versione, ad esempio

\ External \ biblioteche pubbliche \ Nunit \ 2.6 \

o

Public \ Internal \ librerie \ Logger \ 5.4.312 \

e all'interno delle soluzioni tutti i progetti che devono utilizzare una delle dipendenze aggiungono semplicemente un riferimento a tali assiemi nelle cartelle pubbliche interne o esterne.