Paketera din Windows-app som signed MSIX.

Nej, och skillnaden spelar roll. Capture-first-paketering finns för applikationer vars installationsprogram är borta, så att den körande applikationen blir sanningskällan. Den här rutten förutsätter motsatsen: ni har en fungerande build-mapp och vill få den paketerad, signerad och validerad som ett pipelinesteg. Båda delar samma signerings-, validerings- och Intune-leveransväg på slutet, vilket är varför miljöer med både inköpt och egenbyggd programvara kan använda en rutt för båda.

Lägg forge_msix på agentens PATH, peka på din publicerade buildmapp, kör forge_msix prepare för att skapa ett manifest från den byggda körbara filen och sedan forge_msix create med signering från certifikatlagret via thumbprint. Gatea releasen med forge_msix validate och generera vid behov en app installer-feed för sideload-uppdateringar. Samma växlar som ett befintligt makeappx-skript redan använder fortsätter att fungera.

Ja. forge_msix är en CLI för obemannade agenter. Kör den från Azure DevOps, GitHub Actions, GitLab CI, Jenkins eller valfri skriptad Windows-buildagent. Paketering, signering och validering blir steg i samma releasedefinition som dina övriga artefakter.

Inte för de makeappx-kompatibla kommandona. Att paketera, packa upp, bunta, avbunta, validera och indexera resurser är licensfritt, så forge_msix fungerar som en äkta direkt ersättare för makeappx.exe utan att något behöver köpas. De värdeskapande flödena, alltså att skapa från ett manifest, signera, testa, bedöma, hantera certifikat och utvecklarregistreringskommandona, kräver en aktiv EtherApps Forge-licens.

Nej. CLI:t anropar Windows paketerings-API direkt, och den motorn är en operativsystemkomponent i stället för ett SDK-beroende, så paket får samma schemakontroll, block map och struktur som makeappx producerar. Agenten behöver Windows 10 version 1709 eller senare, eller Windows 11, på x64. Driftsättningen är en mapp du kopierar och lägger i PATH, utan installationsprogram.

Signera från ett certifikatlager via tumavtryck eller subjekt i stället för från en PFX på disk, så att inget lösenord skrivs in i en byggdefinition. Lägg till en RFC 3161-tidsstämpelserver så att signaturer förblir giltiga efter att certifikatet gått ut. Sätt utgivaren i ert manifest exakt lika med certifikatets subjekt och låt utgivarläget vara strikt, så att en avvikelse stoppar bygget i stället för att tyst ändra den identitet era kunder redan installerat.

Kör valideringskommandot med JSON-utdata och förgrena på exitkoden. Det skiljer ett analyserat men ogiltigt paket från ett driftfel, vilket är skillnaden mellan ett trasigt paket och en trasig agent. Håll de flaggor som låter ett bygge passera validerings- eller semantikfel utanför release-pipelines; de är diagnosverktyg för att ta reda på varför ett paket inte byggs, inte inställningar att lämna påslagna.

Ja. Applikationer skrivna före MSIX förutsätter ofta beteenden containern inte tillåter, som att skriva bredvid sin egen körbara fil eller förvänta sig en fast installationssökväg. Forge lägger upp Package Support Framework så att de fallen rättas med fil- och registeromdirigering och korrigering av arbetskatalogen, utan ändring i er källkod. För egen programvara vill ni kanske hellre rätta beteendet vid källan, men ramverket gör att en release inte blockeras under tiden.

Generera ett app installer-manifest från det signerade paketet; det härleder identiteten från paketet självt och hanterar bundles. Publicera paketet och det manifestet på en HTTPS-plats, så kan installerade kopior uppdatera sig själva därifrån. Det ger sidoladdande och företagskunder en uppdateringsväg utan butikspublicering eller manuell ominstallation.

Ja. Ett paket kan extraheras till en arbetskatalog, redigeras kirurgiskt, valideras och paketeras om: manifestvärden, capabilities, payload-filer och paketets virtuella register går alla att ändra, och varje manifeständring valideras innan den skrivs, så en felformad ändring avvisas i stället för att sparas. Ompaketering ändrar innehållshashen, så paketet måste signeras igen efteråt.

Signeringscertifikatet finns inte i den betrodda lagringsplats enheten faktiskt kontrollerar. Importera det till Trusted People-lagringen på den lokala datorn, inte till den aktuella användarens lagring och inte till Trusted Root: exportera signerarens certifikat och importera det sedan med administratörsrättigheter under Cert:\LocalMachine\TrustedPeople, eller använd "Installera certifikat" och välj Lokal dator i stället för Aktuell användare. Importera aldrig ett självsignerat utvecklingscertifikat till Trusted Root Certification Authorities; den lagringsplatsen är avsedd för CA-rotcertifikat, och att lägga till ett obetrott certifikat där försvagar hela enhetens förtroendemodell, inte bara förtroendet för ett paket.

MSIX Packaging Tool är Microsofts GUI-first-väg, byggd för en person som klickar sig igenom en guide på en maskin. En CI-pipeline behöver motsatsen: inget gränssnitt att klicka i, en stabil avslutningskod att förgrena på, och flaggor som förblir identiska på varje byggagent. forge_msix är CLI-first av precis den anledningen, så att paketering blir ett skriptat pipeline-steg i stället för ett manuellt steg någon måste komma ihåg att köra före varje release.