Configurando uma pasta comum de pacotes de nuget para todas as soluções quando alguns projetos são incluídos em várias soluções

Eu tenho usado o NuGet para recuperar pacotes de fontes externas e internas, o que é muito conveniente. Mas percebi que os pacotes são armazenados por solução por padrão, o que é muito frustrante quando alguns projetos com referências do NuGet são incluídos em várias soluções. Em seguida, as referências são alteradas para outra pasta do pacote de soluções que pode estar indisponível para outro desenvolvedor ou máquina de compilação.

Vi que existem maneiras de apontar um local de pacote comum (talvez no nível raiz do projeto, estamos usando o controle de fonte TFS) com a versão 2.1 do NuGet, consulte as notas de versão . Estou usando o NuGet v2.7

Mas eu tentei adicionar arquivos nuget.config sem ver nenhum efeito disso. Os pacotes ainda estão armazenados na pasta da solução. Há algo que eu perdi? Parece haver estruturas diferentes do nó xml a serem adicionadas ao arquivo nuget.config, dependendo de quem está respondendo a essa pergunta: Schwarzie sugere em outro thread do Stackoverflow :

<settings>
  <repositoryPath>..\..\[relative or absolute path]</repositoryPath>
</settings>

As notas de versão do NuGet 2.1 (veja o link acima) sugerem este formato:

<configuration>
  <config>
    <add key="repositoryPath" value="..\..\[relative or absolute path]" />
  </config>
</configuration>

Não sei qual desses, ou nenhum, ou ambos, funcionarão no final. Eu tentei ambos no nível da solução. O arquivo nuget.config pode ser colocado no nível raiz do projeto TFS ou deve estar no diretório da solução? Parece que o NuGet lê e aplica as configurações desses arquivos em uma certa ordem, por que faria sentido adicioná-las em vários níveis, onde um arquivo nuget.config no nível da solução substitui um no nível raiz do projeto TFS. Isso pode ser esclarecido?

Preciso remover todos os pacotes instalados para que essas referências funcionem? Eu adoraria que alguém pudesse fornecer uma instrução passo a passo para passar do uso de nuget específico da solução para uma pasta de pacote comum em que projetos que pertencem a várias soluções possam encontrar os pacotes de nuget necessários.

Eu tenho uma situação semelhante com fontes de pacotes externos e internos com projetos referenciados em mais de uma solução. Acabei de trabalhar com uma de nossas bases de código hoje e parece estar trabalhando com as estações de trabalho do desenvolvedor e com o servidor de compilação. O processo abaixo tem esse cenário em mente (embora não deva ser difícil se adaptar para ter a pasta de pacotes comuns em outro lugar).

• Codebase
  • Projeto A
  • Projeto B
  • Projeto C
  • Soluções
    • Solução 1
    • Solução 2
    • Solução 3
    • Pacotes (este é o comum compartilhado por todas as soluções)

Resposta atualizada a partir do NuGet 3.5.0.1484 com o Visual Studio 2015 Update 3

Esse processo é um pouco mais fácil agora do que quando eu o resolvi originalmente e pensei que era hora de atualizá-lo. Em geral, o processo é o mesmo apenas com menos etapas. O resultado é um processo que resolve ou fornece o seguinte:

• Tudo o que precisa ser comprometido com o controle do código-fonte é visível e rastreado na solução
• Instalar novos pacotes ou atualizar pacotes usando o Gerenciador de Pacotes no Visual Studio usará o caminho correto do repositório
• Após a configuração inicial, não há invasão de arquivos .csproj
• Nenhuma modificação na estação de trabalho do desenvolvedor (o código está pronto para compilação no check-out)

Existem algumas desvantagens em potencial a serem observadas (ainda não as experimentei, YMMV). Veja a resposta e os comentários de Benol abaixo.

Adicionar NuGet.Config

Você deseja criar um arquivo NuGet.Config na raiz da pasta \ Solutions \. Verifique se este é um arquivo codificado em UTF-8 que você cria, se não tiver certeza de como fazer isso, use o menu Arquivo do Visual Studio-> Novo-> Arquivo e escolha o modelo de arquivo XML. Adicione ao NuGet.Config o seguinte:

<?xml version="1.0" encoding="utf-8"?>
<configuration>  
  <config>
    <add key="repositoryPath" value="$\..\Packages" />
  </config>
</configuration>

Para a configuração repositoryPath, você pode especificar um caminho absoluto ou relativo (recomendado) usando o token $. O token $ baseia-se na localização do NuGet.Config (o token $ é na verdade relativo a um nível abaixo da localização do NuGet.Config). Portanto, se eu tiver \ Solutions \ NuGet.Config e desejar \ Solutions \ Packages, precisarei especificar $ \ .. \ Packages como o valor.

Em seguida, você deseja adicionar uma pasta de solução à sua solução chamada algo como "NuGet" (clique com o botão direito do mouse na sua solução, Adicionar-> Nova pasta de solução). As pastas de solução são pastas virtuais que existem apenas na solução do Visual Studio e não criarão uma pasta real na unidade (e você poderá fazer referência a arquivos de qualquer lugar). Clique com o botão direito do mouse na pasta da solução "NuGet", depois em Adicionar-> Item Existente e selecione \ Solutions \ NuGet.Config.

A razão pela qual estamos fazendo isso é para que fique visível na solução e ajude a garantir que esteja devidamente comprometido com seu controle de código-fonte. Você pode executar esta etapa para cada solução em sua base de código que participa de seus projetos compartilhados.

Ao colocar o arquivo NuGet.Config em \ Solutions \ acima de qualquer arquivo .sln, aproveitamos o fato de o NuGet navegar recursivamente a estrutura de pastas para cima no "diretório de trabalho atual" procurando um arquivo NuGet.Config para usar. O "diretório de trabalho atual" significa algumas coisas diferentes aqui, uma é o caminho de execução do NuGet.exe e a outra é o local do arquivo .sln.

Alternando pela pasta de pacotes

Primeiro, recomendo que você percorra cada uma das pastas da sua solução e exclua as pastas \ Packages \ existentes (será necessário fechar o Visual Studio primeiro). Isso facilita a visualização de onde o NuGet está colocando sua pasta \ Packages \ recém-configurada e garante que todos os links para a pasta \ Packages \ incorreta falhem e possam ser corrigidos.

Abra sua solução no Visual Studio e inicie um Rebuild All. Ignore todos os erros de compilação que você receberá; isso é esperado neste momento. Isso deve iniciar o recurso de restauração do pacote NuGet no início do processo de compilação. Verifique se sua pasta \ Solutions \ Packages \ foi criada no local desejado. Caso contrário, revise sua configuração.

Agora, para cada projeto em sua solução, você desejará:

1. Clique com o botão direito do mouse no projeto e selecione Descarregar Projeto
2. Clique com o botão direito do mouse no projeto e selecione Editar your-xxx.csproj
3. Encontre todas as referências a \ packages \ e atualize-as para o novo local.
   • A maioria destes serão referências <HintPath>, mas não todos. Por exemplo, WebGrease e Microsoft.Bcl.Build terão configurações de caminho separadas que precisarão ser atualizadas.
4. Salve o .csproj e clique com o botão direito do mouse no projeto e selecione Recarregar Projeto

Depois que todos os seus arquivos .csproj forem atualizados, inicie outro Rebuild All e você não terá mais erros de compilação sobre as referências ausentes. Neste ponto, você está pronto e agora tem o NuGet configurado para usar uma pasta Pacotes compartilhada.

No NuGet 2.7.1 (2.7.40906.75) com o VStudio 2012

Em primeiro lugar, o nuget.config não controla todas as configurações de caminho no sistema de pacotes nuget. Isso foi particularmente confuso para descobrir. Especificamente, o problema é que o msbuild e o Visual Studio (chamando msbuild) não usam o caminho no nuget.config, mas o substituem no arquivo nuget.targets.

Preparação do ambiente

Primeiro, eu examinaria a pasta da sua solução e removeria todas as \ packages \ folders existentes. Isso ajudará a garantir que todos os pacotes estejam sendo instalados visivelmente na pasta correta e ajudará a descobrir quaisquer referências de caminho incorreto nas suas soluções. Em seguida, verifique se você tem a última extensão do Visual Studio do nuget instalada. Também gostaria de garantir que você tenha o nuget.exe mais recente instalado em cada solução. Abra um prompt de comando e vá para cada pasta $ (SolutionDir) \ .nuget \ e execute o seguinte comando:

nuget update -self

Definindo o caminho da pasta do pacote comum para o NuGet

Abra cada $ (SolutionDir) \ .nuget \ NuGet.Config e adicione o seguinte dentro da seção <configuração>:

<config>
    <add key="repositorypath" value="$\..\..\..\Packages" />
</config>

Nota: Você pode usar um caminho absoluto ou um caminho relativo. Lembre-se de que, se você estiver usando um caminho relativo com $, ele é relativo a um nível abaixo da localização do NuGet.Config (acredite que seja um erro).

Definindo o caminho da pasta de pacote comum para o MSBuild e o Visual Studio

Abra cada $ (SolutionDir) \ .nuget \ NuGet.targets e modifique a seção a seguir (observe que para não-Windows, há outra seção abaixo):

<PropertyGroup Condition=" '$(OS)' == 'Windows_NT'">
    <!-- Windows specific commands -->
    <NuGetToolsPath>$([System.IO.Path]::Combine($(SolutionDir), ".nuget"))</NuGetToolsPath>
    <PackagesConfig>$([System.IO.Path]::Combine($(ProjectDir), "packages.config"))</PackagesConfig>
    <PackagesDir>$([System.IO.Path]::Combine($(SolutionDir), "packages"))</PackagesDir>
</PropertyGroup>

Update PackagesDir para ser

<PackagesDir>$([System.IO.Path]::GetFullPath("$(SolutionDir)\..\Packages"))</PackagesDir>

Nota: O GetFullPath resolverá nosso caminho relativo em um caminho absoluto.

Restaurando todos os pacotes de nuget na pasta comum

Abra um prompt de comando e vá para cada $ (SolutionDir) \ .nuget e execute o seguinte comando:

nuget restore ..\YourSolution.sln

Nesse momento, você deve ter uma única pasta \ packages \ no local comum e nenhuma em nenhuma das pastas da solução. Caso contrário, verifique seus caminhos.

Corrigindo referências de projeto

Abra todos os arquivos .csproj em um editor de texto e encontre referências a \ packages e atualize-os para o caminho correto. A maioria destes serão referências <HintPath>, mas não todos. Por exemplo, WebGrease e Microsoft.Bcl.Build terão configurações de caminho separadas que precisarão ser atualizadas.

Crie sua solução

Abra sua solução no Visual Studio e inicie uma compilação. Se ele reclamar de pacotes ausentes que precisam ser restaurados, não assuma que o pacote está ausente e precisa ser restaurado (o erro pode ser enganoso). Pode ser um caminho ruim em um dos seus arquivos .csproj. Verifique isso antes de restaurar o pacote.

Tem um erro de compilação sobre pacotes ausentes?

Se você já verificou se os caminhos nos arquivos .csproj estão corretos, você tem duas opções para tentar. Se esse é o resultado da atualização do seu código do controle do código-fonte, você pode tentar fazer o check-out de uma cópia limpa e criar isso. Isso funcionou para um de nossos desenvolvedores e acho que havia um artefato no arquivo .suo ou algo semelhante. A outra opção é forçar manualmente uma restauração de pacote usando a linha de comando na pasta .nuget da solução em questão:

nuget restore ..\YourSolution.sln

Em vez de definir o local comum do pacote para todos os projetos, também é possível alterar o HintPath no projeto da seguinte maneira:

<HintPath>$(SolutionDir)\packages\EntityFramework.6.1.0\lib\net40\EntityFramework.dll</HintPath>

Na maioria dos casos, no projeto compartilhado, haverá apenas alguns pacotes, para que você possa alterá-lo facilmente.

Eu acho que é uma solução melhor, quando você ramifica o código, ao definir o repositório comum, deve alterar o caminho relativo; nesta solução, você não precisa fazer isso.

Minha experiência ao tentar fazer isso com a versão mais recente do NuGet (2.7) e VS2012:

• Exclua a pasta .nuget (no disco e na solução)
• Coloque um arquivo NuGet.Config em uma pasta pai comum de todas as soluções
• Exclua as pastas de pacotes existentes
• Percorra todos os arquivos csproj e altere o HintPaths para apontar para o novo local
• Lucro

No meu caso, eu queria colocar todos os pacotes .packages, para que meu NuGet.Config se parecesse abaixo.

 <?xml version="1.0" encoding="utf-8"?>
 <configuration>
   <config>
     <add key="repositorypath" value=".packages" />
   </config>
 </configuration>

Observe que existem algumas coisas "estranhas" que podem acontecer, mas acho que são suportáveis:

• Se você 'atualizar' um pacote de uma solução, ela excluirá imediatamente a versão mais antiga da sua pasta de pacotes (não poderá saber se você tem outra solução que esteja apontando para lá). Isso não me incomoda muito, pois a outra solução restaurará apenas quando necessário.
• Se você tentar adicionar um pacote com o botão direito do mouse na solução, se o pacote já estiver presente em outra solução, ele verá que está lá e mostrará o 'sinal verde' em vez do botão 'instalar'. Normalmente, instalo com o botão direito do mouse no projeto, para que isso não me incomode.

Disclaimer : Eu tentei isso hoje, não tenho nenhuma experiência a longo prazo para fazer o backup!

Eu tenho o NuGet versão 2.8.50926 com o VS 2013. Você não precisa usar vários arquivos nuget.config ou estruturas de diretório complexas. Basta modificar o arquivo padrão localizado aqui:

%APPDATA%\Roaming\NuGet\NuGet.Config

Aqui está o conteúdo do meu arquivo:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="repositoryPath" value="C:\Projects\nugetpackages" />
  </config>
  <activePackageSource>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </activePackageSource>
</configuration>

Portanto, todos os pacotes vão para a pasta "C: \ Projects \ nugetpackages", não importa onde esteja a solução.

Em todas as suas soluções, basta excluir as pastas "pacotes" existentes. Em seguida, crie sua solução e o NuGet restaurará automaticamente os pacotes ausentes no novo diretório centralizado que você especificou.

Já não há necessidade de modificar nuget.targets. Foi corrigido no nuget 2.8 ( http://nuget.codeplex.com/workitem/2921 ). Você só precisa definir o caminho do repositório.

Do Visual Studio 2013, atualização 4 e versão do Nugget Package Manager> 2.8.5 ...

Crie o arquivo nuget.config na raiz do repositório.

conteúdo do arquivo:

<configuration>
  <config>
    <add key="repositoryPath" value="packages" />
  </config>
  <packageSources>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </packageSources>
</configuration>

Isso fará com que todos os pacotes entrem na pasta packages no nível do arquivo nuget.config.

Agora você pode ir para cada console de nuget .sln com o comando 'update-package -reinstall'

Se você tiver vários repositórios no mesmo nível e o que compartilhar a mesma pasta de pacotes, tente usar uma maneira de subir uma pasta.

 <add key="repositoryPath" value="..\packages" />

Mas dessa maneira, você faz com que a referência de pacotes de nuget csproj esteja apontando uma pasta para fora do caminho dos repositórios.

Inventei um pacote NuGet que converte de forma transparente todas as referências do NuGet em um projeto para um formato relativo a $ (SolutionDir). Isso é feito usando a transformação XSLT em tempo de construção, para que você não precise hackear o arquivo do projeto manualmente. Você pode atualizar seus pacotes livremente, não quebrará nada.

https://www.nuget.org/packages/NugetRelativeRefs

Ou, se você usa o Visual Studio 2015 Update 3, pode migrar as referências de pacote para o project.jsonformulário conforme descrito aqui: https://oren.codes/2016/02/08/project-json-all-the-things

Atualizando minha experiência com o nuget 2.8.3. Foi relativamente simples. Tudo o que foi feito foi habilitado para restaurar o pacote com o botão direito do mouse. Editou o NuGet.Config e adicionou estas linhas:

  <config>
    <add key="repositorypath" value="..\Core\Packages" />
  </config>

Depois, reconstruiu a solução, baixou todos os pacotes para a pasta desejada e atualizou as referências automaticamente. Fiz o mesmo para todos os meus outros projetos, onde apenas pacotes incrementais foram baixados e pacotes existentes foram referenciados. Portanto, um repositório de pacotes comum para todos os projetos foi definido.

Aqui está um procedimento passo a passo para habilitar a restauração do pacote.

http://blogs.4ward.it/enable-nuget-package-restore-in-visual-studio-and-tfs-2012-rc-to-building-windows-8-metro-apps/

Basta vincular os pacotes / hardlinks ao local compartilhado desejado. Em seguida, seu projeto não será interrompido por outros usuários, que não possuem um local de pacotes especiais.

Abra um prompt de comando como administrador e use

mklink /prefix link_path Target_file/folder_path

Para qualquer solução significativa, as respostas acima serão insuficientes. Simplesmente, uma estrutura complexa do espaço de trabalho do TFS com diferentes caminhos relativos, ramificação, projetos compartilhados etc. torna impossível um único repositório central.

Usar ($ SolutionDir) é um passo na direção certa, mas codificar manualmente o arquivo csproj com ($ SolutionDir) se tornaria bastante tedioso em uma base de código com centenas de pacotes que são atualizados regularmente (sempre que ocorre a atualização, o HintPath é substituído por um novo caminho relativo). O que acontece se você precisar executar o Update-Package -Reinstall.

Existe uma ótima solução chamada NugetReferenceHintPathRewrite . Ele automatiza a injeção de ($ SolutionDir) nos HintPaths imediatamente antes da compilação (sem alterar o arquivo csproj). Eu imagino que poderia ser facilmente incorporado em sistemas de construção automatizados

Um breve resumo para os profissionais do VS 2013 com a Versão NuGet : 2.8.60318.667

É assim que você direcionaria os pacotes para um caminho relativo à pasta .nuget:

<configuration>
  <config>
    <add key="repositoryPath" value="../Dependencies" />
  </config>
</configuration>

Por exemplo, se sua solução (arquivo .sln) reside em C: \ Projects \ MySolution, quando você ativa a restauração do pacote NuGet, a pasta .nuget é criada da seguinte maneira: C: \ Projects \ MySolution.nuget e os pacotes serão baixados para um diretório como este: C: \ Projects \ MySolution \ Dependencies

NOTA: Por alguma razão (desconhecida), sempre que atualizo o "repositoryPath", tenho que fechar e reabrir a solução para que as alterações entrem em vigor

para aqueles que usam o paket como gerenciador de pacotes, há uma opção de vínculo automático para o seu arquivo de dependências:

storage: symlink

btw: paket aproveita pepita

referência: https://fsprojects.github.io/Paket/dependencies-file.html

Se você deseja modificar o mínimo possível, basta limpar subdiretórios periodicamente com um script. ie O comportamento padrão do Nuget é copiar arquivos de um local global para uma pasta de pacotes locais, exclua esses arquivos posteriormente.

Eu apenas uso junções NTFS para fazer com que todas as pastas de pacotes sejam direcionadas para uma única pasta acima das raízes do repositório. Funciona bem. Não há problemas com a restauração de pacotes paralelos em várias soluções. Uma vantagem disso é que você não precisa reconfigurar nada no código-fonte, como as centenas de caminhos de dicas relativas nos arquivos .csproj. Ele simplesmente funciona, permitindo que o sistema de arquivos lide com o redirecionamento e a simulação de uma única pasta de pacotes.

Cuidado com os problemas do 'git'. Embora o 'status do git' através da linha de comando não mostre alterações sem etapas, observei que o GitKraken vê a junção 'package' como um arquivo sem etapas . Ele até mostra erros como 'arquivo é um diretório' quando você clica nele. O GitKraken também tentará ocultar esse 'arquivo' se você recuperar, destruindo a junção e restaurando-o como um arquivo real que contém texto com o caminho do arquivo original. Comportamento muito estranho. Talvez seja possível contorná-lo, garantindo que o arquivo de pacotes seja adicionado ao seu .gitignore.

Estas são as instruções do NuGet 2.1: http://docs.nuget.org/docs/release-notes/nuget-2.1

Não há necessidade de editar arquivos no nível da solução.

Trabalha com o Visual Studio 2013 e três soluções que compartilham projetos.

Não se esqueça de atualizar o NuGet no nível da solução (cada nuget.exe nas pastas .nuget).