2013-09-04 24 views
14

Ho un progetto in cui includo 2 sottomoduli da git. Entrambi i progetti hanno abilitato "ripristino pacchetto nuget", anche il progetto padre. La cartella del pacchetto nei due sottomoduli inclusi non è selezionata, non esiste nei progetti estratti. Quando si crea il progetto genitore, Nuget tenta di ripristinare i pacchetti nelle sottocartelle ma nella cartella del pacchetto errata!Ripristino pacchetto Nuget con sottodulatore git

"C:\Dev\git\oasisdb\odb_oasis_repository\ODB_OASIS_Repository\.nuget\NuGet.exe" install "C:\Dev\git\oasisdb\odb_oasis_repository\odb_oasis_rvm\ODB_OASIS_RVM_EF\ODB_OASIS_RVM_EF\packages.config" -source "" -NonInteractive -RequireConsent -solutionDir "C:\Dev\git\oasisdb\odb_oasis_repository\ODB_OASIS_Repository\ " 

Perché nuget non viene ripristinato nella directory della soluzione del sottomodulo?

Grazie

+0

Eventuali duplicati di [NuGet non ottenere pacchetti mancanti] (http://stackoverflow.com/ques tions/17797052/nuget-not-getting-missing-packages) –

risposta

8
+1

Contrassegnare come "la risposta" in modo che questo non compaia nella pila senza risposta. Grazie. – granadaCoder

+1

Assolutamente no. Un progetto di biblioteca non dovrebbe aver bisogno di conoscere i dettagli sul progetto host che lo sta facendo riferimento. -1. – Nuzzolilo

+0

Questa modifica è stata apportata alla versione più recente di NuGet? – SuperJMN

11

Nuget sta restaurando il pacchetto nella directory soluzione aperta.

È possibile modificare il csproj del progetto modulo e modificare i riferimenti pacchetto DLL da:

<ItemGroup> 
    <Reference Include="Microsoft.Rest.ClientRuntime, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> 
     <HintPath>..\packages\Microsoft.Rest.ClientRuntime.2.1.0\lib\net45\Microsoft.Rest.ClientRuntime.dll</HintPath> 
     <Private>True</Private> 
    </Reference> 

a:

<ItemGroup> 
<Reference Include="Microsoft.Rest.ClientRuntime, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> 
    <HintPath>$(SolutionDir)\packages\Microsoft.Rest.ClientRuntime.2.1.0\lib\net45\Microsoft.Rest.ClientRuntime.dll</HintPath> 
    <Private>True</Private> 
</Reference> 

Spero che questo aiuto!

+0

Se devi modificare ciascun progetto nel sottomodulo, stai effettivamente modificando il sottomodulo, che è un grande no. Come dice @ Nuzzolilo di seguito, la libreria non deve sapere nulla dei progetti che la stanno usando. Dovrebbero essere agnostici. Ci dispiace, ma questa non è una risposta valida. – SuperJMN

+0

sì, ovviamente questo dovrebbe essere usato solo se possiedi il sottomodulo e sai cosa fare con questo trucco. Grazie per il chiarimento – Srounsroun

0

Se si utilizza VS2015 Update 1 o successivo, è possibile convert your project to use project.json to fix this.

In breve:

  • Run Uninstall-Package <package name> -Force -RemoveDependencies per tutti i pacchetti. Potresti voler copiare e incollare il tuo packages.config nel blocco note prima di farlo.
  • Eliminare packages.config dal progetto, salvare il progetto, scaricare
  • Modificare il file di progetto e rimuovere:
    • Qualsiasi riferimento .props file in alto relativa a Nuget
    • Qualsiasi <Reference> elementi che fanno riferimento a un pacchetto
    • I file nella parte inferiore che riferimento nuget - di solito inizia con: <Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
    • Se i pacchetti contengono analizzatori Roslyn, ma ke sicuro di rimuoverli anche tu.
  • Salvare il file e relod il progetto

Aggiungi project.json con:

{ 
    "dependencies": { 
    }, 
    "frameworks": { 
    ".NETFramework,Version=v4.6.1": {} 
    }, 
    "runtimes": { 
    "win": {} 
    } 
} 

Infine aggiungere i pacchetti di nuovo, sia a mano sotto dependencies o utilizzando Install-Package o con l'interfaccia utente NuGet in VS.

Ho anche dovuto rimuovere tutti i pacchetti Microsoft.Bcl.* dai miei progetti perché cercano esplicitamente un file packages.config.

EDIT:. Questo (rimuovendo i Microsoft.Bcl.* pacchetti vi darà un errore di compilazione, anche se il progetto sarà costruire bene, perché il file Microsoft.Bcl.Build.targets aggiunge sarà ancora cercare packages.config

Per sopprimere questo, modificare il file di progetto e aggiungere:.

<SkipValidatePackageReferences>true</SkipValidatePackageReferences> 

Questo deve andare al primo <PropertyGroup> che non ha impostato un attributo Condition Se non c'è uno, basta aggiungere un altro in alto, come:

<PropertyGroup> 
    <SkipValidatePackageReferences>true</SkipValidatePackageReferences> 
</PropertyGroup> 
1

è possibile utilizzare link simbolico: Dopo downloads Nuget tutti i pacchetti nella directory di soluzione packages, creare un link simbolico nella directory principale del modulo (nomi packages e link per il livello della soluzione packages directory). In breve - nel progetto di avvio Aggiungi l'evento pre-compilazione che crea legame simbolico tra la directory di soluzione packages a tutti i vostri sottomoduli packages directory:

Questo è il lotto:

SET sourceDir=$(SolutionDir)packages 
SET destDir=$(SolutionDir)..\..\submodules\saturn72\src\packages 

if not exist %sourceDir% mkdir %sourceDir% 

if not exist %destDir% mklink /j %destDir% %sourceDir% 

spiegazione completa qui: Visual Studio Solution with Nuget git submodules

Il codice sorgente è qui: SolutionWithGitSubmodulesAndNuget

Problemi correlati