Práticas recomendadas com Nuget: Depurar ou liberar?

Atualmente, empacoto as compilações de lançamento com Nuget para as compilações oficiais em nuget.org, mas empacoto as compilações de depuração com Nuget para os envios de fonte de símbolo para symbolsource.org.

EDITAR: (Jon Skeet, com algum viés do desenvolvimento da Noda Time)

O NuGet agora oferece suporte para envio à galeria do NuGet e aos symbolsource.org (ou servidores semelhantes), conforme documentado . Infelizmente, existem dois requisitos contraditórios aqui:

• Ao usar uma biblioteca sem qualquer necessidade de depuração, você realmente deseja uma versão de lançamento. Afinal, é para isso que servem as versões de lançamento.
• Ao depurar em uma biblioteca para fins de diagnóstico, você realmente deseja uma compilação de depuração com todas as otimizações apropriadas desabilitadas. Afinal, é para isso que servem as compilações de depuração.

Isso seria ótimo, mas o NuGet não permite (até onde eu sei) permite que as compilações de lançamento e depuração sejam publicadas de uma maneira útil, no mesmo pacote.

Então, as opções são:

• Distribua as compilações de depuração para todos (conforme mostrado no exemplo nos documentos) e viva com qualquer tamanho e desempenho.
• Distribua as compilações de lançamento para todos e viva com uma experiência de depuração ligeiramente prejudicada.
• Escolha uma política de distribuição realmente complicada, potencialmente fornecendo pacotes separados de lançamento e depuração.

Os dois primeiros realmente se resumem ao efeito das diferenças entre as compilações de depuração e de lançamento ... embora seja importante notar que também há uma grande diferença entre querer entrar no código de uma biblioteca porque você deseja verificar algum comportamento e querer para depurar o código de uma biblioteca porque você acredita que encontrou um bug. No segundo caso, provavelmente é melhor pegar o código da biblioteca como uma solução do Visual Studio e depurar dessa forma, então não estou prestando muita atenção nessa situação.

Minha tentação é apenas continuar com os builds de lançamento, com a expectativa de que relativamente poucas pessoas precisarão depurar, e aqueles que precisam não serão muito afetados pelas otimizações no build de lançamento. (O compilador JIT faz a maior parte da otimização de qualquer maneira.)

Então, há outras opções que não consideramos? Existem outras considerações que fazem pender a balança? O envio de pacotes NuGet para a SymbolSource é suficientemente novo para que as "melhores práticas" não tenham sido estabelecidas?

Falando pela SymbolSource, acredito que a prática recomendada é:

1. Envie pacotes binários de lançamento + conteúdo apenas para nuget.org (ou qualquer outro feed de produção)
2. Envie pacotes binários de depuração + conteúdo para um feed de desenvolvimento:
   • na premissa
   • em myget.org
   • em nuget.org como pacotes de pré-lançamento.
3. Envie os pacotes de símbolos binários de liberação e depuração para symbolsource.org ou qualquer outro armazenamento de símbolos.

Enquanto estamos nisso, é um equívoco comum que as compilações de lançamento e depuração no .NET realmente diferem muito, mas estou assumindo que a diferenciação está aqui por causa de vários códigos que podem ou não estar incluídos em qualquer uma das compilações, como Debug .Avaliações.

Dito isso, realmente vale a pena enviar ambas as configurações para o SymbolSource, porque você nunca sabe quando precisará depurar o código de produção. Remotamente em produção para torná-lo mais difícil. Você precisará da ajuda que poderá obter com seu ferramental quando isso acontecer. O que obviamente não desejo a ninguém.

Ainda há uma questão a considerar em relação ao controle de versão: é correto ter 2 pacotes diferentes (compilados na depuração e na versão) compartilhando 1 número de versão? SymbolSource aceitaria isso, porque extrai pacotes e armazena binários em ramos de modo de compilação separados, SE SÓ o NuGet tiver permissão para marcar os pacotes de acordo. No momento, não há como determinar se um pacote está em modo de depuração ou de lançamento.

Eu concordo totalmente com sua conclusão. Pacotes NuGet com RELEASE e SymbolSource com depuração. Parece muito raro entrar diretamente em pacotes e o erro ocasional de depuração com otimizações habilitadas pode ser aceitável.

Se realmente houvesse um problema, acho que a solução ideal seria ter o suporte do NuGet. Por exemplo, imagine se, durante a depuração, ele pudesse substituir a DLL de lançamento pela incluída no pacote SymbolSource.

Idealmente, o que aconteceria então é que nuget pack SomePackage -Symbolscontra uma versão de lançamento criaria um pacote nuget de lançamento, mas um pacote de símbolos de depuração. E o plug-in VS seria atualizado para ser inteligente o suficiente para ver a associação e extrair os assemblies de depuração ao ser executado em um depurador e carregá-los. Meio louco, mas seria interessante.

No entanto, eu simplesmente não vejo pessoas reclamando sobre isso para que valha a pena no momento.

A equipe do NuGet aceita solicitações pull. :)

O exemplo em Criando e publicando um pacote de símbolos faz referência a arquivos nos diretórios de depuração como fontes para os arquivos dll e pdb.

Especificando o conteúdo do pacote de símbolos

Um pacote de símbolos pode ser construído por convenções, a partir de uma pasta estruturada da maneira descrita na seção anterior, ou seu conteúdo pode ser especificado usando a seção de arquivos. Se você quiser construir o pacote de exemplo descrito anteriormente, pode colocá-lo em seu arquivo nuspec:

<files>
  <file src="Full\bin\Debug\*.dll" target="lib\net40" /> 
  <file src="Full\bin\Debug\*.pdb" target="lib\net40" /> 
  <file src="Silverlight\bin\Debug\*.dll" target="lib\sl40" /> 
  <file src="Silverlight\bin\Debug\*.pdb" target="lib\sl40" /> 
  <file src="**\*.cs" target="src" />
</files>

Visto que o propósito de publicar os símbolos é permitir que outros percorram seu código durante a depuração, parece mais prudente publicar uma versão do código destinada à depuração sem otimizações que possam afetar a etapa de código.