Skicka manifestet till lagringsplatsen

När du har skapat ett paketmanifest som beskriver ditt program är du redo att skicka manifestet till Windows Package Manager-lagringsplatsen. Det här är en offentlig lagringsplats som innehåller en samling manifest som winget-verktyget kan komma åt. Om du vill skicka ditt manifest laddar du upp det till lagringsplatsen med öppen källkod https://github.com/microsoft/winget-pkgs på GitHub.

När du har skickat en pull-begäran om att lägga till ett nytt manifest på GitHub-lagringsplatsen verifierar en automatiserad process manifestfilen och kontrollerar att paketet uppfyller Windows Package Manager-principerna och inte är känt för att vara skadligt. Om verifieringen lyckas läggs paketet till på den offentliga Windows Package Manager-lagringsplatsen så att den kan identifieras av winget-klientverktyget . Observera skillnaden mellan manifesten på GitHub-lagringsplatsen med öppen källkod och den offentliga Windows Package Manager-lagringsplatsen.

Viktigt!

Microsoft förbehåller sig rätten att vägra att lämna in en begäran av någon anledning.

Manifestverifiering

När du skickar ett manifest till https://github.com/microsoft/winget-pkgs lagringsplatsen på GitHub verifieras och utvärderas manifestet automatiskt för säkerheten i Windows-ekosystemet. Manifest kan också granskas manuellt.

Mer information om valideringsprocessen finns i avsnittet om valideringsprocessen nedan.

Så här skickar du ditt manifest

Följ dessa steg för att skicka ett manifest till lagringsplatsen.

Steg 1: Verifiera manifestet

Winget-verktyget tillhandahåller verifieringskommandot för att bekräfta att du har skapat manifestet korrekt. Använd det här kommandot för att verifiera manifestet.

winget validate \<path-to-the-manifests>

Om verifieringen misslyckas använder du felen för att hitta radnumret och göra en korrigering. När manifestet har verifierats kan du skicka det till lagringsplatsen.

Steg 2: Testa manifestet med Windows Sandbox

Windows Package Manager-lagringsplatsen innehåller ett skript som installerar Windows Package Manager i en sandbox-miljö för att testa manifestöverföringar. Om du vill köra PowerShell-skriptet går du till din winget-pkgs-lagringsplats. Från PowerShell anger du följande kommando:

powershell .\Tools\SandboxTest.ps1 manifests\m\Microsoft\VisualStudioCode\1.56.0

Du kan behöva uppdatera skriptet med rätt sökväg till manifestfilen: .\Tools\SandboxTest.ps1 <path to manifest or manifest folder>

Se fullständigt sandbox-testskript i lagringsplatsen winget-pkgs.

Steg 3: Klona lagringsplatsen

Så här skapar du en förgrening av Windows Package Manager Community-lagringsplatsen och klonar lagringsplatsen till den lokala datorn:

1. Gå till https://github.com/microsoft/winget-pkgs i webbläsaren och välj Förgrening.

2. Från Windows-kommandotolken eller PowerShell använder du följande kommando för att klona din förgrening.

   git clone <your-fork-name>
   

3. Om du lämnar in flera inlämningar, skapa en gren istället för en fork. För närvarande tillåter vi bara en manifestfil per sändning.

   git checkout -b <branch-name>
   

Steg 4: Lägg till manifestet på den lokala lagringsplatsen

Du måste lägga till manifestfilerna på lagringsplatsen i följande mappstruktur:

manifest / bokstaven / utgivare / program / version

• Manifestmappen är rotmappen för alla manifest på lagringsplatsen.
• bokstav mappen är första bokstaven i utgivarens namn i gemener. Till exempel m för utgivaren Microsoft.
• Utgivarmappen är namnet på det företag som publicerar programvaran. Till exempel Microsoft.
• Applikationsmappen är namnet på applikationen eller verktyget. Till exempel VSCode.
• Versionsmappen är versionen av programmet eller verktyget. Till exempel 1.0.0.

Värdena PackageIdentifier och PackageVersion i manifestet måste matcha utgivaren, programnamnen och versionen i sökvägen till manifestmappen. Mer information finns i Skapa paketmanifestet.

Steg 5: Skicka manifestet till fjärrlagringsplatsen

Nu är du redo att skicka det nya manifestet till fjärrlagringsplatsen.

1. Använd kommandot commit för att lägga till filer, begå ändringen och ange information om insändningen.

   git commit -m "Submitting ContosoApp version 1.0.0" --all
   

2. push Använd kommandot för att skicka ändringarna till fjärrlagringsplatsen.

   git push
   

Steg 6: Skapa en pull-begäran

När du har pushat dina ändringar, gå tillbaka till https://github.com/microsoft/winget-pkgs och skapa en pull request för att sammanfoga din gren med huvudgrenen.

Inlämningsprocess

När du skapar en pull-begäran startar detta en automatiserad process som verifierar manifesten och verifierar din pull-begäran. Under den här processen kommer vi att köra tester mot installationsprogrammet och installerade binärfiler för att verifiera sändningen.

Vi lägger till etiketter i din pull-begäran så att du kan spåra dess förlopp. För ytterligare information om etiketter och processen, se avsnittet om etiketter för pull-begäranden nedan.

När du är klar granskas ditt bidrag manuellt av en moderator, och när det har godkänts läggs ditt program till i Windows Package Manager-katalogen.

Om det uppstår ett fel under processen kommer du att meddelas och våra etiketter och robot hjälper dig att åtgärda ditt bidrag. En lista över vanliga fel finns i avsnittet om valideringsprocessen nedan.

Valideringsprocessen

När du skapar en pull-begäran för att skicka ditt manifest till Windows Package Manager-lagringsplatsen, kommer det att starta en automatiseringsprocess som validerar manifestet och bearbetar pull-begäran. GitHub-etiketter används för att dela förlopp och gör att du kan kommunicera med oss.

Inlämningsförväntningar

Alla programöverföringar till Windows Package Manager-lagringsplatsen bör följa Windows Package Manager-lagringsprinciperna.

Förväntningar på inlämningar:

• Manifestet uppfyller schemakraven.
• Alla URL:er i manifestet leder till säkra webbplatser.
• Installationsprogrammet och programmet är virusfria. Paketet kan identifieras som skadlig kod av misstag. Om du tror att det är en falsk positiv identifiering kan du skicka installationsprogrammet till Microsoft Defender-teamet för analys.
• Programmet installeras och avinstalleras korrekt för både administratörer och icke-administratörer.
• Installationsprogrammet stöder icke-interaktiva lägen.
• Alla manifestposter är korrekta och vilseleder inte.
• Installationsprogrammet kommer direkt från utgivarens webbplats.

En fullständig lista över principerna finns i Windows Package Manager-principer.

Etiketter för pull-förfrågningar

Under valideringen används en serie etiketter för pull-begäranden för att kommunicera förloppet. Vissa etiketter uppmanar dig att vidta åtgärder, medan andra dirigeras till Windows Package Manager-teknikteamet.

Statusetiketter

I följande tabell beskrivs statusetiketter du kan stöta på.

Etikett	Detaljer
Azure-Pipeline-Godkänd	Manifestet har avslutat testpasset. Den väntar på godkännande. Om inga problem uppstår under testpasset godkänns det automatiskt. Om ett test misslyckas kan det flaggas för manuell granskning.
Blockeringsfråga	Den här etiketten anger att pull-begäran inte kan godkännas eftersom det finns ett blockeringsproblem. Du kan ofta se vad blockeringsproblemet är med hjälp av den inkluderade feletiketten.
Behöver uppmärksamhet	Den här etiketten anger att pull-begäran måste undersökas av Utvecklingsteamet för Windows Package Manager. Detta beror antingen på ett testfel som behöver granskas manuellt eller på en kommentar som lagts till i pull-begäran från communityn.
Behöver-författare-feedback	Anger att det uppstår ett fel med insändningen. Vi kommer att tilldela pull requesten tillbaka till dig. Om du inte åtgärdar problemet inom 10 dagar stänger roboten pull-begäran. Etiketter för behovsförfattare och feedback läggs vanligtvis till när det uppstod ett fel med pull-begäran som ska uppdateras, eller om personen som granskar pull-begäran har en fråga.
validering slutförd	Anger att testpasset har slutförts framgångsrikt och att pull-förfrågan kommer att slås samman.

Feletiketter

Följande tabell beskriver de feletiketter som du kan stöta på. Inte alla felfall kommer att tilldelas dig omedelbart. Vissa kan utlösa manuell validering.

Etikett	Detaljer
Binärvalideringsfel	Programmet som ingår i den här pull-begäran kunde inte klara installationsgenomsökningstestet . Det här testet är utformat för att säkerställa att programmet installeras i alla miljöer utan varningar. Mer information om det här felet finns i avsnittet Om binär valideringsfel nedan.
Felanalys-Timeout	Tidsgränsen för Binary-Validation-Test-testet har överskridits. Pull-begäran kommer att tilldelas en Windows Package Manager-tekniker för undersökning.
Error-Hash-Mismatch	Det gick inte att bearbeta det inskickade manifestet eftersom den InstallerSha256-hash som angavs för InstallerURL inte matchade. Uppdatera InstallerSha256 i pull-begäran och försök igen.
Fel-Installations-Tillgänglighet	Valideringstjänsten kunde inte ladda ned installationsprogrammet. Detta kan bero på att Azure IP-intervall blockeras eller att installations-URL:en är felaktig. Kontrollera att InstallerURL är korrekt och försök igen. Om du anser att det här har misslyckats av misstag, lägg till en kommentar så tilldelas pull requesten till en ingenjör för Windows Package Manager för att undersöka problemet.
Manifest-Installer-Validation-Error	Det finns antingen inkonsekvenser eller värden som inte finns i manifestet under utvärderingen av ett MSIX-paket.
Manifest-Path-Error	Manifestfilerna måste placeras i en specifik mappstruktur. Den här etiketten anger ett problem med sökvägen till din sändning. Mappstrukturen har till exempel inte det format som krävs. Uppdatera manifestet och sökvägen och skicka pull-begäran igen.
manifestverifieringsfel	Det skickade manifestet innehåller ett syntaxfel. Åtgärda syntaxproblemet med manifestet och skicka igen. Mer information om manifestformatet och schemat finns i krävt format.
PullRequest-Error	Pull-begäran är ogiltig eftersom inte alla filer som skickas finns under manifestmappen eller att det finns mer än ett paket eller en version i pull-begäran. Uppdatera pull-begäran för att åtgärda problemet och försök igen.
URL-valideringsfel	Valideringstestet för URL:er kunde inte hitta URL:en och svarade med en HTTP-felstatuskod (403 eller 404), eller så misslyckades URL-ryktestestet. Du kan identifiera vilken URL som är i fråga genom att titta på kontrollinformation för pull-begäran. Åtgärda det här problemet genom att uppdatera url:erna i fråga för att lösa statuskoden för HTTP-fel. Om problemet inte beror på en HTTP-felstatuskod kan du skicka URL:en för granskning för att undvika ryktesfelet.
Validering-Försvarare-Fel	Under dynamisk testning rapporterade Microsoft Defender ett problem. Om du vill återskapa det här problemet installerar du programmet och kör sedan en fullständig genomsökning av Microsoft Defender. Om du kan återskapa problemet kan du åtgärda binärfilen eller skicka den för analys för falsk positiv hjälp. Om du inte kan återskapa problemet lägger du till en kommentar för att få Windows Package Manager-tekniker att undersöka.
Valideringsdomän	Testet har fastställt domänen om InstallerURL inte matchar den förväntade domänen. Windows Package Manager-principerna kräver att InstallerUrl kommer direkt från ISV:s versionsplats. Om du tror att det här är en falsk identifiering lägger du till en kommentar i pull-begäran för att få Windows Package Manager-teknikerna att undersöka saken.
Valideringsfel	Verifieringen av Windows Package Manager misslyckades under manuellt godkännande. Titta på den tillhörande kommentaren för nästa steg.
Validering-Körbar-Fel	Under installationstestningen kunde testet inte hitta det primära programmet. Kontrollera att programmet installeras korrekt på alla plattformar. Om programmet inte installerar ett program, men ändå ska ingå i lagringsplatsen, lägger du till en kommentar i pull-begäran för att få Windows Package Manager-tekniker att undersöka saken.
validerings-hash-verifiering-misslyckades	Under installationstestningen kan programmet inte installeras eftersom InstallerSha256 inte längre matchar InstallerURL-hashen . Detta kan inträffa om programmet ligger bakom en fåfäng URL och installationsprogrammet uppdaterades utan att uppdatera InstallerSha256-. Åtgärda problemet genom att uppdatera InstallerSha256 som är associerad med InstallerURL och skicka på nytt.
Verifierings-HTTP-fel	Url:en som används för installationsprogrammet använder inte HTTPS-protokollet. Uppdatera InstallerURL för att använda HTTPS och skicka pull-begäran igen.
validation-Indirect-URL	URL:en kommer inte direkt från ISV-servern. Testningen har fastställt att en omdirigering har använts. Detta är inte tillåtet eftersom Windows Package Manager-principerna kräver att InstallerUrl kommer direkt från ISV:s versionsplats. Ta bort omdirigeringen och skicka igen.
Valideringsinstallationsfel	Under manuell validering av det här paketet uppstod ett allmänt fel. Titta på den tillhörande kommentaren för nästa steg.
Validering-Sammanslagnings-konflikt	Det gick inte att verifiera det här paketet på grund av en sammanslagningskonflikt. Åtgärda sammanslagningskonflikten och skicka pull-begäran igen.
Validering-MSIX-Beroende	MSIX-paketet har ett beroende av paket som inte kunde lösas. Uppdatera paketet så att det innehåller de komponenter som saknas eller lägg till beroendet i manifestfilen och skicka pull-begäran igen.
Validering-ej godkänd URL-	Testet har fastställt domänen om InstallerURL inte matchar den förväntade domänen. Windows Package Manager-principerna kräver att InstallerUrl kommer direkt från ISV:s versionsplats.
validering-utan tillsyn-misslyckades	Under installationen gick testet utom tid. Detta beror troligen på att programmet inte installeras i bakgrunden. Det kan också bero på att något annat fel påträffas och att testet stoppas. Kontrollera att du kan installera manifestet utan användarindata. Om du behöver hjälp lägger du till en kommentar i pull-begäran så undersöker Windows Package Manager-teknikerna.
Validering-Avinstallation-Fel	Under avinstallationstestningen rensade programmet inte helt efter avinstallationen. Mer information finns i den tillhörande kommentaren.
Validation-VCRuntime-Dependency	Paketet har ett beroende av C++-körtid som inte kunde lösas. Uppdatera paketet så att det innehåller de komponenter som saknas eller lägg till beroendet i manifestfilen och skicka pull-begäran igen.

Innehållsprincipetiketter

I följande tabell visas innehållsprincipetiketter. Om en av dessa etiketter läggs till utlöste något i manifestmetadata ytterligare manuell innehållsgranskning för att säkerställa att metadata följer Windows Package Manager-principerna.

Etikett	Detaljer
Policytest-2.1	Se allmänna innehållskraven.
Policy-test-2.2	Se innehåll inklusive namn, logotyper, original och tredje partsinnehåll
Principtest-2.3	Se Risk för skada.
Policytest-2.4	Se förtal, ärekränkande, smädande och hotande.
Principtest-2.5	Se stötande innehåll.
Principtest-2.6	Se alkohol, tobak, vapen och droger.
Policytest-2.7	Se vuxeninnehåll.
Principtest-2.8	Se olaglig aktivitet.
Principtest-2.9	Se Oanständig och olämplig innehåll.
Policytest-2.10	Se Specifika krav för land/region.
Policytest-2.11	Se Åldersklassificeringar.
Principtest-2.12	Se Användargenererat innehåll.

Interna etiketter

I följande tabell visas interna feletiketter. När interna fel påträffas tilldelas din pull-begäran till ingenjörerna hos Windows Package Manager för att undersöka felen.

Etikett	Detaljer
intern feldomän	Ett fel uppstod under domänverifieringen av URL:en.
Internt-Fel-Dynamisk-Skanning	Ett fel uppstod under valideringen av de installerade binärfilerna.
Intern-fel-nyckelord-policy	Ett fel uppstod under valideringen av manifestet.
Internt felmanifest	Ett fel uppstod under valideringen av manifestet.
Internt-Fel-IngaArkitekturer	Ett fel uppstod eftersom testet inte kunde fastställa programmets arkitektur.
Internt fel - Inga stödda arkitekturer	Ett fel uppstod eftersom den aktuella arkitekturen inte stöds.
Internal-Error-PR-	Ett fel uppstod under bearbetningen av pull-begäran.
Internal-Error-Static-Scan	Ett fel uppstod vid statisk analys av installationsprogrammet.
intern-fel-URL	Ett fel uppstod under ryktesverifieringen av installationsprogrammet.
internt fel	Ett allmänt fel eller ett okänt fel påträffades under testpasset.

Ett binärt valideringsfel

Om valideringen av pull-begäran misslyckas med att installera genomsökningstestet och får en etikett för binär valideringsfel innebär det att programmet inte kunde installeras i alla miljöer.

Genomsökningstest för installationsprogram

För att ge en utmärkt användarupplevelse för programinstallation måste Windows Package Manager se till att alla program installeras på datorer utan fel, oavsett miljö. Ett viktigt test är att se till att alla program installeras utan varningar på olika populära antiviruskonfigurationer. Windows tillhandahåller det inbyggda Microsoft Defender-antivirusprogrammet, men många företagskunder och användare använder andra antivirusprogram.

Varje överföring till Windows Package Manager-lagringsplatsen körs via flera antivirusprogram. Alla dessa program har olika algoritmer för virusidentifiering för att identifiera potentiellt oönskade program (PUA) och skadlig kod.

Åtgärda binära valideringsfel

Om ett program misslyckas med valideringen försöker Microsoft först verifiera med antivirusleverantören om den flaggade programvaran är en falsk positiv identifiering. I många fall, efter meddelande och validering, uppdaterar antivirusleverantören sin algoritm och programmet skickas.

I vissa fall kan antivirusleverantören inte avgöra om den identifierade kodavvikelsen är ett falskt positiv. I det här fallet kan programmet inte läggas till i Windows Package Manager-lagringsplatsen. Pull-begäran avvisas med etiketten för binärt valideringsfel .

Om du får en etikett för binärvalideringsfel i pull-begäran uppdaterar du programvaran för att ta bort koden som identifierats som PUA.

Ibland visas äkta verktyg som används för felsökning och lågnivåaktiviteter som PUA till antivirusprogram. Detta beror på att den nödvändiga felsökningskoden har en liknande signatur som oönskad programvara. Även om den här kodningspraxis är legitim kan Windows Package Manager-lagringsplatsen tyvärr inte tillåta dessa program.

Felsökning av insändning

Om din Windows Package Manager-överföring misslyckas kan du använda etiketterna som beskrivs ovan för att undersöka orsaken till felet.

Utför följande steg för att undersöka fel med pull-begäranden:

1. Ett pull-begärandefel visas längst ned på webbsidan med strängen Vissa kontroller lyckades inte. Välj länken Information bredvid en misslyckad validering för att gå till sidan Azure Pipelines.

   

2. På sidan Azure Pipelines väljer du länken 0 fel / 0 varningar.

   

3. På nästa sida väljer du det misslyckade jobbet.

   

4. På nästa sida visas utdata för det misslyckade jobbet. Utdata bör hjälpa dig att identifiera den ändring du behöver göra för att åtgärda manifestet.

   I följande exempel inträffade felet under installationsverifieringsaktiviteten .