2016-03-17 23 views
7

Stiamo sperimentando con nuget per i nostri progetti di studio visivo. Tuttavia, utilizziamo (o almeno principalmente) solo nuget per i nostri riferimenti esterni e li archiviamo in un repository locale (condivisione di rete). Quello che vorrei sapere è come gestire l'intera situazione di debug/release.Debug e rilascia repository locale pacchetti nuget

Calcestruzzo (semplificato) Situazione:

Abbiamo un progetto principale che ha i riferimenti a due componenti condivisi che abbiamo sviluppato noi stessi. Questi componenti condivisi sono utilizzati anche in altri prodotti della nostra azienda

Quando costruiamo il progetto principale sul server di build (attività di costruzione di tfs 2015), costruiamo le versioni di debug e release del progetto. Tuttavia, possiamo solo specificare un singolo pacchetto nuget per ogni riferimento esterno.

Ciò che vogliamo ottenere per utilizzare la versione di debug dei componenti condivisi durante la build di debug e la versione di rilascio durante la build di rilascio. Tuttavia, questi sono (per quanto ne so) pacchetti effettivamente diversi.

Qual è il modo di affrontare questo problema? C'è ad esempio un modo per includere entrambe le versioni di rilascio e di debug in un unico pacchetto di nuget? È possibile avere diverse configurazioni di nuget per diverse impostazioni di configurazione di build?

Ho trovato Best practices with Nuget: Debug or Release?, tuttavia questo argomento non risolve il problema. Questo thread è più una discussione sull'opportunità di pubblicare versioni di debug o release su un server remoto. Vogliamo pubblicare entrambi e utilizzare entrambi, ma solo su un server locale. Non abbiamo intenzione di condividere le nostre biblioteche con il resto del mondo.

risposta

1

Un pacchetto NuGet normalmente contiene solo un singolo set di assiemi per un particolare framework di destinazione. Non è progettato per distribuire una versione di debug e release poiché si sta pubblicando il pacchetto NuGet per essere utilizzato da altri utenti. Normalmente non pubblichi un debug e una versione separata della tua applicazione per gli utenti finali.

Potrebbe essere possibile risolvere il problema utilizzando custom MSBuild .targets file nel pacchetto NuGet che ha i propri riferimenti e informazioni di configurazione. Puoi utilizzare questo file .targets come estensione del tuo progetto. Verrà importato in modo da poter definire i riferimenti come necessario in base alle configurazioni definite nel progetto. Non è l'ideale, ma dovrebbe funzionare.

+0

Questo non significa che, per la nostra situazione, potrebbe non essere la strada da percorrere? Esiste un approccio diverso oltre a nuget per includere questo tipo di componenti condivisi nel nostro progetto? Come fanno le altre persone a raggiungere questo risultato? Sono sicuro che non siamo la prima azienda con questa situazione – PaulVrugt

+0

Sì, NuGet potrebbe non essere un buon approccio per te. Presumibilmente la tua condivisione di rete funziona ancora per debug e build di rilascio, quindi forse non c'è bisogno di cambiarla. –

+2

Non vedo davvero perché non ci siano più persone con lo stesso problema. Ho abbozzato una situazione che credo sia molto comune per molte aziende. Come fanno le altre aziende a configurare il loro build server per creare con librerie esterne? Il vantaggio dell'utilizzo di nuget è che funziona subito in build di build di build tfs2015 e garantisce che la versione del riferimento rimanga invariata fino all'aggiornamento manuale. Perdiamo questo vantaggio se ci allontaniamo da nuget. – PaulVrugt