Talvez eu esteja empurrando o envelope aqui, mas estou desesperado para alavancar o NuGet para facilitar o Inferno da DLL em que me encontrei.

Temos 4 produtos principais que todos vivem em repositórios inter-relacionados do Mercurial. Todos eles "compartilham" 3 conjuntos principais e, em seguida, todo o resto é praticamente específico do produto. Tornou-se muito difícil gerenciar agora porque um produto foi atualizado para o .NET 4.0 e está usando dependências externas que exigem o .NET 4.0, enquanto outro produto está preso no .NET 3.5 por motivos que eu nem quero entrar.

Então, perdemos nossa capacidade de mesclar diferenças entre produtos.

Para consertar isso, eu quero remover os 3 principais conjuntos e transformá-los em seu próprio projeto com seu próprio ciclo de lançamento, e tome cuidado para ter certeza de que eles podem compilar tanto no .NET 3.5 quanto no 4.0 e transformá-los em Pacotes NuGet contendo várias versões do framework.

MAS, também quero que os desenvolvedores possam procurar a origem desses projetos.

Então eu montei umservidor privado do NuGet e umservidor privado SymbolSource. Então eu cuidadosamente juntei todas as mudanças de todos os repositórios e joguei fora tudo, exceto minhas montagens principais. Depois, editei meticulosamente os arquivos .csproj para que, em vez da plataforma AnyCPU, cada projeto tenha alvos de plataforma de 3.5 e 4.0, que especifica constantes condicionais (para controlar recursos específicos da plataforma, como System.Dynamic) e define a versão do framework.

Em seguida, configurei as configurações de solução para "3.5 Debug", "3.5 Release", "4.0 Debug" e "4.0 Release". Cada um tem como alvo a Configuração (Depuração ou Liberação) e a Plataforma (3.5 ou 4.0) apropriadas.

Eu posso construir tudo bem no Visual Studio para qualquer plataforma. Agora eu tenho um problema quando se trata de NuGet, porque há duas maneiras de criar um pacote, e ambos têm uma fraqueza, a menos que eu esteja faltando alguma coisa:

Pacote por Arquivo de Projeto

nuget pack MyProject.csproj -Build -Symbols -Version <insert-from-build-server> -Properties "Configuration=Release;Platform=3.5;"

Os problemas com isso são:

Enquanto a versão 3.5 é construída e empacotada, a saída diz "Construindo o projeto para a estrutura de destino '.NETFramework, Version = v4.0'."Se eu descompactar os pacotes resultantes, os conjuntos estão soblib\net40 o que está errado.Eu não acho que há alguma maneira de empacotar dois alvos de framework dessa maneira, você tem que fazer o contrário com pastas e convenções.Estou disposto a aceitar que você não pode empacotar os frameworks juntos e fazer 2 pacotes chamados MyProject (que eu faria como 4.0) e MyProject.V35 ... no entanto eu não consigo descobrir como ter o mesmo projeto e nuspec e acabe com 2 resultados diferentes com ids diferentes.

Pacote por Arquivo Nuspec

Com este método, eu tenho que fazer todo o msbuilding eu mesmo e, em seguida, fazer um monte de cópia de arquivos para configurar uma estrutura de pastas como

* MyProject.nuspec
* net40
    * MyProject.dll
    * MyProject.pdb
* net35
    * MyProject.dll
    * MyProject.pdb

Então eu posso corrernuget pack MyProject.nuspec mas não há fonte para usar os símbolos, porque sem o arquivo .csproj, o NuGet não tem como descobrir onde obter todos os arquivos de origem, e não vejo nenhuma documentação sobre como fazer isso usando convenções de diretório ou.

Então minhas perguntas são:

Existe uma maneira de adicionar arquivos de origem a um pacote baseado em convenção?Existe uma maneira de empacotar um pacote baseado em projeto duas vezes com ids diferentes?Existe outra avenida que talvez eu não tenha considerado?

Qualquer pensamento seria muito apreciado.