Leer en inglés Editar

Compartir a través de


Preguntas más frecuentes de NuGet

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.

General

¿Qué se necesita para ejecutar NuGet?

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.

¿Admite NuGet Mono?

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.

¿Cómo puedo averiguar lo que contiene un paquete y si es estable y útil para mi aplicación?

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.

NuGet en Visual Studio

¿Cómo se admite NuGet en los diferentes productos de Visual Studio?

¿Cómo puedo comprobar la versión exacta de las herramientas de NuGet que están instaladas?

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.

¿Qué lenguajes de programación son compatibles con NuGet?

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#.

¿Qué plantillas de proyecto son compatibles con NuGet?

NuGet es totalmente compatible con una variedad de plantillas de proyecto como Windows, web, de nube, SharePoint, Wix y otras.

¿Cómo puedo actualizar los paquetes que forman parte de plantillas de Visual Studio?

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í.

¿Puedo usar NuGet fuera de Visual Studio?

Sí, NuGet funciona directamente desde la línea de comandos. Vea la Guía de instalación y la Referencia de la CLI.

Línea de comandos de NuGet

¿Cómo puedo obtener la versión más reciente de la herramienta de línea de comandos de NuGet?

Vea la Guía de instalación. Para comprobar la versión instalada actualmente de la herramienta, use nuget help.

¿Cuál es la licencia de nuget.exe?

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.

¿Es posible extender la herramienta de línea de comandos de NuGet?

Sí, es posible agregar comandos personalizados a nuget.exe, como se describe en la publicación de Rob Reynold disponible en Archive.org.

Consola del Administrador de paquetes NuGet (Visual Studio en Windows)

¿Cómo puedo obtener acceso al objeto DTE en la consola del Administrador de paquetes?

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.

Creación y publicación de paquetes

¿Cómo puedo mostrar el paquete en una fuente?

Tengo varias versiones de la biblioteca destinadas a versiones diferentes de .NET Framework. ¿Cómo genero un único paquete que admita esto?

¿Cómo configuro mi propio repositorio o fuente?

¿Cómo puedo cargar paquetes a mi fuente de NuGet de forma masiva?

Trabajar con paquetes

¿Es posible instalar paquetes NuGet sin conectividad a Internet?

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.

¿Cómo instalo paquetes en una ubicación distinta de la carpeta de paquetes predeterminada?

Establezca el valor repositoryPath de Nuget.Config mediante nuget config -set repositoryPath=<path>.

¿Cómo puedo evitar que la carpeta de paquetes NuGet se agregue al control de código fuente?

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.

¿Cómo se desactiva la restauración de paquetes?

¿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.

No veo nuget.org en mi lista de repositorios, ¿cómo lo recupero?

  • 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.