Referencia de project.json
Importante
Este contenido ha quedado en desuso. Los proyectos deben usar los formatos packages.config
o PackageReference.
NuGet 3.x y versiones posteriores
El archivo project.json
mantiene una lista de los paquetes que se usan en un proyecto, conocida como formato de administración de paquetes. Sustituye a packages.config
pero, a su vez, se sustituye por PackageReference con NuGet 4.0 y versiones posteriores.
El archivo project.lock.json
(descrito a continuación) también se usa en los proyectos que emplean project.json
.
project.json
tiene la siguiente estructura básica, donde cada uno de los cuatro objetos de nivel superior puede tener cualquier número de objetos secundarios:
{
"dependencies": {
"PackageID" : "{version_constraint}"
},
"frameworks" : {
"TxM" : {}
},
"runtimes" : {
"RID": {}
},
"supports" : {
"CompatibilityProfile" : {}
}
}
Enumera las dependencias de paquetes NuGet del proyecto en el formato siguiente:
"PackageID" : "version_constraint"
Por ejemplo:
"dependencies": {
"Microsoft.NETCore": "5.0.0",
"System.Runtime.Serialization.Primitives": "4.0.10"
}
En la sección dependencies
, el cuadro de diálogo Administrador de paquetes NuGet agrega las dependencias de paquetes al proyecto.
El identificador del paquete se corresponde con el identificador del paquete en nuget.org, el mismo que se usa en la consola del Administrador de paquetes: Install-Package Microsoft.NETCore
.
Al restaurar paquetes, la restricción de versión de "5.0.0"
implica >= 5.0.0
. Es decir, si 5.0.0 no está disponible en el servidor pero 5.0.1 sí lo está, NuGet instala 5.0.1 y le advierte de la actualización. En caso contrario, NuGet elige la versión más baja posible en el servidor que coincida con la restricción.
Vea Resolución de dependencias para obtener más detalles sobre las reglas de resolución.
Los activos que fluyen desde las dependencias al proyecto de nivel superior se controlan mediante la especificación de un conjunto delimitado por comas de etiquetas en las propiedades include
y exclude
de la referencia de dependencia. Las etiquetas se muestran en la tabla siguiente:
Etiqueta Include o Exclude | Carpetas afectadas del destino |
---|---|
contentFiles | Contenido |
motor en tiempo de ejecución | Runtime, Resources y FrameworkAssemblies |
compile | lib |
build | build (propiedades y destinos de MSBuild) |
nativas | nativas |
None | Sin carpetas |
all | Todas las carpetas |
Las etiquetas especificadas con exclude
tienen prioridad sobre las que se especifican con include
. Por ejemplo, include="runtime, compile" exclude="compile"
es lo mismo que include="runtime"
.
Por ejemplo, para incluir las carpetas build
y native
de una dependencia, use lo siguiente:
{
"dependencies": {
"packageA": {
"version": "1.0.0",
"include": "build, native"
}
}
}
Para excluir las carpetas content
y build
de una dependencia, use lo siguiente:
{
"dependencies": {
"packageA": {
"version": "1.0.0",
"exclude": "contentFiles, build"
}
}
}
Enumera las plataformas en las que se ejecuta el proyecto, como net45
, netcoreapp
o netstandard
.
"frameworks": {
"netcore50": {}
}
En la sección frameworks
solo se permite una entrada. (Una excepción son los archivos project.json
de los proyectos ASP.NET que se compilan con la cadena de herramientas DNX en desuso, lo que permite varios destinos).
Enumera los sistemas operativos y arquitecturas en los que se ejecuta la aplicación, como win10-arm
, win8-x64
o win8-x86
.
"runtimes": {
"win10-arm": { },
"win10-arm-aot": { },
"win10-x86": { },
"win10-x86-aot": { },
"win10-x64": { },
"win10-x64-aot": { }
}
Un paquete con una PCL que se puede ejecutar en cualquier runtime no tiene que especificar un runtime. Esto también se aplica a todas las dependencias; en caso contrario, se deben especificar runtimes.
Define un conjunto de comprobaciones de dependencias de paquete. Puede definir dónde se espera que se ejecute la PCL o aplicación. Las definiciones no son restrictivas, dado que es posible que el código se ejecute en otro lugar. Pero, al especificar estas comprobaciones, NuGet debe comprobar que se cumplan todas las dependencias en los TxM indicados. Ejemplos de los valores para esto son: net46.app
, uwp.10.0.app
, etc.
Esta sección se debería rellenar automáticamente al seleccionar una entrada en el cuadro de diálogo de destinos Biblioteca de clases portable.
"supports": {
"net46.app": {},
"uwp.10.0.app": {}
}
Las importaciones están diseñadas para permitir que los paquetes que usan el TxM dotnet
funcionen con paquetes que no declaran un TxM de dotnet. Si en el proyecto se usa el TxM dotnet
, todos los paquetes de los que depende también deben tener un TxM dotnet
, a menos que agregue lo siguiente a project.json
para permitir que las plataformas que no sean de dotnet
sean compatibles con dotnet
:
"frameworks": {
"dotnet": { "imports" : "portable-net45+win81" }
}
Si se usa el TxM dotnet
, el sistema de proyecto de PCL agrega la instrucción imports
adecuada según los destinos admitidos.
El archivo project.json
que usa NuGet es un subconjunto del que se encuentra en proyectos de ASP.NET Core. En ASP.NET Core se usa project.json
para metadatos del proyecto, información de compilación y dependencias. Cuando se usa en otros sistemas de proyecto, esos tres elementos se dividen en archivos independientes y project.json
contiene menos información. Las diferencias principales incluyen:
Solo puede haber una plataforma en la sección
frameworks
.El archivo no puede contener las dependencias, opciones de compilación, etc., que se ven en archivos
project.json
de DNX. Dado que solo puede haber una plataforma, no tiene sentido especificar dependencias específicas de la plataforma.La compilación se controla mediante MSBuild, por lo que las opciones de compilación, definiciones del preprocesador, etc., todas forman parte del archivo de proyecto de MSBuild y no de
project.json
.
En NuGet 3 y versiones posteriores, no se espera que los desarrolladores modifiquen manualmente el archivo project.json
, dado que el contenido se manipula en la interfaz de usuario del Administrador de paquetes de Visual Studio. Es decir, por supuesto se puede modificar el archivo, pero se debe compilar el proyecto para iniciar una restauración del paquete o invocar la restauración de otro modo. Vea Restauración de paquetes.
El archivo project.lock.json
se genera en el proceso de restauración de los paquetes NuGet en proyectos que usan project.json
. Contiene una instantánea de toda la información que se genera mientras NuGet recorre el gráfico de los paquetes e incluye la versión, contenido y dependencias de todos los paquetes del proyecto. El sistema de compilación usa esto para elegir los paquetes desde una ubicación global que son pertinentes al compilar el proyecto en lugar de depender de una carpeta de paquetes local en el propio proyecto. Esto supone un mayor rendimiento de compilación porque solo es necesario leer project.lock.json
en lugar de muchos archivos .nuspec
independientes.
project.lock.json
se genera automáticamente al restaurar el paquete, por lo que se puede omitir en el control de código fuente agregándolo a los archivos .gitignore
y .tfignore
(vea Paquetes y control de código fuente). Pero si se incluye en el control de código fuente, el historial de cambios muestra los cambios en las dependencias resueltos en el tiempo.