project.json referens

Viktig

Det här innehållet är inaktuellt. Projekt bör använda PackageReference-format. Lär dig hur du migrera ditt project.json-projekt till PackageReference. Visual Studio 2026 migrerar automatiskt project.json vid lösningens inläsningstid. .NET 10 SDK & NuGet.exe 7.0 stöder inte project.json projekt.

NuGet 3.x

Filen project.json innehåller en lista över paket som används i ett projekt, som kallas pakethanteringsformat. Den ersätter packages.config men ersätts i sin tur av PackageReference med NuGet 4.0+.

Filen project.lock.json (beskrivs nedan) används också i projekt som använder project.json.

project.json har följande grundläggande struktur, där vart och ett av de fyra objekten på den översta nivån kan ha valfritt antal underordnade objekt:

{
    "dependencies": {
        "PackageID" : "{version_constraint}"
    },
    "frameworks" : {
        "TxM" : {}
    },
    "runtimes" : {
        "RID": {}
    },
    "supports" : {
        "CompatibilityProfile" : {}
    }
}

Migrera project.json till PackageReference

Migreringen mellan project.json och PackageReference är enkel.

Automatisk migrering i Visual Studio 2026

Visual Studio 2026 och senare migrerar automatiskt project.json projekt till PackageReference när du öppnar en lösning som innehåller project.json projekt. Migreringen sker vid lösningens inläsningstid:

  1. Öppna en lösning som innehåller project.json projekt i Visual Studio 2026 eller senare.
  2. Visual Studio identifierar automatiskt project.json filer och migrerar dem till PackageReference-format.
  3. Om du vill kontrollera migreringsstatusen öppnar du utdatafönstret och väljer Visa utdata från "Package Manager". Du bör se meddelanden som "Migrera project.json projekt..." följt av "Migrering lyckades" för varje projekt. Eventuella fel visas i fellistan.
  4. En säkerhetskopia av den ursprungliga projektfilen och project.json filen skapas i en Backup mapp i roten i projektkatalogen.
  5. Migreringen konverterar alla paketberoenden till PackageReference-format i projektfilen.

Manuell migrering i Visual Studio 2022

För Visual Studio 2022 och tidigare kan du använda den inbyggda migratorn:

  1. Läs in project.json-projektet i Visual Studio.
  2. Gå till lösningsutforskaren för project.json-projektet och leta reda på noden beroenden.
  3. Högerklicka och välj Migrate project.json to PackageReference...

Migrera från project.json till PackageReference

Alternativa migreringsmetoder

Du kan också använda kommandoradsverktyget dotnet migrate eller utföra migreringen manuellt genom att ta allt innehåll från filen project.json och ersätta det med motsvarande PackageReference-syntax.

Beroenden

Visar en lista över NuGet-paketberoenden för projektet i följande form:

"PackageID" : "version_constraint"

Till exempel:

"dependencies": {
    "Microsoft.NETCore": "5.0.0",
    "System.Runtime.Serialization.Primitives": "4.0.10"
}

I avsnittet dependencies läggs paketberoenden till i projektet i dialogrutan NuGet Package Manager.

Paket-ID motsvarar ID:t för paketet på nuget.org , samma som id:t som används i pakethanterarens konsol: Install-Package Microsoft.NETCore.

När du återställer paket innebär versionsbegränsningen för "5.0.0">= 5.0.0. Om 5.0.0 inte är tillgängligt på servern men 5.0.1 är, installerar NuGet 5.0.1 och varnar dig om uppgraderingen. NuGet väljer annars den lägsta möjliga versionen på servern som matchar villkoret.

Mer information om lösningsregler finns i beroendematchning.

Hantera beroendetillgångar

Vilka tillgångar från beroenden som flödar till projektet på den översta nivån styrs genom att ange en kommaavgränsad uppsättning taggar i include och exclude egenskaper för beroendereferensen. Taggarna visas i tabellen nedan:

Ta med/exkludera tagg Berörda mappar i målet
contentFiles Innehåll
Runtime Körning, resurser och FrameworkAssemblies
kompilera Lib
bygga build (MSBuild props och mål)
infödd infödd
ingen Inga mappar
alla Alla mappar

Taggar som anges med exclude ha företräde framför de som anges med include. Till exempel är include="runtime, compile" exclude="compile" samma som include="runtime".

Om du till exempel vill inkludera mapparna build och native för ett beroende använder du följande:

{
  "dependencies": {
    "packageA": {
      "version": "1.0.0",
      "include": "build, native"
    }
  }
}

Om du vill exkludera mapparna content och build för ett beroende använder du följande:

{
  "dependencies": {
    "packageA": {
      "version": "1.0.0",
      "exclude": "contentFiles, build"
    }
  }
}

Ramar

Visar de ramverk som projektet körs på, till exempel net45, netcoreapp, netstandard.

"frameworks": {
    "netcore50": {}
    }

Endast en enda post tillåts i avsnittet frameworks. (Ett undantag är project.json filer för ASP.NET projekt som skapas med inaktuell DNX-verktygskedja, vilket möjliggör flera mål.)

Körningar

Visar en lista över operativsystem och arkitekturer som appen körs på, till exempel win10-arm, win8-x64, win8-x86.

"runtimes": {
    "win10-arm": { },
    "win10-arm-aot": { },
    "win10-x86": { },
    "win10-x86-aot": { },
    "win10-x64": { },
    "win10-x64-aot": { }
}

Ett paket som innehåller en PCL som kan köras på valfri körning behöver inte ange någon körning. Detta måste också gälla för eventuella beroenden, annars måste du ange körningskörningar.

Stöder

Definierar en uppsättning kontroller för paketberoenden. Du kan definiera var du förväntar dig att PCL eller appen ska köras. Definitionerna är inte restriktiva eftersom koden kan köras någon annanstans. Men om du anger dessa kontroller kontrollerar NuGet att alla beroenden är uppfyllda på de listade TxM:erna. Exempel på värden för detta är: net46.app, uwp.10.0.apposv.

Det här avsnittet bör fyllas i automatiskt när du väljer en post i dialogrutan Portabelt klassbiblioteksmål.

"supports": {
    "net46.app": {},
    "uwp.10.0.app": {}
}

Import

Importer är utformade för att tillåta paket som använder dotnet TxM att fungera med paket som inte deklarerar en dotnet TxM. Om projektet använder dotnet TxM måste alla paket som du är beroende av också ha en dotnet TxM, såvida du inte lägger till följande i din project.json för att tillåta att icke-dotnet plattformar är kompatibla med dotnet:

"frameworks": {
    "dotnet": { "imports" : "portable-net45+win81" }
}

Om du använder dotnet TxM lägger PCL-projektsystemet till lämplig imports-instruktion baserat på de mål som stöds.

Skillnader från portabla appar och webbprojekt

Den project.json fil som används av NuGet är en delmängd av den som finns i ASP.NET Core-projekt. I ASP.NET Core används project.json för projektmetadata, kompileringsinformation och beroenden. När de används i andra projektsystem delas dessa tre saker upp i separata filer och project.json innehåller mindre information. Några viktiga skillnader är:

  • Det kan bara finnas ett ramverk i avsnittet frameworks.

  • Filen får inte innehålla beroenden, kompileringsalternativ osv. som du ser i DNX-project.json filer. Med tanke på att det bara kan finnas ett enda ramverk är det inte meningsfullt att ange ramverksspecifika beroenden.

  • Kompilering hanteras av MSBuild så kompileringsalternativ, förprocessordefinierade osv. är alla en del av MSBuild-projektfilen och inte project.json.

I NuGet 3+ förväntas utvecklare inte redigera project.jsonmanuellt eftersom Package Manager-användargränssnittet i Visual Studio manipulerar innehållet. Med det sagt kan du säkert redigera filen, men du måste skapa projektet för att starta en paketåterställning eller anropa återställning på ett annat sätt. Se Paketåterställning.

project.lock.json

Filen project.lock.json genereras i processen att återställa NuGet-paketen i projekt som använder project.json. Den innehåller en ögonblicksbild av all information som genereras när NuGet går i diagrammet över paket och innehåller version, innehåll och beroenden för alla paket i projektet. Byggsystemet använder detta för att välja paket från en global plats som är relevanta när du skapar projektet i stället för beroende på en lokal paketmapp i själva projektet. Detta resulterar i snabbare byggprestanda eftersom det är nödvändigt att endast läsa project.lock.json i stället för många separata .nuspec filer.

project.lock.json genereras automatiskt vid paketåterställning, så det kan utelämnas från källkontrollen genom att lägga till den i .gitignore och .tfignore filer (se Paket och källkontroll. Men om du inkluderar den i källkontrollen visar ändringshistoriken ändringar i beroenden som har lösts över tid.