Dela via

Windows App Certification Kit-tester

  • Artikel

Windows App Certification Kit innehåller ett antal tester som hjälper dig att se till att din app är redo att publiceras i Microsoft Store. Testerna visas nedan med deras kriterier, information och föreslagna åtgärder vid fel.

Distributions- och starttester

Övervakar appen under certifieringstestningen för att registrera när den kraschar eller låser sig.

Bakgrund

Appar som slutar svara eller kraschar kan orsaka att användaren förlorar data och har en dålig upplevelse.

Vi förväntar oss att appar fungerar fullt ut utan att windows-kompatibilitetslägen, AppHelp-meddelanden eller kompatibilitetskorrigeringar används.

Appar får inte visa DLL:er som ska läsas in i registernyckeln HKEY-LOCAL-MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit-DLLs.

Testinformation

Vi testar appens motståndskraft och stabilitet under certifieringstestningen.

Windows App Certification Kit anropar IApplicationActivationManager::ActivateApplication för att starta appar. För ActivateApplication för att starta en app måste UAC (User Account Control) aktiveras och skärmupplösningen måste vara minst 1 024 x 768 eller 768 x 1024. Om något av villkoren inte uppfylls misslyckas appen med det här testet.

Korrigerande åtgärder

Kontrollera att UAC är aktiverat på testdatorn.

Kontrollera att du kör testet på en dator med tillräckligt stor skärm.

Om din app inte startar och testplattformen uppfyller kraven för ActivateApplicationkan du felsöka problemet genom att granska aktiveringshändelseloggen. Så här hittar du dessa poster i händelseloggen:

  1. Öppna eventvwr.exe och gå till mappen Application and Services Log\Microsoft\Windows\Immersive-Shell.
  2. Filtrera vyn för att visa händelse-ID: 5900-6000.
  3. Granska loggposterna för information som kan förklara varför appen inte startades.

Felsöka filen med problemet, identifiera och åtgärda problemet. Återskapa och testa appen igen. Du kan också kontrollera om en dumpfil genererades i loggmappen för Windows App Certification Kit som kan användas för att felsöka din app.

Lanseringstest för plattformsversion

Kontrollerar att Windows-appen kan köras på en framtida version av operativsystemet. Det här testet har tidigare endast tillämpats på arbetsflödet för skrivbordsappen, men det är nu aktiverat för arbetsflödena Store och Universal Windows Platform (UWP).

Bakgrund

Versionsinformationen för operativsystemet har begränsad användning för Microsoft Store. Detta har ofta använts felaktigt av appar för att kontrollera os-versionen så att appen kan ge användarna funktioner som är specifika för en os-version.

Testinformation

Windows App Certification Kit använder HighVersionLie för att identifiera hur appen kontrollerar operativsystemets version. Om appen kraschar misslyckas det här testet.

Korrigeringsåtgärder

Appar bör använda hjälpfunktioner för versions-API för att kontrollera detta. Mer information finns i operativsystemversion.

Validering av hanteraren för annullering av bakgrundsaktiviteter

Detta verifierar att appen har en avbokningshanterare för deklarerade bakgrundsaktiviteter. Det måste finnas en dedikerad funktion som anropas när aktiviteten avbryts. Det här testet tillämpas endast för distribuerade appar.

Bakgrund

Store-appar kan registrera en process som körs i bakgrunden. En e-postapp kan till exempel pinga en server då och då. Men om operativsystemet behöver dessa resurser avbryts bakgrundsaktiviteten och appar bör hantera den här annulleringen på ett korrekt sätt. Appar som inte har en avbokningshanterare kan krascha eller inte stängas när användaren försöker stänga appen.

Testinformation

Appen startas, pausas och appens icke-bakgrundsdel avslutas. Sedan avbryts bakgrundsuppgifterna som är associerade med den här appen. Appens tillstånd kontrolleras, och om appen fortfarande körs kommer testet att misslyckas.

Korrigeringsåtgärder

Lägg till hanteraren för annullering i din app. För mer information, se Stöd din app med bakgrundsuppgifter.

Antal appar

Detta verifierar att ett apppaket (.msix, .appx eller apppaket) innehåller ett program. Detta ändrades i testkitet till ett fristående test.

Bakgrund

Det här testet implementerades enligt Store-principen.

Testinformation

För Windows Phone 8.1-appar verifierar testet det totala antalet .appx paket i paketet är < 512, det finns bara ett huvudpaket i paketet och att arkitekturen för huvudpaketet i paketet är markerad som Arm eller neutral.

För Windows 10-appar verifierar testet att revisionsnumret i versionen av paketet är inställt på 0.

Korrigeringsåtgärder

Se till att apppaketet och samlingen uppfyller ovanstående krav i Testinformation.

Efterlevnadstest av appmanifestet

Testa innehållet i appmanifestet för att se till att innehållet är korrekt.

Bakgrund

Appar måste ha ett korrekt formaterat appmanifest.

Testinformation

Undersöker appmanifestet för att kontrollera att innehållet är korrekt enligt beskrivningen i App-paketkrav.

  • Filnamnstillägg och protokoll

    Din app kan deklarera filnamnstilläggen som den vill associera med. En app kan deklarera ett stort antal filnamnstillägg på ett felaktigt sätt, varav de flesta kanske inte ens används, vilket resulterar i en felaktig användarupplevelse. Det här testet lägger till en kontroll för att begränsa antalet filnamnstillägg som en app kan associera med.

  • Ramverk Beroende Regel

    Det här testet tillämpar kravet på att appar ska ha lämpliga beroenden på UWP. Om det finns ett olämpligt beroende misslyckas det här testet.

    Om det finns ett matchningsfel mellan operativsystemversionen som appen gäller för och de ramverksberoenden som görs misslyckas testet. Testet skulle också misslyckas om appen refererar till några förhandsversioner av ramverksdllarna.

  • IPC-verifiering (Inter-Process Communication)

    Det här testet tillämpar kravet på att UWP-appar inte kommunicerar utanför appcontainern till Skrivbordskomponenter. Kommunikation mellan processer är endast avsedd för sido-laddade appar. Appar som anger ActivatableClassAttribute med namnet "DesktopApplicationPath" misslyckas med det här testet.

Korrigeringsåtgärder

Granska appens manifest mot de krav som beskrivs i App-paketkrav.

Test av Windows-säkerhetsfunktioner

Bakgrund

Om du ändrar standardsäkerhetsskyddet för Windows kan kunderna utsättas för ökad risk.

Testinformation

Testar appens säkerhet genom att köra BinScope Binary Analyzer.

BinScope Binary Analyzer-testerna undersöker appens binära filer för att söka efter kodnings- och byggmetoder som gör appen mindre sårbar för angrepp eller för att användas som attackvektor.

BinScope Binary Analyzer-testerna söker efter korrekt användning av följande säkerhetsrelaterade funktioner.

  • BinScope Binary Analyzer-tester
  • Privat kodsignering

BinScope Binary Analyzer-tester

BinScope Binary Analyzer tester undersöker appens binära filer för att söka efter kodnings- och byggmetoder som gör appen mindre sårbar för angrepp eller för att användas som attackvektor.

BinScope Binary Analyzer-testerna söker efter korrekt användning av dessa säkerhetsrelaterade funktioner:

AllowPartiallyTrustedCallersAttribute

felmeddelande för Windows App Certification Kit: APTCACheck-testet misslyckades

Attributet AllowPartiallyTrustedCallersAttribute (APTCA) ger åtkomst till fullständigt betrodd kod från delvis betrodd kod i signerade sammansättningar. När du använder APTCA-attributet för en sammansättning kan delvis betrodda anropare komma åt sammansättningen under hela sammansättningen, vilket kan äventyra säkerheten.

Vad du ska göra om din app misslyckas med det här testet

Använd inte APTCA-attributet för starka namngivna sammansättningar om inte projektet kräver det och riskerna är väl förstådda. I de fall där det krävs kontrollerar du att alla API:er skyddas med lämpliga krav på kodåtkomstsäkerhet. APTCA har ingen effekt när sammansättningen är en del av en UWP-app (Universal Windows Platform).

Kommentarer

Det här testet utförs endast på hanterad kod (C#, .NET osv.).

/SafeSEH Undantagshanteringsskydd

felmeddelande för Windows App Certification Kit: SafeSEHCheck-testet misslyckades

En undantagshanterare körs när appen stöter på ett exceptionellt villkor, till exempel ett divide-by-zero-fel. Eftersom adressen till undantagshanteraren lagras i stacken när en funktion anropas kan den vara sårbar för en buffertöverflödesanfallare om någon skadlig programvara skulle skriva över stacken.

Vad du ska göra om din app misslyckas med det här testet

Aktivera alternativet /SAFESEH i kommandot linker när du skapar din app. Det här alternativet är aktiverat som standard i Versionskonfigurationerna för Visual Studio. Kontrollera att det här alternativet är aktiverat i bygginstruktionerna för alla körbara moduler i din app.

Anmärkningar

Testet utförs inte på 64-bitars binärfiler eller binärfiler för Arm-kretsuppsättningar eftersom de inte lagrar undantagshanteraradresser i stacken.

Datakörningsskydd

felmeddelande för Windows App Certification Kit: NXCheck-testet misslyckades

Det här testet verifierar att en app inte kör kod som lagras i ett datasegment.

Vad du ska göra om din app misslyckas med det här testet

Aktivera alternativet /NXCOMPAT i kommandot linker när du skapar din app. Det här alternativet är aktiverat som standard i länkversioner som stöder datakörningsskydd (DEP).

kommentarer

Vi rekommenderar att du testar dina appar på en DEP-kompatibel processor och åtgärdar eventuella fel som du hittar som resultat av DEP.

Adressutrymmeslayout slumpmässigt

felmeddelande för Windows App Certification Kit: DBCheck-testet misslyckades

ASLR (Address Space Layout Randomization) läser in körbara bilder till oförutsägbara platser i minnet, vilket gör det svårare för skadlig programvara som förväntar sig att ett program ska läsas in på en viss virtuell adress för att fungera förutsägbart. Din app och alla komponenter som appen använder måste ha stöd för ASLR.

Vad du ska göra om din app misslyckas med det här testet

Aktivera alternativet /DYNAMICBASE i länkkommandot när du skapar din app. Kontrollera att alla moduler som appen använder också använder det här länkalternativet.

kommentarer

Normalt påverkar ASLR inte prestanda. Men i vissa scenarier finns det en liten prestandaförbättring på 32-bitarssystem. Det är möjligt att prestanda kan försämras i ett mycket överbelastat system som har många bilder inlästa på många olika minnesplatser.

Det här testet utförs endast på appar som skrivits på ohanterade språk, till exempel med C eller C++.

Läsa/Skriva Delat PE-avsnitt

felmeddelande för Windows App Certification Kit: SharedSectionsCheck Test misslyckades.

Binära filer med skrivbara avsnitt som är markerade som delade är ett säkerhetshot. Skapa inte appar med delade skrivbara avsnitt om det inte behövs. Använd CreateFileMapping eller MapViewOfFile för att skapa ett korrekt skyddat delat minnesobjekt.

Vad du ska göra om din app misslyckas med det här testet

Ta bort delade avsnitt från appen och skapa delade minnesobjekt genom att anropa CreateFileMapping eller MapViewOfFile med rätt säkerhetsattribut och sedan återskapa din app.

kommentarer

Det här testet utförs endast på appar som skrivits på ohanterade språk, till exempel med C eller C++.

AppContainerCheck

felmeddelande för Windows App Certification Kit: AppContainerCheck-testet misslyckades.

AppContainerCheck verifierar att appcontainerbiten i rubriken för det portabla körbara (PE)-filen för en körbar binär fil är inställd. Appar måste ha appcontainer bit inställd för alla .exe-filer och alla ohanterade DLL:er för att kunna köras korrekt.

Vad du ska göra om din app misslyckas med det här testet

Om en intern körbar fil misslyckas med testet kontrollerar du att du använde den senaste kompilatorn och länkaren för att skapa filen och att du använder flaggan /appcontainer på länkaren.

Om en hanterad körbar fil inte klarar testet, ser du till att du använde den senaste versionen av kompilatorn och länkaren, till exempel Microsoft Visual Studio, för att skapa UWP-appen.

Kommentarer

Det här testet utförs på alla .exe filer och på ohanterade DLL:er.

ExecutableImportsCheck

felmeddelande för Windows App Certification Kit: ExecutableImportsCheck-testet misslyckades.

En bärbar exekverbar avbildning (PE) misslyckas med det här testet om dess importtabell har placerats i ett exekverbart kodavsnitt. Detta kan inträffa om du har aktiverat .rdata-sammanslagning för PE-avbildningen genom att ange flaggan /merge för Visual C++-länkaren som /merge:.rdata=.text.

Vad du ska göra om din app misslyckas med det här testet

Sammanfoga inte importtabellen till ett körbart kodavsnitt. Kontrollera att flaggan /merge för Visual C++-länkaren inte är inställd på att sammanfoga avsnittet ".rdata" i ett kodavsnitt.

Anmärkningar

Det här testet utförs på all binär kod utom rent hanterade sammansättningar.

WXCheck

felmeddelande för Windows App Certification Kit: WXCheck-test misslyckades.

Kontrollen hjälper till att säkerställa att en binär fil inte har några sidor som är mappade som skrivbara och körbara. Detta kan inträffa om binärfilen har ett skrivbart och körbart avsnitt eller om binärfilens SectionAlignment- är mindre än PAGE-SIZE-.

Vad du ska göra om din app misslyckas med det här testet

Kontrollera att binärfilen inte har ett skrivbart eller körbart avsnitt och att binärfilens SectionAlignment- värde är minst lika med dess PAGE-SIZE.

kommentarer

Det här testet utförs på alla .exe filer och på interna, ohanterade DLL:er.

En körbar fil kan ha ett skrivbart och körbart avsnitt om det har skapats med Redigera och Fortsätt aktiverat (/ZI). Om du inaktiverar Redigera och Fortsätt visas inte det ogiltiga avsnittet.

PAGE-SIZE är standard SectionAlignment för exekverbara filer.

Privat kodsignering

Testar om det finns binärfiler för privat kodsignering i apppaketet.

Bakgrund

Privata kodsigneringsfiler bör hållas privata eftersom de kan användas för skadliga ändamål i händelse av att de komprometteras.

Testinformation

Tester för filer i apppaketet som har ett tillägg av .pfx eller.snk som skulle indikera att privata signeringsnycklar inkluderades.

Korrigerande åtgärder

Ta bort alla privata kodsigneringsnycklar (till exempel .pfx- och .snk-filer) från paketet.

API-test som stöds

Testa appen för användning av icke-kompatibla API:er.

Bakgrund

Appar måste använda API:erna för UWP-appar (Windows Runtime eller Win32-API:er som stöds) för att certifieras för Microsoft Store. Det här testet identifierar även situationer där en hanterad binär fil är beroende av en funktion utanför den godkända profilen.

Testinformation

  • Verifierar att varje binärfil i apppaketet inte har något beroende av ett Win32-API som inte stöds för UWP-apputveckling genom att kontrollera importadresstabellen för binärfilen.
  • Verifierar att varje hanterad binärfil i apppaketet inte har något beroende av en funktion utanför den godkända profilen.

Korrigerande åtgärder

Kontrollera att appen kompilerades som en versionsversion och inte som en felsökningsversion.

Obs Felsökningsversionen av en app misslyckas även om appen endast använder API:er för UWP-appar.

Granska felmeddelandena för att identifiera det API som appen använder som inte är ett API för UWP-appar.

Observera C++-appar som är inbyggda i en felsökningskonfiguration misslyckas det här testet även om konfigurationen endast använder API:er från Windows SDK för UWP-appar. Mer information finns i Alternativ till Windows-API:er i UWP-appar.

Prestandatestning

Appen måste svara snabbt på användarinteraktion och systemkommandon för att kunna presentera en snabb och smidig användarupplevelse.

Egenskaperna hos den dator där testet utförs kan påverka testresultaten. Tröskelvärdena för prestandatest för appcertifiering anges så att lågeffektdatorer uppfyller kundens förväntningar på en snabb och smidig upplevelse. För att fastställa appens prestanda rekommenderar vi att du testar på en dator med låg effekt, till exempel en Intel Atom-processorbaserad dator med en skärmupplösning på 1366x768 (eller högre) och en rotationshårddisk (i motsats till en solid state-hårddisk).

Bytecode-generering

Som en prestandaoptimering för att påskynda JavaScript-körningstiden genererar JavaScript-filer som slutar med .js-tillägget bytekod när appen distribueras. Detta förbättrar start- och exekveringstider avsevärt för JavaScript-operationer.

Testinformation

Kontrollerar appdistributionen för att kontrollera att alla .js filer har konverterats till bytekod.

Korrigeringsåtgärder

Om det här testet misslyckas bör du tänka på följande när du åtgärdar problemet:

  • Kontrollera att händelseloggning är aktiverat.
  • Kontrollera att alla JavaScript-filer är syntaktiskt giltiga.
  • Bekräfta att alla tidigare versioner av appen har avinstallerats.
  • Undanta identifierade filer från apppaketet.

Optimerade bindningsreferenser

När du använder bindningar bör WinJS.Binding.optimizeBindingReferences anges till true för att optimera minnesanvändningen.

Testinformation

Kontrollera värdet för WinJS.Binding.optimizeBindingReferences.

Korrigeringsåtgärder

Ange WinJS.Binding.optimizeBindingReferences till true i appens JavaScript-kod.

Test av appmanifestresurser

Validering av appresurser

Appen kanske inte installeras om strängarna eller avbildningarna som deklareras i appens manifest är felaktiga. Om appen installeras med dessa fel kanske appens logotyp eller andra bilder som används av appen inte visas korrekt.

Testinformation

Inspekterar de resurser som definierats i appmanifestet för att se till att de finns och är giltiga.

Korrigeringsåtgärder

Använd följande tabell som vägledning.

FelmeddelandeKommentarer

Bilden {image name} definierar både Skalnings- och TargetSize-kvalificerare. du kan bara definiera en kvalificerare i taget.

Du kan anpassa bilder för olika upplösningar.

I det faktiska meddelandet innehåller {image name} namnet på avbildningen med felet .

Kontrollera att varje bild definierar antingen skala eller målstorlek som kvalificerare.

Bilden {image name} misslyckades med storleksbegränsningarna.

Se till att alla appbilder följer rätt storleksbegränsningar.

I det faktiska meddelandet innehåller {image name} namnet på avbildningen med felet .

Avbildningen {image name} saknas i paketet.

En obligatorisk avbildning saknas.

I det faktiska meddelandet innehåller {image name} namnet på den bild som saknas.

Avbildningen {image name} är inte en giltig bildfil.

Se till att alla appbilder följer rätt filformatstypbegränsningar.

I det faktiska meddelandet innehåller {image name} namnet på den bild som inte är giltig.

Bilden "BadgeLogo" har ett ABGR-värde {value} vid position (x, y) som inte är giltig. Pixeln måste vara vit (##FFFFFF) eller transparent (00######)

Märkeslogotypen är en bild som visas bredvid märkesmeddelandet för att identifiera appen på låsskärmen. Den här bilden måste vara monokromatisk (den får endast innehålla vita och transparenta bildpunkter).

I det faktiska meddelandet innehåller {value} färgvärdet i bilden som inte är giltig.

Bilden "BadgeLogo" har ett ABGR-värde {value} vid position (x, y) som inte är giltigt för en vit bild med hög kontrast. Pixeln måste vara (##2A2A2A) eller mörkare eller transparent (00######).

Märkeslogotypen är en bild som visas bredvid märkesmeddelandet för att identifiera appen på låsskärmen. Eftersom märkeslogotypen visas i en vit bakgrund när den är vit med högkontrast måste den vara en mörk version av den normala märkeslogotypen. I högkontrast vitt kan märkeslogotypen bara innehålla bildpunkter som är mörkare än (##2A2A2A) eller transparenta.

I det faktiska meddelandet innehåller {value} färgvärdet i bilden som inte är giltig.

Bilden måste definiera minst en variant utan en TargetSize-kvalificerare. Det måste definiera en skalningskvalificerare eller lämna Skala och TargetSize ospecificerade, vilket standardmässigt blir Skala-100.

Mer information finns i Dynamisk design 101 för UWP-appar och Riktlinjer för appresurser.

Paketet saknar en "resources.pri"-fil.

Om du har lokalt innehåll i appmanifestet kontrollerar du att appens paket innehåller en giltig resources.pri-fil.

Filen "resources.pri" måste innehålla en resurskarta med ett namn som matchar paketnamnet {paketets fullständiga namn}

Du kan få det här felet om manifestet har ändrats och namnet på resurskartan i resources.pri inte längre matchar paketnamnet i manifestet.

I det faktiska meddelandet innehåller {paketets fullständiga namn} det paketnamn som resources.pri måste innehålla.

För att åtgärda detta måste du återskapa resources.pri och det enklaste sättet att göra det är genom att återskapa appens paket.

Filen "resources.pri" får inte ha AutoMerge aktiverat.

MakePRI.exe stöder ett alternativ som heter AutoMerge. Standardvärdet för AutoMerge är av. När det här är aktiverat sammanfogar AutoMerge en apps språkpaketresurser till en enda resources.pri vid körning. Vi rekommenderar inte detta för appar som du tänker distribuera via Microsoft Store. Resources.pri för en app som distribueras via Microsoft Store måste finnas i roten för appens paket och innehålla alla språkreferenser som appen stöder.

Strängen {string} misslyckades med maxlängdsbegränsningen för {number}-tecken.

Se kraven för apppaket.

I det faktiska meddelandet ersätts {string} av strängen med felet och {number} innehåller den maximala längden.

Strängen {string} får inte ha inledande/avslutande blanksteg.

Schemat för elementen i appmanifestet tillåter inte inledande eller avslutande blankstegstecken.

I det faktiska meddelandet ersätts {string} av strängen med felet .

Kontrollera att inget av de lokaliserade värdena för manifestfälten i resources.pri har inledande eller avslutande blankstegstecken.

Strängen måste vara icke-tom (större än noll i längd)

Mer information finns i apppaketkrav.

Det finns ingen standardresurs som anges i filen "resources.pri".

Mer information finns i Riktlinjer för appresurser.

I standardkonfigurationen innehåller Visual Studio endast avbildningsresurser med skala 200 i apppaketet vid generering av paket, och placerar andra resurser i resurspaketet. Se till att du antingen inkluderar avbildningsresurserna scale-200 eller konfigurerar projektet så att det inkluderar de resurser du har.

Inget resursvärde har angetts i filen "resources.pri".

Kontrollera att appmanifestet har giltiga resurser som definierats i resources.pri.

Bildfilen {filename} måste vara mindre än 204800 byte.\*\*

Minska storleken på de angivna bilderna.

Filen {filename} får inte innehålla ett avsnitt med omvänd mappning.\*\*

Även om den omvända kartan genereras under Visual Studio F5-felsökning när du anropar till makepri.exekan den tas bort genom att köra makepri.exe utan parametern /m när du genererar en pri-fil.

\*\* Anger att ett test har lagts till i Windows App Certification Kit 3.3 för Windows 8.1 och endast gäller när du använder den versionen av paketet eller senare.

 

Varumärkesverifiering

UWP-appar förväntas vara fullständiga och fullt funktionella. Appar som använder standardbilderna (från mallar eller SDK-exempel) har en dålig användarupplevelse och kan inte enkelt identifieras i butikskatalogen.

Testinformation

Testet kontrollerar om de bilder som används av appen inte är standardbilder från SDK-exempel eller från Visual Studio.

Korrigerande åtgärder

Ersätt standardbilder med något mer distinkt och representativt för din app.

Test av felsökningskonfiguration

Testa appen för att se till att den inte är en felsökningsversion.

Bakgrund

För att certifieras för Microsoft Store får appar inte kompileras för felsökning och de får inte referera till felsökningsversioner av en körbar fil. Dessutom måste du skapa koden som optimerad för att appen ska klara det här testet.

Testinformation

Testa appen för att se till att den inte är en felsökningsversion och inte är länkad till några felsökningsramverk.

Korrigerande åtgärder

  • Bygg appen som en releaseversion innan du skickar den till Microsoft Store.
  • Kontrollera att du har rätt version av .NET Framework installerad.
  • Kontrollera att appen inte länkar till felsökningsversioner av ramverket och att den byggs med en produktionsversion. Om den här appen innehåller .NET-komponenter kontrollerar du att du har installerat rätt version av .NET-ramverket.

Filkodningstest

UTF-8-filkodning

Bakgrund

HTML-, CSS- och JavaScript-filer måste kodas i UTF-8-formulär med motsvarande byteordningsmärke (BOM) för att kunna dra nytta av cachelagring av bytekod och undvika vissa körningsfel.

Testinformation

Testa innehållet i apppaket för att se till att de använder rätt filkodning.

Korrigeringsåtgärder

Öppna den berörda filen och välj Spara som på menyn Fil i Visual Studio. Välj listrutekontrollen bredvid knappen Spara och välj Spara med kodning. Välj alternativet Unicode (UTF-8 med signatur) i dialogrutan Avancerade spara alternativ och klicka på OK.

Direct3D-funktionsnivåtest

Stöd för Direct3D-funktionsnivå

Testar Microsoft Direct3D-appar för att säkerställa att de inte kraschar på enheter med äldre grafikmaskinvara.

Bakgrund

Microsoft Store kräver att alla applikationer som använder Direct3D renderas korrekt eller misslyckas på ett kontrollerat sätt på grafikkort med funktionsnivå 9-1.

Eftersom användarna kan ändra grafikmaskinvaran på sin enhet när appen har installerats måste din app vid start identifiera om den aktuella maskinvaran uppfyller minimikraven om du väljer en lägsta funktionsnivå som är högre än 9–1. Om minimikraven inte uppfylls måste appen visa ett meddelande till användaren som beskriver Direct3D-kraven. Om en app laddas ned på en enhet som den inte är kompatibel med bör den också identifiera att den vid start och visa ett meddelande till kunden som beskriver kraven.

Testinformation

Testet kontrollerar om apparna visas korrekt på funktionsnivå 9–1.

Korrigeringsåtgärder

Se till att appen renderas korrekt på Direct3D-funktionsnivå 9–1, även om du förväntar dig att den ska köras på en högre funktionsnivå. Mer information finns i Utveckla för olika Direct3D-funktionsnivåer.

Direct3D Trim efter uppehåll

Obs Det här testet gäller endast UWP-appar som utvecklats för Windows 8.1 och senare.

Bakgrund

Om appen inte anropar Trim på sin Direct3D-enhet släpper appen inte det minne som allokerats för dess tidigare 3D-arbete. Detta ökar risken för att appar avslutas på grund av systemminnesbelastning.

Testinformation

Kontrollerar att appar uppfyller d3d-kraven och säkerställer att appar anropar ett nytt Trim API vid deras Suspend-callback.

Korrigeringsåtgärder

Appen bör anropa API:et Trim på sitt IDXGIDevice3-gränssnitt när det är på väg att pausas.

Test av appfunktioner

Specialanvändningsfunktioner

Bakgrund

Specialanvändningsfunktioner är avsedda för mycket specifika scenarier. Endast företagskonton får använda dessa funktioner.

Testinformation

Kontrollera om appen deklarerar någon av funktionerna nedan:

  • Företagsautentisering
  • Delade användarcertifikat
  • Dokumentsbibliotek

Om någon av dessa funktioner deklareras visas en varning för användaren i testet.

Korrigerande åtgärder

Överväg att ta bort specialanvändningsfunktionen om din app inte kräver det. Dessutom är användningen av dessa funktioner föremål för ytterligare granskning av introduktionsprinciper.

Validering av Windows Runtime-metadata

Bakgrund

Säkerställer att komponenterna som levereras i en app överensstämmer med Windows Runtime-typsystemet.

Testinformation

Verifierar att .winmd- filer i paketet överensstämmer med Windows Runtime-reglerna.

Korrigerande åtgärder

  • ExclusiveTo-attributtest: Kontrollera att Windows Runtime-klasser inte implementerar gränssnitt som är markerade som ExclusiveTo en annan klass.
  • Typplatstest: Kontrollera att metadata för alla Windows Runtime-typer finns i den winmd-fil som har det längsta namnområdesmatchningsnamnet i apppaketet.
  • Typ av skiftlägesokänslighetstest: Kontrollera att alla Windows Runtime-typer har unika, skiftlägesokänsliga namn i apppaketet. Kontrollera också att inget UWP-typnamn också används som namnområdesnamn i apppaketet.
  • Test av typnamnskorrigering: Kontrollera att det inte finns några Windows Runtime-typer i det globala namnområdet eller i Windows-namnområdet på den översta nivån.
  • Test av allmän metadatakorrigering: Kontrollera att kompilatorn som du använder för att generera dina typer är uppdaterad med Windows Runtime-specifikationerna.
  • Properties test: se till att alla egenskaper i en Windows Runtime-klass har en get-metod (uppsättningsmetoder är valfria). Se till att typen av returvärdet för get-metoden matchar typen av indataparameter för set-metoden för alla egenskaper i Windows Runtime-typer.

Paket sanitetstest

Test av plattformsanpassade filer

Appar som installerar blandade binärfiler kan krascha eller inte köras korrekt beroende på användarens processorarkitektur.

Bakgrund

Det här testet validerar binärfilerna i ett apppaket för arkitekturkonflikter. Ett apppaket ska inte innehålla binärfiler som inte kan användas i processorarkitekturen som anges i manifestet. Om du inkluderar binärfiler som inte stöds kan det leda till att appen kraschar eller att storleken på apppaketen ökar i onödan.

Testinformation

Verifierar att varje fils "bitvärde" i PE-huvudet är lämpligt när det jämförs med deklarationen av app-paketets processorns arkitektur.

Korrigeringsåtgärder

Följ dessa riktlinjer för att se till att ditt apppaket endast innehåller filer som stöds av arkitekturen som anges i appmanifestet:

  • Om målprocessorarkitekturen för din app är neutral processortyp kan apppaketet inte innehålla filer av typen x86, x64 eller Arm binary eller image type.

  • Om målprocessorarkitekturen för din app är x86-processortyp får apppaketet endast innehålla filer av binärtyp eller bildtyp för x86. Om paketet innehåller x64- eller armbinär- eller bildtyper misslyckas testet.

  • Om målprocessorarkitekturen för din app är x64-processortyp måste apppaketet innehålla filer av binär- eller bildtyp x64. Observera att paketet i det här fallet också kan innehålla x86-filer, men den primära appupplevelsen bör använda x64-binärfilen.

    Men om paketet innehåller filer av typen Arm binary eller image, eller bara innehåller x86-binärfiler eller filer av bildtyp, misslyckas testet.

  • Om målprocessorarkitekturen för din app är typ av armprocessor får apppaketet endast innehålla filer av typen Arm-binär eller bildtyp. Om paketet innehåller x64- eller x86-binära filer eller bildtypfiler misslyckas testet.

Test av stöd för katalogstruktur

Verifierar att program inte skapar underkataloger som en del av installationen som är längre än MAX-PATH.

Bakgrund

OS-komponenter (inklusive Trident, WWAHost osv.) är internt begränsade till MAX-PATH för filsystemsökvägar och fungerar inte korrekt för längre sökvägar.

Testinformation

Verifierar att ingen sökväg i appinstallationskatalogen överskrider MAX-PATH.

Korrigeringsåtgärder

Använd en kortare katalogstruktur och eller filnamn.

Test av resursanvändning

WinJS-bakgrundsuppgiftstest

WinJS-bakgrundsuppgiftstestet säkerställer att JavaScript-appar har rätt slutinstruktioner så att appar inte förbrukar batteri.

Bakgrund

Appar som har JavaScript-bakgrundsaktiviteter måste anropa Close() som den sista instruktionen i sin bakgrundsaktivitet. Appar som inte gör detta kan hindra systemet från att återgå till anslutet vänteläge och leda till att batteriet töms.

Testinformation

Om appen inte har någon bakgrundsaktivitetsfil angiven i manifestet godkänns testet. Annars parsar testet javascript-bakgrundsaktivitetsfilen som anges i apppaketet och letar efter en Close()-instruktion. Om det hittas godkänns testet; annars misslyckas testet.

Korrigeringsåtgärder

Uppdatera JavaScript-bakgrundskoden för att anropa Close() korrekt.