È possibile utilizzare sia un repository locale NuGet che un repository remoto

Question

Ho convertito i nostri progetti di libreria in pacchetti NuGet e li ho ospitati su un feed NuGet interno. Funziona alla grande e ha ridotto gli sviluppatori ricreando classi di helper e "reinventando la ruota". Un altro vantaggio enorme è che ora gli altri team possono consumare librerie "rilasciate" dai nostri progetti. Fondamentalmente è stata una vittoria enorme finora.

L'unico problema che stiamo affrontando sono le build locali. Quello che vorremmo fare è raccogliere le librerie di test nei nostri progetti di consumo prima di inserire una build nel feed NuGet. Stiamo incontrando un problema perché i progetti che stanno consumando queste librerie sono configurati per utilizzare il feed locale (il ripristino del pacchetto sul server di compilazione consente di creare il nostro trunk principale con le ultime librerie "rilasciate").

C'è un modo per far recuperare le build locali da un repository locale? Ho iniziato a lavorare su un'attività successiva alla creazione per le librerie che creano file di pacchetti locali. Utilizzando NuGet.config penso che dovrei essere in grado di mascherare alcuni repository e quindi mascherare i file di configurazione sul server di build. La mia teoria è che quando si utilizza una build locale si dovrebbe prelevare il repository locale e sul server di build si userebbe il feed.

È possibile? C'è qualcun altro che ha documentato come farlo?

Ecco il compito dopo accumulo che sto utilizzando per la creazione dei pacchetti locali:

<PropertyGroup> 
    <PackOutputDir>$([System.IO.Path]::Combine($(SolutionDir), "..\Prerelease"))</PackOutputDir> 
    <BuildSpecCommand>$(NuGetCommand) spec $(ProjectFileName) -force -NonInteractive -Verbosity detailed</BuildSpecCommand> 
    <PackCommand>$(NuGetCommand) pack $(ProjectFileName) -OutputDirectory "$(PackOutputDir)"</PackCommand> 
    </PropertyGroup> 
    <Target Name="AfterBuild" Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "> 
    <Exec Command="$(BuildSpecCommand)" LogStandardErrorAsError="true" Condition=" '$(OS)' == 'Windows_NT' " /> 
    <Exec Command="$(PackCommand)" LogStandardErrorAsError="true" Condition=" '$(OS)' == 'Windows_NT' " /> 
    </Target> 

ho messo questo NuGet.config alla base del nostro progetto di squadra. Questo file è avvolta sul server di build:

<configuration> 
    <packageSources> 
    <add key="NuGet official package source" value="https://nuget.org/api/v2/" /> 
    <add key="TestSource" value="Source\Prerelease" /> 
    </packageSources> 
    <disabledPackageSources> 
    <add key="LocalNuGetFeed" value="LocalNuGetFeed" /> 
    </disabledPackageSources> 
    <activePackageSource> 
    <add key="All" value="(Aggregate source)" /> 
    </activePackageSource> 
</configuration> 

Ecco il NuGet.config che ho messo in una cartella che dovrebbe ottenere raccolti nella gerarchia del server di generazione:

<configuration> 
    <packageSources> 
    <add key="NuGet official package source" value="https://nuget.org/api/v2/" /> 
    <add key="LocalNuGetFeed" value="http://team2:12345/nuget" /> 
    </packageSources> 
    <disabledPackageSources> 
    </disabledPackageSources> 
    <activePackageSource> 
    <add key="All" value="(Aggregate source)" /> 
    </activePackageSource> 
</configuration> 

Aggiornamento Sulla base di una risposta fornita ho cambiato il file nuget.targets. Idealmente non mi piacerebbe farlo, ma se questo è il modo migliore per ottenere ciò che mi piacerebbe realizzare, allora sto bene con questo tipo di modifica.

<ItemGroup Condition=" '$(PackageSources)' == '' And '$Configuration' == 'Release'"> 
    <PackageSource Include="https://nuget.org/api/v2/" /> 
    <PackageSource Include="http://team2:12345/nuget/" /> 
    </ItemGroup> 
    <ItemGroup Condition=" '$(PackageSources)' == '' And '$Configuration' != 'Release'"> 
    <PackageSource Include="https://nuget.org/api/v2/" /> 
    <PackageSource Include="C:\temp\NuGet\Prerelease" /> 
    </ItemGroup> 

L'idea è quella di utilizzare l'attività di compilazione pubblicato in precedenza per i progetti di libreria in modo che i loro pacchetti vengono trasmessi in una cartella temporanea sul disco. Il codice immediatamente sopra dovrebbe essere nel file nuget.targets per quei progetti che dovremo apportare immediatamente all'aggiornamento della libreria mentre gli sviluppatori lavoreranno sui loro computer locali, tuttavia il server di generazione parlerà solo con il nostro feed locale durante il processo di costruzione del team.

È corretto?

Un'altra idea ... Dopo aver discusso di questo con un collega, abbiamo trovato un'altra soluzione che potrebbe essere più efficace nella pratica. Abbiamo deciso di modellarlo sul progetto AvalonDock. Quando si scaricano fonti e si apre la soluzione per quel progetto, non solo si vede il codice per creare i controlli dell'interfaccia utente, ma si vede anche un progetto di esempio che utilizza tutte le funzionalità di tali controlli.

La sua idea era che nei nostri progetti di libreria in cui il codice fosse solo librerie C#, i test di unità dovrebbero essere abbastanza efficaci da coprire qualsiasi problema. Anche le build che spingono queste librerie sono gated, il che significa che applicano solo i checkin se la build (e le prove) sono complete.

Per i controlli dell'interfaccia utente, ha indicato l'esempio precedente per AvalonDock. Includere un progetto che utilizza tutti i controlli dovrebbe mitigare la maggior parte dei problemi. Dal momento che i test unitari sui controlli dell'interfaccia utente sono limitati, tuttavia, imporrebbe lo stesso allo sviluppatore di controllare i controlli all'interno del progetto di test prima di commettere il codice e avviare il processo di compilazione.

Qual è l'opinione generale di questo approccio?

Answer 1

È possibile utilizzare più repository contemporaneamente. La parte importante qui è che è necessario definire l'ordine in cui si desidera che vengano utilizzati. Quando si ripristina/installa un pacchetto, NuGet cerca prima il primo repository, se non lo trova scansiona il secondo repository e così via.

Se è necessario che il repository locale abbia la priorità sul repository "rilasciato", è necessario specificare assicurandosi che il repository locale sia il primo nell'elenco.

Il tuo approccio sembra OK a prima vista, anche se potresti anche optare per una soluzione MSBuild (senza queste modifiche di configurazione) utilizzando il file .nuget\NuGet.targets fornito con il ripristino del pacchetto NuGet. Definisci i tuoi feed aggiungendoli nell'elemento <PackageSources> e poi (magari in base alla configurazione Build Debug | Release) puoi cambiare il repository da utilizzare nello <RestoreCommand>.