Skapa korrigeringar som förenklar lösningsuppdateringar

Om du lägger till en entitet i en lösning och exporterar lösningen kommer hela entiteten och samtliga dess relaterade tillgångar att exporteras i denna lösning. I dessa resurser ingår attribut, formulär, vyer, relationer och visualiseringar, samt andra resurser som paketerats tillsammans med entiteten. Export av alla objekt innebär att du oavsiktligt kan ändra objekt i måldistributionen eller överföra oönskade beroenden.

Du kan lösa problemet genom att skapa och publicera lösningskorrigeringar som innehåller delkomponenter för entiteter i stället för att publicera hela entiteten och alla dess tillgångar. Den ursprungliga lösningen och en eller flera relaterade korrigeringsfiler kan slås samman vid ett senare tillfälle i en uppdaterad version av lösningen, som sedan kan ersätta den ursprungliga lösningen i Microsoft Dataverse-målorganisationen.

Korrigeringar

Du kan tillämpa korrigeringsfiler på antingen hanterade eller icke-hanterade lösningar och endast inkludera ändringar i entiteter och relaterade entitetstillgångar. Korrigeringsfiler innehåller inga icke-anpassade systemkomponenter eller relationer som den är beroende av eftersom dessa komponenter redan finns i den distribuerade organisationen. Någon gång i din utvecklingscykel kan du slå samman alla korrigeringsfiler till en ny lösningsversion som ersätter originallösningen som korrigeringsfilerna skapades från.

Korrigeringsfiler lagras i Dataverse-databasen som Solution-entitetsposter. Ett icke-null-ParentSolutionId-attribut anger att lösningen är en korrigeringsfil. Korrigeringsfiler kan skapas och hanteras via SDK för .NET eller webb-API:er, som är användbara för utveckling av automatisering, t. ex. ett produktinstallationsskript. Webbappen Dataverse tillhandahåller emellertid olika webbformulär som gör att du interaktivt kan skapa och hantera korrigeringsfiler.

  • Det går endast att skapa korrigeringsfiler från en överordnad lösning med hjälp av CloneAsPatchRequest eller CloneAsPatch Action.

  • Den överordnade korrigeringen kan inte vara en korrigeringsfil.

  • Korrigeringsfiler kan endast ha en överordnad lösning.

  • En korrigeringsfil skapar ett beroende (på lösningsnivån) i dess överordnade lösning.

  • Du kan endast installera en korrigeringsfil om den överordnade lösningen finns.

  • Du kan inte installera en korrigeringsfil om inte det unika namnet och huvud- eller delversionsnumret för den överordnade lösningen, som identifieras av ParentSolutionId, inte matchar de för den överordnade lösningen som installerats i målorganisationen.

  • En korrigeringsversion måste ha samma huvud- och delnummer, men ett högre versions- och frisläppningsnummer än den överordnade lösningens versionsnummer. Visningsnamnet kan variera.

  • Om en lösning innehåller korrigeringsfiler måste efterföljande korrigeringsfiler ha ett numeriskt högre versionsnummer än eventuellt befintlig korrigering för den lösningen.

  • Korrigeringsfiler stöder samma åtgärder som lösningar, till exempel uppdateringar, men inte borttagning. Du kan inte ta bort komponenter från en lösning med hjälp av en korrigeringsfil. Om du vill ta bort komponenter från en lösning utför du en uppgradering.

  • Korrigeringsfiler som exporteras som hanterade måste importeras ovanpå en hanterad överordnadlösning. Regeln är att korrigeringsskydd (hanterad eller icke-hanterad) måste överensstämma med den överordnade nivån.

  • Använd inte icke-hanterade korrigeringsfiler i produktionssyfte.

  • Korrigeringsfiler stöds endast i Dataverse-organisationer med version 8.0 eller senare.

    Verktygen SolutionPackager och PackageDeployer i den här versionen stöder lösningskorrigeringar. Information om vilka kommandoradsalternativ som är relaterade till korrigeringsfiler finns i verktygets direkthjälp.

Skapa en korrigering

Skapa en korrigeringsfil från en icke-hanterad lösning i en organisation genom att använda CloneAsPatchRequest-meddelandet eller CloneAsPatch Action, eller med hjälp av webbappen. När du väl skapar korrigeringsfilen blir den ursprungliga lösningen låst, och du kan inte ändra eller exportera den så länge underordnade korrigeringar existerar i organisationen som identifierar lösningen som den överordnade lösningen. Versionstilldelningen för korrigeringen liknar lösningsversionstilldelningen och anges i följande format: major.minor.build.release. Du kan inte ändra befintliga större eller mindre lösningsversioner när du skapar en korrigeringsfil.

Exportera och importera en korrigeringsfil

Du kan använda SDK för .NET eller webb-API:erna, webbappen eller Package Deployer-verktyget för att exportera och importera en korrigeringsfil. De relevanta SDK för .NET-begäransklasser är ImportSolutionRequest och ExportSolutionRequest. De relevanta åtgärderna för webb-API:et är åtgärden ImportSolution och åtgärden ExportSolution.

Exempel på korrigeringsfiler

I följande tabell visas detaljerna för ett korrigeringsexempel. I det här exemplet importeras lösningen och korrigeringsfilerna i nummerordning och är additiva, vilket är i enlighet med lösningsimporten i allmänhet.

Namn på korrigering Beskrivning
Lösning A, version 1.0 (icke-hanterad) Innehåller en entitet A med 6 fält.
Lösning A, version 1.0,1.0 (icke-hanterad) Innehåller en entitet A med 6 fält (3 uppdaterade) och lägger till entitet B med 10 fält.
Lösning A, version 1.0,2.0 (icke-hanterad) Innehåller en entitet C med 10 fält.

Importen sker på följande sätt:

  1. Utvecklaren eller anpassaren importerar först baslösningen (Lösning 1.0) till organisationen. Resultatet är entitet A med 6 fält i organisationen.

  2. Därefter importeras korrigeringsfil 1.0.1.0 för lösning A. Organisationen innehåller nu entitet A med 6 fält (3 har uppdaterats), plus entitet B med 10 fält.

  3. Slutligen importeras korrigeringsfil 1.0.2.0 för lösning A. Organisationen innehåller nu entitet A med 6 fält (3 har uppdaterats), entitet B med 10 fält, plus entitet C med 10 fält.

Ytterligare korrigeringsexempel

Låt oss ta en titt på ett annat korrigeringsexempel med den information som visas i följande tabell.

Namn på korrigering Beskrivning
Lösning A, version 1.0 (icke-hanterad, baslösning) Innehåller den Account-entitet där kontonummerfältets längd justeras från 20 till 30 tecken.
Lösning B, version 2.0 (ickehanterad, annan leverantör) Innehåller den Account-entitet där kontonummerfältets längd justeras till 50 tecken.
Lösning A, version 1.0.1.0 (icke-hanterad, korrigeringsfil) Innehåller en uppdatering av den Account-entitet där kontonummerfältets längd justeras till 35 tecken.

Importen sker på följande sätt:

  1. Utvecklaren eller anpassaren importerar först baslösningen (Lösning 1.0) till organisationen. Resultatet är en Account-entitet med ett kontonummerfält på 30 tecken.

  2. Lösning B importeras. Organisationen innehåller nu en Account-entitet med ett kontonummerfält på 50 tecken.

  3. Korrigeringsfil 1.0.1.0 för lösning A importeras. Organisationen innehåller fortfarande en Account-entitet med ett kontonummerfält på 50 tecken, enligt tillämpat av Lösning B.

  4. Lösningen B avinstalleras. Organisationen innehåller nu en Account-entitet med ett kontonummerfält på 35 tecken, enligt tillämpat av korrigeringsfil 1.0.1.0 för Lösning A.

Ta bort en korrigeringsfil

Du kan ta bort en korrigeringsfil eller baslösning (överordnad) med hjälp av DeleteRequest eller, för webb-API, använd HTTP DELETE-metoden. Borttagnings processen skiljer sig för en hanterad eller icke-hanterad lösning som har en eller flera korrigeringsfiler som finns i organisationen.

För en icke-hanterad lösning måste du först avinstallera alla korrigeringsfiler för baslösningen, i omvänd versionsordning mot när de skapades, innan bas lösningen avinstalleras.

För en hanterad lösning avinstallerar du helt enkelt baslösningen. Dataverse-systemet avinstallerar korrigeringsfilerna automatiskt i omvänd versionsordning innan baslösningen avinstalleras. Du kan även helt enkelt avinstallera en enskild korrigeringsfil.

Uppdatera en lösning

Att uppdatera en lösning innebär att slå samman alla korrigeringar till lösningen i en ny version av lösningen. Därefter blir lösningen olåst och kan återigen ändras (endast vid icke-hanterad lösning) eller exporteras. För en hanterad lösning tillåts inga ytterligare ändringar av lösningen, förutom för att skapa korrigeringsfiler från den nyligen uppdaterade lösningen. Om du vill samla korrigeringsfiler i en icke-hanterad lösning kan du använda CloneAsSolutionRequest eller åtgärden CloneAsSolution. När du klonar en lösning skapas en ny version av den icke-hanterade lösningen som innehåller alla korrigeringsfiler, med ett högre major-minor-versionsnummer, samma unika namn och ett visningsnamn.

För en hanterad lösning hanteras saker och ting något annorlunda. Du klonar först den icke-hanterade lösningen (A) och använder alla dess korrigeringsfiler innan du exporterar den som en hanterad lösning (B). I målorganisationen som innehåller den hanterade versionen av lösningen (A) och dess korrigeringsfiler importerar du den hanterade lösningen (B) och kör sedan DeleteAndPromoteRequest eller åtgärden DeleteAndPromote för att ersätta hanterad lösning (A) och dess korrigeringsfiler med den uppgraderade hanterade lösningen (B) med ett högre versionsnummer.

Se även

Använda segmenterade lösningar