Para conocer las preguntas más frecuentes sobre nuget.org, como aquellas relativas a las cuentas de nuget.org, vea Preguntas más frecuentes de nuget.org.
Toda la información relacionada con las herramientas de interfaz de usuario y línea de comandos está disponible en la Guía de instalación.
La herramienta de línea de comandos, nuget.exe
, compila y se ejecuta normalmente en Windows. NuGet se puede ejecutar en sistemas operativos Unix mediante mono
, pero no es compatible oficialmente con la directiva de soporte técnico de NuGet.
Mono ha transferido la propiedad a Wine y ya no lo mantiene Microsoft.
La fuente principal para obtener información sobre un paquete es su página de listado en nuget.org (u otra fuente privada). Cada página de paquete en nuget.org incluye una descripción del paquete, su historial de versiones y estadísticas de uso. En la sección Información de la página del paquete también se incluye un vínculo al sitio web del proyecto donde normalmente encontrará muchos ejemplos y otra documentación para ayudarle a obtener información sobre cómo se usa el paquete.
Para más información, vea Búsqueda y selección de paquetes.
- Visual Studio en Windows admite la Interfaz de usuario del Administrador de paquetes y la Consola del Administrador de paquetes.
- Visual Studio para Mac tiene características integradas de NuGet, como se describe en Incluir un paquete NuGet en el proyecto.
- Visual Studio Code (todas las plataformas) no tiene ninguna integración directa de NuGet. Use la CLI de NuGet o la CLI de dotnet.
- Azure DevOps proporciona un paso de compilación para restaurar paquetes NuGet. También puede hospedar fuentes privadas de distribución de paquetes NuGet en Azure DevOps.
En Visual Studio, use el comando Ayuda > Acerca de Microsoft Visual Studio y mire la versión que se muestra junto a Administrador de paquetes NuGet.
Como alternativa, inicie la consola del Administrador de paquetes (Herramientas > Administrador de paquetes NuGet > Consola del Administrador de paquetes) y escriba $host
para ver información sobre NuGet, incluida la versión.
En general, NuGet funciona para lenguajes .NET y está diseñado para incluir bibliotecas .NET en un proyecto. Como también admite la automatización de MSBuild y Visual Studio en algunos tipos de proyecto, también admite otros proyectos y lenguajes hasta cierto punto.
La versión más reciente de NuGet es compatible con C#, Visual Basic, F#, WiX, C++ y Q#.
NuGet es totalmente compatible con una variedad de plantillas de proyecto como Windows, web, de nube, SharePoint, Wix y otras.
Vaya a la pestaña Actualizaciones en la interfaz de usuario del Administrador de paquetes y seleccione Actualizar todo, o use el comando Update-Package
desde la consola del Administrador de paquetes.
Para actualizar la plantilla propiamente dicha, debe actualizar manualmente el repositorio de plantillas. Vea el blog de Xavier Decoster sobre este tema. Tenga en cuenta que esto se realiza bajo su responsabilidad, ya que es posible que las actualizaciones manuales dañen la plantilla si la versión más reciente de todas las dependencias no es compatible entre sí.
Sí, NuGet funciona directamente desde la línea de comandos. Vea la Guía de instalación y la Referencia de la CLI.
Vea la Guía de instalación. Para comprobar la versión instalada actualmente de la herramienta, use nuget help
.
Está autorizado a redistribuir nuget.exe conforme a los términos de la licencia MIT. Es responsable de la actualización y el mantenimiento de las copias de nuget.exe que elija para redistribuir.
Sí, es posible agregar comandos personalizados a nuget.exe
, como se describe en la publicación de Rob Reynold disponible en Archive.org.
El objeto de nivel superior en el modelo de objetos de automatización de Visual Studio se denomina objeto DTE (Entorno de herramientas de desarrollo). La consola lo proporciona a través de una variable denominada $DTE
. Para más información, vea Información general del modelo de automatización en la documentación de extensibilidad de Visual Studio.
Intento convertir la variable $DTE al tipo DTE2, pero obtengo un error: No se puede convertir el valor de "EnvDTE.DTEClass" del tipo "EnvDTE.DTEClass" al tipo "EnvDTE80.DTE2". ¿Qué ocurre?
Se trata de un problema conocido de cómo interactúa PowerShell con un objeto COM. Realice lo siguiente:
`$dte2 = Get-Interface $dte ([EnvDTE80.DTE2])`
Get-Interface
es una función del asistente agregada por el host de PowerShell de NuGet.
Tengo varias versiones de la biblioteca destinadas a versiones diferentes de .NET Framework. ¿Cómo genero un único paquete que admita esto?
Vea Publicación masiva de paquetes NuGet (jeffhandly.com).
Sí, vea la entrada de blog de Scott Hanselman How to access NuGet when nuget.org is down (or you're on a plane) [Cómo obtener acceso a NuGet cuando nuget.org está inactivo (o está en un avión)] en hanselman.com.
Establezca el valor repositoryPath
de Nuget.Config
mediante nuget config -set repositoryPath=<path>
.
Establezca disableSourceControlIntegration
de Nuget.Config
en true
. Esta clave funciona en el nivel de la solución y, por tanto, debe agregarse al archivo $(Solutiondir)\.nuget\Nuget.Config
. Al habilitar la restauración de paquetes desde Visual Studio, se crea automáticamente este archivo.
¿Por qué aparece un error "No se puede resolver la dependencia" al instalar un paquete local con dependencias remotas?
Debe seleccionar el origen Todos al instalar un paquete local en el proyecto. Esto agrega todas las fuentes en lugar de usar solo una. El motivo por el que se produce este error es que los usuarios de un repositorio local a menudo quieren evitar la instalación accidental de un paquete remoto debido a las directivas de la empresa.
Tengo varios proyectos en la misma carpeta, ¿cómo puedo usar archivos packages.config independientes para cada proyecto?
En la mayoría de los proyectos en los que los proyectos independientes se encuentran en carpetas independientes, esto no es un problema ya que NuGet identifica los archivos packages.config
de cada proyecto. Con NuGet 3.3 y versiones posteriores, y varios proyectos en la misma carpeta, puede insertar el nombre del proyecto en los nombres de archivo packages.config
, usar el modelo packages.{project-name}.config
y que NuGet use ese archivo.
Esto no es un problema al usar PackageReference, ya que cada archivo de proyecto contiene su propia lista de dependencias.
- Agregue
https://api.nuget.org/v3/index.json
a la lista de orígenes, o bien - Elimine
%appdata%\.nuget\NuGet.Config
(Windows) o~/.nuget/NuGet/NuGet.Config
(Mac/Linux) y deje que NuGet se vuelve a crear.
He realizado la migración a PackageReference, ¿por qué se produce un error "Este proyecto hace referencia a paquetes NuGet que faltan en este equipo" en la compilación?
En los proyectos de packages.config, cuando se instala un paquete con propiedades o destinos build
, NuGet agrega un destino EnsureNuGetPackageBuildImports
para comprobar que el contenido MSBuild de los paquetes se ha importado antes de la compilación.
Si el destino (target
) se ha modificado manualmente, es posible que NuGet no pueda detectar que es necesario quitarlo al realizar la migración.
Si su proyecto es de PackageReference
y todavía tiene este destino en el archivo del proyecto, debería poder eliminarlo de forma segura.