Esiste un approccio consigliato alla configurazione di un pacchetto NuGet che utilizza più framework in TeamCity utilizzando MSBuild?

Question

Ho letto una manciata di post (vedi riferimenti sotto) e devo ancora trovare una guida sulle migliori pratiche specifiche per il mio stack tecnologico.

L'obiettivo: Creare un unico pacchetto NuGet mira più framework .NET costruite da un singolo file csproj via TeamCity utilizzando MSBuild e NuGet.

I vincoli:

1. tirare il codice dai VCS solo una volta.
2. Tutti gli assembly compilati devono essere versionati allo stesso modo.
3. Singolo .csproj (non uno per framework di destinazione).

ho due approcci in mente:

1. creare una singola configurazione di generazione. Contiene tre passaggi di costruzione: compilazione di .NET 3.5, compilazione di .NET 4.0, pacchetto con NuGet. Ogni passo di costruzione sarebbe subordinato al successo dell'ultimo. L'unico vero problema che vedo con questo approccio (e spero che esista una soluzione di cui non sono a conoscenza) è che ogni fase di costruzione richiede il proprio set di parametri di build (ad es. System.TargetFrameworkVersion e system.OputputPath) per designare il posizione unica per la DLL di sedersi (ad esempio, bin \ release \ v3.5 e bin \ release \ v4.0) in modo che il passaggio del pacchetto NuGet sarebbe in grado di fare la sua cosa in base alla sezione File nel file .nuspec.

2. Creare più configurazioni di build. Una configurazione di build per i passi di costruzione descritti sopra. Con questo approccio, è facile risolvere il problema dei parametri di build TargetFrameworkVersion e OutputPath, ma ora devo creare dipendenze per gli snapshot e condividere il numero di versione dell'assembly tra i build. Mangia anche slot di configurazione build che è ok (ma non ottimale) per noi poiché abbiamo una licenza Enterprise.

Option # 1 sembra la scelta più ovvia. Le opzioni # 2 sono sporche.

Quindi le mie due domande sono:

1. E 'possibile creare parametri che sono unici per un passaggio di generazione?
2. Esiste un terzo approccio migliore?

Riferimenti:

1. Multi-framework NuGet build with symbols for internal dependency management
2. Nuget - packing a solution with multiple projects (targeting multiple frameworks)
3. http://lostechies.com/joshuaflanagan/2011/06/23/tips-for-building-nuget-packages/
4. http://msdn.microsoft.com/en-us/library/hh264223.aspx
5. https://stackoverflow.com/a/1083362/607701
6. http://confluence.jetbrains.com/display/TCD7/Configuring+Build+Parameters
7. http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package

Answer 1

Qui è la mia soluzione preferita (Opzione 1):

La magia si basa su una soluzione infelice. Se sei disposto a fare questo compromesso, questa soluzione funziona. Se non lo sei, puoi seguire the issue that I opened on JetBrains' issue tracker.

La configurazione singola costruzione simile a questa:

Nota il nome delle prime due fasi di compilazione. Sono, infatti, denominati esplicitamente come valori TargetFrameworkVersion per .NET 3.5 e 4.0, rispettivamente.

Poi, nella sezione parametri di costruzione, ho configurato i seguenti parametri:

E infine, il passo Nuget pacchetto fa la traduzione percorso del file in base alla sezione File di mio .nuspec:

<files> 
    <file src="bin\release\v3.5\*.*" target="lib\net35" /> 
    <file src="bin\release\v4.0\*.*" target="lib\net40" /> 
</files> 

Answer 2

Ecco una soluzione di prendere il secondo approccio:

Il progetto contiene le seguenti configurazioni di build e il modello:

La Shared Costruire Number Generator è la prima build della catena. Non fa altro che creare un numero di build che le build dipendenti condivideranno. Sto usando il plugin di riferimento TeamCity Shared Build Number di Nicholas Williams.

e qui ci sono le configurazioni notevoli nella creazione da modello:

Annotare il numero di build viene dalla ID build del Shared Costruire generatore di numeri di cui sopra. Quindi, nel mio caso, l'ID di quella build è 14. Nota anche la variabile% TargetFrameworkVersion% nel percorso artefatto. Fortunatamente, TeamCity supporta l'interpolazione variabile quasi ovunque.

Affinché il modello di sfruttare il numero di build, deve avere una dipendenza istantanea su tale configurazione di generazione:

E, infine (per quanto riguarda il modello), i parametri di costruzione sono quasi identiche ai parametri nella mia soluzione preferita. Notare il parametro di configurazione aggiuntivo, tuttavia. Questo è ciò che verrà sovrascritto dalle configurazioni ereditare costruire:

Poi, nel dipendente costruisce, è necessario cablare una dipendenza snapshot in modo che il numero di build (ereditato dal modello) in realtà funziona anche prendendo una dipendenza la build di configurazione numero di build comune:

E, naturalmente, è necessario impostare il quadro mirato attuale:

Con le build effettive configurate, è ora possibile configurare la configurazione di build del pacchetto NuGet. Non è necessario allegare ad una radice VCS:

Ma si ha bisogno di configurare un gruppo di dipendenze (sia snapshot e artefatto):

E, infine, hai finito.