Compartilhar via


NuGet versus SDK como referência de projeto

Este artigo foi criado para ajudar os desenvolvedores a escolher se desejam empacotar seu software como um pacote NuGet ou como um SDK (kit de desenvolvimento de software). Especificamente, ele discute as diferenças entre os dois quando eles são referenciados em um projeto do Visual Studio.

  • O NuGet é um sistema de gerenciamento de pacotes de software livre que simplifica o processo de incorporação de bibliotecas em uma solução de projeto. Para o .NET (incluindo o .NET Core), o NuGet é o mecanismo com suporte da Microsoft para compartilhar código. O NuGet define como os pacotes para .NET são criados, hospedados e consumidos e fornece as ferramentas para cada uma dessas funções. No Visual Studio, você adiciona pacotes NuGet a um projeto usando a interface do usuário do Gerenciador de Pacotes.

  • Um SDK é uma coleção de arquivos que o Visual Studio trata como um único item de referência. A caixa de diálogo Gerenciador de Referências no Visual Studio lista todos os SDKs relevantes para o projeto atual quando você escolhe Adicionar Referência. Quando você adiciona um SDK a um projeto, é possível acessar todo o conteúdo desse SDK por meio do IntelliSense, da janela Caixa de Ferramentas, dos designers, do Pesquisador de Objetos, do MSBuild, da implantação, da depuração e do empacotamento.

Que mecanismo devo usar?

A tabela a seguir ajuda a comparar os recursos de referência de um SDK com os recursos de referência do NuGet.

Recurso Suporte do SDK Anotações do SDK Suporte do NuGet Anotações do NuGet
O mecanismo referencia uma entidade e, em seguida, todos os arquivos e funcionalidades estarão disponíveis. Y Você adiciona um SDK usando a caixa de diálogo Gerenciador de Referências e todos os arquivos e funcionalidades estarão disponíveis durante o fluxo de trabalho de desenvolvimento. Y
O MSBuild consome automaticamente assemblies e arquivos de metadados do Windows (.winmd). Y As referências no SDK são automaticamente passadas para o compilador. Y
O MSBuild consome automaticamente os arquivos .h ou .lib. Y O arquivo SDKName.props informa ao Visual Studio como configurar o diretório do Visual C++ e assim por diante, para consumo automático do arquivo .h ou .lib. N
O MSBuild consome automaticamente os arquivos .js ou .css. Y No Gerenciador de Soluções, é possível expandir o nó de referência do SDK do JavaScript para mostrar arquivos .js ou .css individuais e, em seguida, gerar marcações <source include/> arrastando esses arquivos para seus arquivos de origem. O SDK dá suporte ao F5 e à configuração automática do pacote. Y
O MSBuild adiciona automaticamente o controle na Caixa de Ferramentas. Y A Caixa de Ferramentas pode consumir SDKs e mostrar controles nas guias especificadas. N
O mecanismo dá suporte ao VSIX (Instalador do Visual Studio para extensões). Y O VSIX tem um manifesto e uma lógica especiais para criar pacotes do SDK Y O VSIX pode ser inserido em outro programa de instalação.
O Pesquisador de Objetos enumera as referências. Y O Pesquisador de Objetos obtém automaticamente a lista de referências em SDKs e as enumera. N
Os arquivos e links são automaticamente adicionados à caixa de diálogo Gerenciador de Referências (links de ajuda e assim por diante, preenchimento automático) Y A caixa de diálogo Gerenciador de Referências enumera os SDKs automaticamente, juntamente com links de ajuda e a lista de dependências do SDK. N O NuGet fornece sua própria caixa de diálogo Gerenciar Pacotes do NuGet.
O mecanismo dá suporte a várias arquiteturas. Y Os SDKs podem distribuir várias configurações. O MSBuild consome os arquivos apropriados para cada configuração de projeto. N
O mecanismo dá suporte a várias configurações. Y Os SDKs podem distribuir várias configurações. Dependendo da arquitetura de projeto, o MSBuild consome os arquivos apropriados para cada arquitetura de projeto. N
O mecanismo pode especificar para "não copiar". Y Dependendo se os arquivos são soltos na pasta \redist ou \designtime, é possível controlar quais arquivos devem ser copiados no pacote do aplicativo de consumo. N Você declara quais arquivos devem ser copiados no manifesto do pacote.
O conteúdo é exibido nos arquivos localizados. Y Documentos XML localizados em SDKs são incluídos automaticamente para obter uma melhor experiência do tempo de design. N
O MSBuild dá suporte ao consumo de várias versões de um SDK simultaneamente. Y O SDK dá suporte ao consumo de várias versões simultaneamente. N Isso não está referenciando. Não é possível ter mais de uma versão de arquivos NuGet em seu projeto de cada vez.
O mecanismo dá suporte à especificação de estruturas de destino, versões do Visual Studio e tipos de projeto aplicáveis. Y A caixa de diálogo Gerenciador de Referências e a Caixa de Ferramentas mostram apenas os SDKs aplicáveis a um projeto para que os usuários possam escolher mais facilmente os SDKs apropriados. Y (parcial) O Pivot é a estrutura de destino. Não há nenhuma filtragem na interface do usuário. No momento da instalação, ela pode retornar um erro.
O mecanismo dá suporte à especificação de informações de registro para WinMDs nativos. Y É possível especificar a correlação entre o arquivo .winmd e o arquivo .dll em SDKManifest.xml. N
O mecanismo dá suporte à especificação de dependências em outros SDKs. Y O SDK apenas notifica o usuário; o usuário ainda deverá instalá-las e referenciá-las manualmente. Y O NuGet as extrai automaticamente; o usuário não é notificado.
O mecanismo integra-se com conceitos da Microsoft Store como o manifesto do aplicativo e a ID do Framework. Y O SDK deve aprovar conceitos específicos da Store para que o empacotamento e o F5 funcionem corretamente com os SDKs disponíveis na Store. N
O mecanismo integra-se com os pipelines de depuração de aplicativo para aplicativos Windows 8.x Store. Y O SDK deve aprovar conceitos específicos da Store para que o empacotamento e o F5 funcionem corretamente com os SDKs disponíveis na Store. Y O conteúdo do NuGet se torna parte do projeto. Nenhuma consideração F5 especial é necessária.
O mecanismo se integra aos manifestos do aplicativo. Y O SDK deve aprovar conceitos específicos da Store para que o empacotamento e o F5 funcionem corretamente com os SDKs disponíveis na Store. Y O conteúdo do NuGet se torna parte do projeto. Nenhuma consideração F5 especial é necessária.
O mecanismo implanta os arquivos de não referência (por exemplo, implante a estrutura de testes na qual os testes de aplicativos Windows 8.x Store serão executados). Y Se você soltar os arquivos na pasta \redist, eles serão implantados automaticamente. Y
O mecanismo adiciona automaticamente os SDKs da plataforma no IDE do Visual Studio. Y Se você soltar o SDK do Windows 8 ou do Windows Phone em um local específico com um layout específico, o SDK será automaticamente integrado a todos os recursos do Visual Studio. N
O mecanismo dá suporte a um computador de desenvolvedor limpo. (Ou seja, não é necessária nenhuma instalação e a simples recuperação do controle do código-fonte funcionará.) N Como você referencia um SDK, é necessário verificar fazer check-in na sua solução e no SDK separadamente. É possível fazer check-in do SDK nos dois locais de não Registro padrão dos quais o MSBuild itera SDKs (para obter detalhes, consulte Creating a Software Development Kit (Criando um Software Development Kit)). Como alternativa, se um local personalizado for composto dos SDKs, será possível especificar o código a seguir no arquivo de projeto:

<PropertyGroup>
  <SDKReferenceDirectoryRoot>
  C:\MySDKs
  </SDKReferenceDirectoryRoot>
</PropertyGroup>

Em seguida, faça check-in dos SDKs nesse local.
Y É possível fazer check-out da solução e o Visual Studio reconhece imediatamente e age nos arquivos.
É possível ingressar a uma grande comunidade existente de autores de pacotes. N/D A comunidade é nova. Y
É possível ingressar em uma grande comunidade existente de consumidores de pacotes. N/D A comunidade é nova. Y
É possível ingressar em um ecossistema de parceiros (galerias personalizadas, repositórios e assim por diante). N/D Os repositórios disponíveis incluem Visual Studio Marketplace, o Centro de Download da Microsoft e a Microsoft Store. Y
O mecanismo se integra a servidores de build de integração contínua para criação e consumo de pacotes. Y O SDK deve passar o local com check-in (propriedade SDKReferenceDirectoryRoot) na linha de comando para o MSBuild. Y
O mecanismo dá suporte a versões do pacote estáveis e de pré-lançamento. Y O SDK dá suporte à adição de referências a várias versões. Y
O mecanismo dá suporte à atualização automática para pacotes instalados. Y Se fornecido como VSIX ou como parte de atualizações automáticas do Visual Studio, o SDK oferece notificações automáticas. Y
O mecanismo contém um arquivo .exe autônomo para criar e consumir pacotes. Y O SDK contém MSBuild.exe. Y
O check-in dos pacotes pode ser feito no controle de versão. Y Não é possível fazer check-in fora do nó Documentos, o que significa que o check-in dos SDKs da Extensão não pode ser feito. O tamanho do SDK da Extensão pode ser grande. Y
É possível usar uma interface do PowerShell para criar e consumir pacotes. Y (consumo), N (criação) Não há ferramentas para a criação de um SDK. Consumo está sendo executado o MSBuild na linha de comando. Y
É possível usar um pacote de símbolos para o suporte à depuração. Y Se você soltar arquivos .pdb no SDK, os arquivos serão selecionados automaticamente. Y
O mecanismo dá suporte a atualizações automáticas do gerenciador de pacotes. N/D O SDK é revisado com o MSBuild. Y
O mecanismo dá suporte a um formato de manifesto leve. Y O SDKManifest.xml oferece suporte a muitos atributos, mas geralmente um pequeno subconjunto é necessário. Y
O mecanismo está disponível para todas as edições do Visual Studio. Y O SDK é compatível com todas as edições do Visual Studio. Y O NuGet é compatível com todas as edições do Visual Studio.