Sistemas de gerenciamento de dependências .NET

Eu tenho alguns projetos .NET que estão começando a ficar grandes o suficiente para serem analisados ​​nas soluções de Gerenciamento de Dependências, portanto, não precisamos copiar binários de um projeto para outro. Aqui está o que eu encontrei até agora:

• O NPanday é baseado em uma porta do Maven. Não sei dizer se foi trabalhado recentemente, mas o último lançamento foi em maio de 2011.
• O NuGet parece estar em desenvolvimento ativo e parece ter suporte diretamente da Microsoft. Algumas pessoas reclamaram que "apenas aborda a resolução de dependências", mas não sei mais o que ela deveria abordar ou se adicionou mais recursos desde esse ponto. Parece ter adicionado recentemente a capacidade de importar binários como parte do processo de compilação, para que não tenhamos que confirmá-los em nossos repositórios.
• O Refix parece ainda estar na versão beta, depois de não receber atenção desde setembro de 2011.

Alguém com experiência recente usando alguma dessas ferramentas de gerenciamento de dependências (ou quaisquer outras que funcionem bem) compartilharia sua experiência? O NuGet é maduro o suficiente para usá-lo no gerenciamento de dependências? Se não, o que falta?

O NuGet provavelmente seria minha resposta. Depois de trabalhar o precursor (Nu), que estava apenas no topo do RubyGems, posso dizer que ter recursos para algo ajuda. Agora, uma vez que o trabalho acabei com uma versão corrigida do executável, porque tínhamos um repositório local além dos remotos. Ainda não tenho certeza se eles resolveram esse problema ou não, mas como eles estão aceitando patches, deve ser fácil corrigi-los. Em todos os projetos de código aberto na arena do .NET em que trabalho, agora fazemos tudo através do NuGet. É muito mais fácil, embora a publicação na cadeia demore um pouco mais.

O OpenWrap é uma opção, mas tudo precisa ser construído. O que é meio doloroso. Se você não conseguir acertar o projeto, leva um tempo para lidar. O Openwrap vem tentando resolver isso há muito tempo e ainda é realmente estranho. A distribuição binária apenas é muito mais fácil (às vezes) ...

Os outros dois com os quais não estou familiarizado. Portanto, não posso comentar muito sobre eles.

Acabei de baixar uma versão mais recente do NuGet para ver o que mudou desde a última vez. Corrija-me se estiver errado (estou realmente pensando em migrar minhas coisas para nuget):

Os pacotes NuGet ainda não especificam uma "plataforma" como uma dependência de pacote. Acabei de instalar o "Ninject" e ele referenciou a versão do .NET 4.0 em uma subpasta "pacotes". Suponho que foi o melhor palpite, pois meu projeto está na versão 4.0, mas isso é bastante perigoso de se supor. Também não entendo qual plataforma será selecionada pela dependência dos pacotes.

O recurso "Restauração de pacote" transforma minha solução adicionando uma etapa de pré-compilação personalizada. Não gosto de algo modificando meus arquivos de solução, mas isso não é um problema. Eu não entendo com que freqüência ele verifica as novas versões (eu gostaria de definir uma frequência para repositórios particulares com bastante frequência).

Posso estar totalmente errado aqui, no entanto, parece que o nuget não atualiza automaticamente a dependência do projeto quando uma versão do pacote é atualizada. A Restauração de pacotes criará uma nova subpasta para uma nova versão do pacote, no entanto, tenho que escolher manualmente essa pasta no Visual Studio, excluindo a referência com antecedência.

Alguns pacotes (como o jQuery) executam um script incorporado do PowerShell na inicialização. Eu realmente não gosto de nenhuma execução personalizada e dependência do PS, que nem sempre existe no Windows e está totalmente ausente nas compilações Mono não-Windows. A propósito, como mencionei o MSBuild anteriormente, mesmo essa dependência pode não ser realista para algumas compilações de C ++ (caso contrário, sentirei falta do recurso Restauração de Pacotes?).

O último pode não ser tão importante, no entanto, leva um tempo razoável para restaurar as dependências quando eu tenho muitas delas.

O NuGet ainda é a melhor opção neste momento.

O principal problema do NuGet como gerenciador de dependências é que ele era considerado um gerenciador de dependências com "tempo de desenvolvimento", não um gerenciador de dependências com "tempo de construção".

Um desenvolvedor restauraria um pacote NuGet através do Visual Studio ... e isso poderia executar um script do PowerShell durante a restauração que modifica os arquivos no projeto.

Isso é diferente de outros sistemas de gerenciamento de dependência que eu já vi, pois adicionar uma dependência e resolvê-la podem alterar o sistema que faz referência à dependência.

Não há mecanismo interno para garantir ou verificar a idempotência no script do PowerShell, portanto, executá-lo mais de uma vez no mesmo conjunto de arquivos pode não ser determinístico.

Parece que muitos usam o NuGet para puxar pacotes pelo Visual Studio durante o tempo de desenvolvimento, mas não conheço uma recomendação sólida sobre como isso deve funcionar em um servidor de compilação.