A pasta .nuget deve ser adicionada ao controle de versão?

Com as versões mais recentes do NuGet, é possível configurar um projeto para restaurar automaticamente os pacotes NuGet para que a packagespasta não precise ser incluída no repositório de código-fonte. Boa.

No entanto, este comando adiciona uma nova .nugetpasta e há um binário lá, NuGet.exe. Isso também pode ser recriado automaticamente pelo Visual Studio e, portanto, não parece correto adicioná-lo ao controle de versão. No entanto, sem essa pasta, o Visual Studio nem mesmo carregará a solução corretamente.

Como vocês lidam com isso? Adicionar .nuget ao controle de origem? Executar algum script de linha de comando antes de abrir a solução?

Esta postagem é antiga, você não deve usar mais a restauração de pacote NuGet de nível de solução. A partir da versão 2.7+, há uma opção na configuração do NuGet para restaurar automaticamente os pacotes na compilação. Assim, a pasta .nuget pode ser excluída e a opção removida de seus projetos.

http://docs.nuget.org/docs/reference/package-restore

ATUALIZAÇÃO: Com o lançamento do NuGet 4.xe .NET Standard 2.0, quando você usa o novo formato csproj, agora você pode usar referências de pacote, ironicamente reintroduzindo a dependência do msbuild para restaurar pacotes, mas agora os pacotes são cidadãos de primeira classe do msbuild . O link acima também menciona o PackageReference, mas o anúncio a seguir o detalha melhor:

https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html

E o anúncio RTM do NuGet 4.x, que ironicamente não é tão útil:

https://blog.nuget.org/20170308/Announcing-NuGet-4.0-RTM.html

ATUALIZAÇÃO 2: Aparentemente com o VS2017 você pode até usar referências de pacote com projetos csproj clássicos, mas eles não são mais compatíveis com versões anteriores, e houve alguns problemas com a restauração de subdependências de pacotes. Tenho certeza de que tudo será resolvido.

A resposta de @Richard Szalay está certa - você não precisa enviar o nuget.exe. Se, por algum motivo, o Visual Studio não baixar automaticamente o nuget.exe, certifique-se de ter o seguinte definido como verdadeiro no nuget.targetsarquivo:

<!-- Download NuGet.exe if it does not already exist --> 
<DownloadNuGetExe Condition=" '$(DownloadNuGetExe)' == '' ">true</DownloadNuGetExe>

Feche a solução VS, abra-a novamente e crie-a. O Visual Studio deve baixar nuget.exe automaticamente agora.

De acordo com este tópico , a pasta .nuget deve ser controlada por versão.

Você precisa se comprometer .nuget\nuget.targets, mas não nuget.exe. Os destinos irão baixar o exe se ele não existir, contanto que você mude DownloadNuGetExepara trueem nuget.targets

Embora eu geralmente não goste da ideia de adicionar exe ao controle de origem, sugiro que o controle de origem deve conter tudo o que é necessário para abrir, construir e executar o projeto.

Nesse caso, parece que a pasta .nuget é uma dependência necessária. Portanto, deve estar sob controle de origem.

A única pergunta que resta, que você precisa pesquisar, é como o NuGet vai reagir se essa pasta estiver marcada como somente leitura, o que o TFS fará depois de fazer o check-in.

Atualização: Pesquisei um pouco mais sobre isso, pois nunca usei o NuGet antes. http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html

Eu sugeriria que provavelmente o que você deseja fazer é tornar o NuGet um requisito que deve ser instalado em todas as estações de trabalho dos desenvolvedores.

Além disso, você deve colocar no controle de origem o arquivo em lote necessário para preparar uma estação de trabalho para começar a editar o projeto. O arquivo em lote executará os comandos necessários para obter e instalar os pacotes de dependência.

Além disso, eu diria que você pode entrar em contato com o NuGet diretamente para perguntar como, exatamente, isso deve funcionar.

Agora que o nuget oferece suporte à restauração de pacotes, estamos examinando-o mais de perto.

Usamos o Subversion para controle de origem, e minha ideia inicial é que .nugetdeve ser adicionado ao nosso repositório, mas adicionado usando svn: externals para que aponte para um único local.

Dessa forma, podemos enviar automaticamente novas versões para todos os desenvolvedores e projetos. Para projetos em ramos de lançamento, ao invés de HEAD, podemos especificar a revisão de svn: referência externa se quisermos deixar o nuget sozinho.

Temos muitos projetos, então isso também significa não duplicar nuget.exevárias vezes no repo.

Temos o nuget.configarquivo na pasta, pois contém as referências ao nosso servidor Nuget interno, usando a área Fontes do pacote: https://docs.nuget.org/consume/nuget-config-settings

Além desse motivo, você deve permitir que o Visual Studio cuide do download dos pacotes.