NuGet frente a SDK como referencia de proyecto

Este artículo está diseñado para ayudar a los desarrolladores a elegir si empaquetan su software como un paquete NuGet o como un kit de desarrollo de software (SDK). En concreto, se describen las diferencias entre los dos cuando se hace referencia a ellas en un proyecto de Visual Studio.

  • NuGet es un sistema de administración de paquetes de código abierto que simplifica el proceso de incorporación de bibliotecas en un proyecto. Para .NET (incluido .NET Core), NuGet es el mecanismo compatible con Microsoft para compartir código. NuGet define cómo se crean, hospedan y consumen los paquetes de .NET y proporcionan las herramientas para cada uno de esos roles. En Visual Studio, agregará paquetes NuGet a un proyecto mediante la interfaz de usuario Administrador de paquetes.

  • Un SDK es una colección de archivos que Visual Studio trata como un único elemento de referencia. En el cuadro de diálogo Administrador de referencias de Visual Studio se enumeran todos los SDK que son relevantes para el proyecto actual al elegir Agregar referencia. Al agregar un SDK a un proyecto, puede acceder a todo el contenido de ese SDK a través de IntelliSense, la ventana Cuadro de herramientas, los diseñadores, el Examinador de objetos, MSBuild, la implementación, la depuración y el empaquetado.

¿Qué mecanismo debo usar?

La tabla siguiente le ayuda a comparar las características de referencia de un SDK con las características de referencia de NuGet.

Característica Compatibilidad con el SDK Notas del SDK Compatibilidad con NuGet Notas de NuGet
El mecanismo hace referencia a una entidad y, después, todos los archivos y funcionalidades están disponibles. Y Para agregar un SDK, use el cuadro de diálogo Administrador de referencias. Todos los archivos y funcionalidades están disponibles durante el flujo de trabajo de desarrollo. Y
MSBuild consume automáticamente ensamblados y archivos de metadatos de Windows (.winmd). Y Las referencias del SDK se pasan automáticamente al compilador. Y
MSBuild consume automáticamente los archivos .h o .lib. Y El archivo nombreDeSDK.props indica a Visual Studio cómo configurar el directorio de Visual C++, etc., para el consumo automático de archivos .h o .lib. N
MSBuild consume automáticamente los archivos .js o .css. Y En el Explorador de soluciones, puede expandir el nodo de referencia de SDK de JavaScript para mostrar archivos individuales .js o .css y, después, generar etiquetas <source include/> arrastrando esos archivos a sus archivos de origen. El SDK es compatible con F5 y con la instalación de paquetes automática. Y
MSBuild agrega automáticamente el control en el Cuadro de herramientas. Y El Cuadro de herramientas puede consumir SDK y mostrar controles en las pestañas que especifique. N
El mecanismo admite el instalador de Visual Studio para extensiones (VSIX). Y VSIX tiene un manifiesto y lógica especiales para crear paquetes de SDK. Y VSIX se puede insertar en otro programa de instalación.
El Examinador de objetos enumera las referencias. Y El Examinador de objetos obtiene automáticamente la lista de referencias de los SDK y las enumera. N
Los archivos y los vínculos se agregan automáticamente al cuadro de diálogo Administrador de referencias (los vínculos de ayuda, etc., se rellenan automáticamente). Y En el cuadro de diálogo Administrador de referencias se enumeran automáticamente los SDK, junto con los vínculos de ayuda y la lista de dependencias de SDK. N NuGet proporciona su propio cuadro de diálogo Administrar paquetes NuGet.
El mecanismo admite varias arquitecturas. Y Los SDK pueden incluir varias configuraciones. MSBuild consume los archivos adecuados para cada configuración de proyecto. N
El mecanismo admite varias configuraciones. Y Los SDK pueden incluir varias configuraciones. En función de la arquitectura del proyecto, MSBuild consume los archivos adecuados para cada arquitectura de proyecto. N
El mecanismo puede especificar "no para la copia". Y En función de si se quitan los archivos de la carpeta \redist o \designtime, puede controlar qué archivos se copian en el paquete de la aplicación de consumo. N Debe declarar qué archivos se copian en el manifiesto del paquete.
El contenido aparece en archivos localizados. Y Los documentos XML localizados de los SDK se incluyen automáticamente para ofrecer una mejor experiencia en tiempo de diseño. N
MSBuild admite el consumo de varias versiones de un SDK simultáneamente. Y El SDK admite el consumo de varias versiones simultáneamente. N Esto no es equivalente a hacer referencia. No puede tener a la vez más de una versión de archivos NuGet en el proyecto.
El mecanismo admite la especificación de plataformas de destino aplicables, versiones de Visual Studio y tipos de proyectos. Y En el cuadro de diálogo Administrador de referencias y en el Cuadro de herramientas solo se muestran los SDK que se aplican a un proyecto, para que los usuarios puedan elegir más fácilmente los SDK adecuados. Y (parcialmente) Pivot es la plataforma de destino. No hay filtrado en la interfaz de usuario. Durante la instalación, podría devolver un error.
El mecanismo admite la especificación de información de registro para archivos WinMD nativos. Y Puede especificar la correlación entre el archivo .winmd y el archivo .dll en SDKManifest.xml. N
El mecanismo admite la especificación de dependencias en otros SDK. Y El SDK solo notifica al usuario, y este debe instalarlos y hacer referencia a ellos de forma manual. Y NuGet los extrae automáticamente, sin que se notifique al usuario.
El mecanismo se integra con conceptos de Microsoft Store, como el manifiesto de la aplicación y el identificador de marco. Y El SDK debe pasar conceptos específicos de store para que el empaquetado y F5 funcionen correctamente con los SDK disponibles en theStore. N
El mecanismo se integra con la canalización de depuración de aplicaciones para aplicaciones de la Tienda Windows 8.x. Y El SDK debe pasar conceptos específicos de la Tienda para que el empaquetado y F5 funcionen correctamente con los SDK disponibles en la Tienda. Y El contenido de NuGet pasa a formar parte del proyecto. No se necesita ninguna consideración especial de F5.
El mecanismo se integra con los manifiestos de la aplicación. Y El SDK debe pasar conceptos específicos de la Tienda para que el empaquetado y F5 funcionen correctamente con los SDK disponibles en la Tienda. Y El contenido de NuGet pasa a formar parte del proyecto. No se necesita ninguna consideración especial de F5.
El mecanismo implementa archivos que no son de referencia (por ejemplo, implementa el marco de pruebas en el que se ejecutan pruebas de aplicaciones de la Tienda Windows 8.x). Y Si coloca los archivos en la carpeta \redist, se implementan automáticamente. Y
El mecanismo agrega automáticamente los SDK de plataforma en el IDE de Visual Studio. Y Si quitas el SDK de Windows 8 o el SDK de Windows Teléfono en una ubicación específica con un diseño específico, el SDK se integra automáticamente con todas las características de Visual Studio. N
El mecanismo admite una máquina de desarrollo limpia. (Es decir, no se requiere ninguna instalación, y funcionará una sencilla recuperación del control de código fuente). N Dado que hace referencia a un SDK, debe proteger la solución y el SDK por separado. Puede proteger el SDK desde las dos ubicaciones predeterminadas que no son del Registro desde las que MSBuild itera los SDK (para obtener más información, vea Crear un kit de desarrollo de software). Como alternativa, si una ubicación personalizada consta de los SDK, puede especificar el código siguiente en el archivo de proyecto:

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

Después, proteja los SDK en dicha ubicación.
Y Puede desproteger la solución y Visual Studio reconocerá inmediatamente los archivos y actuará sobre ellos.
Puede unirse a una gran comunidad existente de autores de paquetes. N/D La comunidad es nueva. Y
Puede unirse a una gran comunidad existente de consumidores de paquetes. N/D La comunidad es nueva. Y
Puede unirse a un ecosistema de asociados (galerías personalizadas, repositorios, etc.). N/D Los repositorios disponibles incluyen Visual Studio Marketplace, el Centro de descarga de Microsoft y Microsoft Store. Y
El mecanismo se integra con los servidores de compilación de integración continua para la creación y el consumo de paquetes. Y El SDK debe pasar la ubicación protegida (propiedad SDKReferenceDirectoryRoot) en la línea de comandos a MSBuild. Y
El mecanismo admite las versiones de paquete preliminar y estable. Y El SDK admite la adición de referencias a varias versiones. Y
El mecanismo admite la actualización automática de los paquetes instalados. Y Si se incluye como VSIX o como parte de las actualizaciones automáticas de Visual Studio, el SDK proporciona notificaciones automáticas. Y
El mecanismo contiene un archivo .exe independiente para crear y consumir paquetes. Y El SDK contiene MSBuild.exe. Y
Los paquetes se pueden proteger en el control de versiones. Y No se puede proteger nada fuera del nodo Documentos, lo que significa que los SDK de extensión podrían no estar protegidos. El SDK de extensión podría tener un gran tamaño. Y
Puede usar una interfaz de PowerShell para crear y consumir paquetes. Y (consumo), N (creación) No hay herramientas para crear un SDK. El consumo ejecuta MSBuild en la línea de comandos. Y
Puede usar un paquete de símbolos para la compatibilidad con la depuración. Y Si quita los archivos .pdb del SDK, los archivos se recogen automáticamente. Y
El mecanismo admite las actualizaciones automáticas del administrador de paquetes. N/D El SDK se revisa con MSBuild. Y
El mecanismo admite un formato de manifiesto ligero. Y SDKManifest.xml admite muchos atributos, pero normalmente solo es necesario un pequeño subconjunto. Y
El mecanismo está disponible para todas las ediciones de Visual Studio. Y El SDK es compatible con todas las ediciones de Visual Studio. Y NuGet es compatible con todas las ediciones de Visual Studio.