referencia de project.json
Importante
Este contenido está en desuso. Los proyectos deben usar los formatos PackageReference. Aprenda a migrar el proyecto de project.json a PackageReference.
nuGet 3.x
El archivo project.json mantiene una lista de paquetes usados en un proyecto, conocido como formato de administración de paquetes. Reemplaza a packages.config pero, a su vez, se sustituye por PackageReference con NuGet 4.0+.
El archivo project.lock.json (que se describe a continuación) también se usa en 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" : {}
}
}
La migración entre project.json y PackageReference es sencilla. La manera más fácil de hacerlo para usar el migrador integrado en la versión más reciente de Visual Studio 2022, Update 14.
- Cargue el proyecto de project.json en Visual Studio.
- Vaya al Explorador de soluciones del proyecto de project.json y busque el nodo dependencias.
- Haga clic en
Migrate project.json to PackageReference...!
Como alternativa, puede usar el dotnet migrateo realizar la migración manualmente tomando todo el contenido del archivo de project.json y reemplazarlo por la sintaxis PackageReference equivalente.
Enumera las dependencias del paquete NuGet del proyecto de la siguiente forma:
"PackageID" : "version_constraint"
Por ejemplo:
"dependencies": {
"Microsoft.NETCore": "5.0.0",
"System.Runtime.Serialization.Primitives": "4.0.10"
}
La sección dependencies es donde el cuadro de diálogo Administrador de paquetes NuGet agrega dependencias de paquetes al proyecto.
El identificador de paquete corresponde al identificador del paquete en nuget.org , igual que el identificador usado 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 es, NuGet instala 5.0.1 y le advierte sobre la actualización. De lo contrario, NuGet elige la versión más baja posible en el servidor que coincide con la restricción.
Consulte de resolución de dependencias para obtener más información sobre las reglas de resolución.
Qué recursos de las dependencias fluyen al proyecto de nivel superior se controla especificando un conjunto de etiquetas delimitado por comas en las propiedades include y exclude de la referencia de dependencia. Las etiquetas se enumeran en la tabla siguiente:
| Etiqueta Include/Exclude | Carpetas afectadas del destino |
|---|---|
| contentFiles | Contenido |
| Ejecución | Runtime, Resources y FrameworkAssemblies |
| compilar | Lib |
| construir | build (propiedades y destinos de MSBuild) |
| nativo | nativo |
| ninguno | Sin carpetas |
| todo | Todas las carpetas |
Las etiquetas especificadas con exclude tienen prioridad sobre las especificadas con include. Por ejemplo, include="runtime, compile" exclude="compile" es igual 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 los marcos en los que se ejecuta el proyecto, como net45, netcoreapp, netstandard.
"frameworks": {
"netcore50": {}
}
Solo se permite una sola entrada en la sección frameworks. (Una excepción es project.json archivos para proyectos de ASP.NET que se compilan con la cadena de herramientas DNX en desuso, lo que permite varios destinos).
Enumera los sistemas operativos y las arquitecturas en los que se ejecuta la aplicación, como win10-arm, win8-x64, win8-x86.
"runtimes": {
"win10-arm": { },
"win10-arm-aot": { },
"win10-x86": { },
"win10-x86-aot": { },
"win10-x64": { },
"win10-x64-aot": { }
}
Un paquete que contiene una PCL que se puede ejecutar en cualquier entorno de ejecución no necesita especificar un tiempo de ejecución. Esto también debe ser true de las dependencias; de lo contrario, debe especificar los entornos de ejecución.
Define un conjunto de comprobaciones para las dependencias del paquete. Puede definir dónde espera que se ejecute la PCL o la aplicación. Las definiciones no son restrictivas, ya que el código puede ejecutarse en otro lugar. Pero al especificar estas comprobaciones, NuGet comprueba que todas las dependencias se cumplan en los txM enumerados. Algunos ejemplos de los valores para esto son: net46.app, uwp.10.0.app, etc.
Esta sección se debe rellenar automáticamente al seleccionar una entrada en el cuadro de diálogo Destinos de la 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 dotnet TxM funcionen con paquetes que no declaran un dotnet TxM. Si el proyecto usa el dotnet TxM, todos los paquetes de los que depende también deben tener un dotnet TxM, a menos que agregue lo siguiente a su project.json para permitir que las plataformas que no sean de dotnet sean compatibles con dotnet:
"frameworks": {
"dotnet": { "imports" : "portable-net45+win81" }
}
Si usa el dotnet TxM, el sistema de proyectos PCL agrega la instrucción imports adecuada en función de los destinos admitidos.
El archivo project.json usado por NuGet es un subconjunto de que se encuentra en ASP.NET proyectos principales. En ASP.NET core project.json se usa para metadatos del proyecto, información de compilación y dependencias. Cuando se usa en otros sistemas de proyecto, estas tres cosas se dividen en archivos independientes y project.json contienen menos información. Entre las diferencias importantes se incluyen las siguientes:
Solo puede haber un marco en la sección
frameworks.El archivo no puede contener dependencias, opciones de compilación, etc. que vea en archivos
project.jsonDNX. Dado que solo puede haber un único marco, no tiene sentido especificar dependencias específicas del marco.MsBuild controla la compilación, por lo que las opciones de compilación, el preprocesador define, etc. forman parte del archivo de proyecto de MSBuild y no
project.json.
En NuGet 3+, no se espera que los desarrolladores editen manualmente el project.json, ya que la interfaz de usuario del Administrador de paquetes en Visual Studio manipula el contenido. Dicho esto, sin duda puede editar el archivo, pero debe compilar el proyecto para iniciar una restauración de paquete o invocar la restauración de otra manera. Consulte restauración de paquetes .
El archivo project.lock.json se genera en el proceso de restaurar los paquetes NuGet en proyectos que usan project.json. Contiene una instantánea de toda la información que se genera a medida que NuGet recorre el gráfico de paquetes e incluye la versión, el contenido y las dependencias de todos los paquetes del proyecto. El sistema de compilación lo usa para elegir paquetes de una ubicación global que sea relevante al compilar el proyecto en lugar de en función de una carpeta de paquetes locales en el propio proyecto. Esto da como resultado un rendimiento de compilación más rápido porque es necesario leer solo project.lock.json en lugar de muchos archivos de .nuspec independientes.
project.lock.json se genera automáticamente en la restauración de paquetes, por lo que se puede omitir desde el control de código fuente agregándolo a archivos .gitignore y .tfignore (consulte Paquetes y control de código fuente. Sin embargo, si lo incluye en el control de código fuente, el historial de cambios muestra los cambios en las dependencias resueltas a lo largo del tiempo.