project.json verwijzing

NuGet 3.x-

Het bestand project.json onderhoudt een lijst met pakketten die worden gebruikt in een project, ook wel een pakketbeheerindeling genoemd. Het vervangt packages.config, maar wordt op zijn beurt vervangen door PackageReference met NuGet 4.0+.

Het bestand project.lock.json (hieronder beschreven) wordt ook gebruikt in projecten met project.json.

project.json heeft de volgende basisstructuur, waarbij elk van de vier objecten op het hoogste niveau een willekeurig aantal onderliggende objecten kan hebben:

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

project.json migreren naar PackageReference

De migratie tussen project.json en PackageReference is eenvoudig.

Automatische migratie in Visual Studio 2026

Visual Studio 2026 en hoger migreert automatisch project.json projecten naar PackageReference wanneer u een oplossing opent die project.json projecten bevat. De migratie vindt plaats tijdens de laadtijd van de oplossing:

1. Open een oplossing met project.json projecten in Visual Studio 2026 of hoger.
2. Visual Studio detecteert automatisch project.json bestanden en migreert deze naar packageReference-indeling.
3. Als u de migratiestatus wilt controleren, opent u het uitvoervenster en selecteert u Uitvoer van Pakketbeheer weergeven. U ziet nu berichten zoals 'Migreren project.json project...' gevolgd door Migratie geslaagd voor elk project. Eventuele fouten worden weergegeven in de lijst met fouten.
4. Een back-up van het oorspronkelijke projectbestand en project.json-bestand wordt gemaakt in een Backup map in de hoofdmap van de projectmap.
5. Met de migratie worden alle pakketafhankelijkheden geconverteerd naar de PackageReference-indeling in het projectbestand.

Handmatige migratie in Visual Studio 2022

Voor Visual Studio 2022 en eerder kunt u de ingebouwde migratie gebruiken:

1. Laad het project.json project in Visual Studio.
2. Ga naar de Solution Explorer van het project.json-project en zoek het knooppunt afhankelijkheden.
3. Klik met de rechtermuisknop en selecteer Migrate project.json to PackageReference...

Alternatieve migratiemethoden

U kunt ook het opdrachtregelprogramma dotnet migreren gebruiken of de migratie handmatig uitvoeren door alle inhoud uit het project.json bestand te nemen en te vervangen door de equivalente PackageReference-syntaxis.

Afhankelijkheden

Toont de NuGet-pakketafhankelijkheden van uw project in de volgende vorm:

"PackageID" : "version_constraint"

Bijvoorbeeld:

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

In de sectie dependencies voegt het dialoogvenster NuGet Package Manager pakketafhankelijkheden toe aan uw project.

De pakket-id komt overeen met de id van het pakket op nuget.org, dezelfde als de id die wordt gebruikt in de Package Manager-console: Install-Package Microsoft.NETCore.

Bij het herstellen van pakketten impliceert de versiebeperking van "5.0.0">= 5.0.0. Als 5.0.0 niet beschikbaar is op de server, maar 5.0.1 is, installeert NuGet 5.0.1 en waarschuwt u voor de upgrade. NuGet kiest anders de laagst mogelijke versie op de server die overeenkomt met de beperking.

Zie Afhankelijkheidsoplossing voor meer informatie over oplossingsregels.

Afhankelijkheidsassets beheren

Welke assets van afhankelijkheden naar het project op het hoogste niveau stromen, wordt bepaald door een door komma's gescheiden set tags op te geven in de include en exclude eigenschappen van de afhankelijkheidsverwijzing. De tags worden weergegeven in de onderstaande tabel:

Tags die zijn opgegeven met exclude voorrang hebben op de tags die zijn opgegeven met include. include="runtime, compile" exclude="compile" is bijvoorbeeld hetzelfde als include="runtime".

Als u bijvoorbeeld de mappen build en native van een afhankelijkheid wilt opnemen, gebruikt u het volgende:

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

Als u de mappen content en build van een afhankelijkheid wilt uitsluiten, gebruikt u het volgende:

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

Kaders

Een lijst met de frameworks waarop het project wordt uitgevoerd, zoals net45, netcoreapp, netstandard.

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

Er is slechts één vermelding toegestaan in de sectie frameworks. (Een uitzondering is project.json bestanden voor ASP.NET projecten die zijn gebouwd met afgeschafte DNX-hulpprogrammaketen, waardoor meerdere doelen mogelijk zijn.)

Runtimes

Een lijst met de besturingssystemen en architecturen waarop uw app wordt uitgevoerd, zoals win10-arm, win8-x64, win8-x86.

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

Een pakket met een PCL dat kan worden uitgevoerd op elke runtime hoeft geen runtime op te geven. Dit geldt ook voor eventuele afhankelijkheden, anders moet u runtimes opgeven.

Ondersteunt

Hiermee definieert u een set controles voor pakketafhankelijkheden. U kunt definiëren waar u verwacht dat de PCL of app wordt uitgevoerd. De definities zijn niet beperkend, omdat uw code mogelijk ergens anders kan worden uitgevoerd. Maar als u deze controles opgeeft, wordt NuGet gecontroleerd of aan alle afhankelijkheden wordt voldaan op de vermelde TxMs. Voorbeelden van de waarden hiervoor zijn: net46.app, uwp.10.0.app, enzovoort.

Deze sectie moet automatisch worden ingevuld wanneer u een vermelding selecteert in het dialoogvenster Portable Class Library-doelen.

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

Invoer

Import is ontworpen om pakketten die gebruikmaken van de dotnet TxM toe te staan om te werken met pakketten die geen dotnet TxM declareren. Als uw project gebruikmaakt van de dotnet TxM, moeten alle pakketten waarvoor u afhankelijk bent, ook een dotnet TxM hebben, tenzij u het volgende toevoegt aan uw project.json om niet-dotnet platforms compatibel te laten zijn met dotnet:

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

Als u de dotnet TxM gebruikt, voegt het PCL-projectsysteem de juiste imports instructie toe op basis van de ondersteunde doelen.

Verschillen tussen draagbare apps en webprojecten

Het project.json-bestand dat door NuGet wordt gebruikt, is een subset van die in ASP.NET Core-projecten. In ASP.NET Core project.json wordt gebruikt voor projectmetagegevens, compilatiegegevens en afhankelijkheden. Bij gebruik in andere projectsystemen worden deze drie dingen opgesplitst in afzonderlijke bestanden en project.json minder informatie bevat. Belangrijke verschillen zijn:

• Er kan slechts één framework zijn in de sectie frameworks.

• Het bestand kan geen afhankelijkheden, compilatieopties, enzovoort bevatten die u in DNX-project.json-bestanden ziet. Aangezien er slechts één framework kan zijn, is het niet zinvol om frameworkspecifieke afhankelijkheden in te voeren.

• Compilatie wordt verwerkt door MSBuild, dus compilatieopties, preprocessor definieert, enzovoort maken allemaal deel uit van het MSBuild-projectbestand en niet project.json.

In NuGet 3+ wordt verwacht dat ontwikkelaars de project.jsonniet handmatig bewerken, omdat de gebruikersinterface van Package Manager in Visual Studio de inhoud bewerkt. Dat gezegd hebbende, kunt u het bestand zeker bewerken, maar u moet het project bouwen om een pakketherstel te starten of herstel op een andere manier aan te roepen. Zie Pakket herstellen.

project.lock.json

Het project.lock.json-bestand wordt gegenereerd tijdens het herstellen van de NuGet-pakketten in projecten die gebruikmaken van project.json. Het bevat een momentopname van alle informatie die wordt gegenereerd als NuGet leidt naar de grafiek met pakketten en bevat de versie, inhoud en afhankelijkheden van alle pakketten in uw project. Het buildsysteem gebruikt dit om pakketten te kiezen op een globale locatie die relevant zijn bij het bouwen van het project in plaats van afhankelijk van een lokale pakketmap in het project zelf. Dit resulteert in snellere buildprestaties omdat het nodig is om alleen-lezen project.lock.json te lezen in plaats van veel afzonderlijke .nuspec bestanden.

project.lock.json wordt automatisch gegenereerd bij pakketherstel, zodat het kan worden weggelaten uit broncodebeheer door het toe te voegen aan .gitignore en .tfignore bestanden (zie Pakketten en broncodebeheer. Als u deze echter opneemt in broncodebeheer, worden in de wijzigingsgeschiedenis wijzigingen in afhankelijkheden weergegeven die in de loop van de tijd zijn opgelost.