Übermitteln des Manifests an das Repository
Nachdem Sie ein Paketmanifest erstellt, das Ihre Anwendung beschreibt, sind Sie bereit, Ihr Manifest an das Repository von Windows-Paket-Manager zu übermitteln. Dies ist ein öffentliches Repository, das eine Sammlung von Manifesten enthält, auf die das Tool winget zugreifen kann. Um Ihr Manifest zu übermitteln, laden Sie es in das Open Source-Repository https://github.com/microsoft/winget-pkgs auf GitHub hoch.
Nachdem Sie einen Pull Request zum Hinzufügen eines neuen Manifests zum GitHub-Repository übermittelt haben, wird die Manifestdatei durch einen automatisierten Prozess validiert, und es wird überprüft, ob das Paket den Windows-Paket-Manager-Richtlinien entspricht und nicht als bösartig bekannt ist. Bei erfolgreicher Validierung wird das Paket dem öffentlichen Repository von Windows-Paket-Manager hinzugefügt, sodass es vom Clienttool winget erkannt werden kann. Beachten Sie die Unterscheidung zwischen den Manifesten im Open Source-GitHub-Repository und im öffentlichen Repository von Windows-Paket-Manager.
Wichtig
Microsoft behält sich das Recht vor, eine Übermittlung gleich aus welchem Grund abzulehnen.
Manifestvalidierung
Wenn Sie ein Manifest an das Repository https://github.com/microsoft/winget-pkgs auf GitHub senden, wird das Manifest automatisch validiert und auf Sicherheit im Windows-Ökosystem geprüft. Manifeste können auch manuell überprüft werden.
Weitere Informationen zum Validierungsprozess finden Sie weiter unten im Abschnitt Validierungsprozess.
Übermitteln ihres Manifests
Führen Sie die folgenden Schritte aus, um ein Manifest an das Repository zu übermitteln.
Schritt 1: Validieren des Manifests
Das Tool winget- stellt den Befehl validate bereit, um zu bestätigen, dass Sie das Manifest ordnungsgemäß erstellt haben. Verwenden Sie diesen Befehl, um das Manifest zu validieren.
winget validate \<path-to-the-manifests>
Tritt bei der Überprüfung ein Fehler auf, suchen Sie anhand der Fehler die Zeilennummer, und nehmen Sie eine Korrektur vor. Nach dem Validieren des Manifests können Sie es an das Repository übermitteln.
Schritt 2: Testen Ihres Manifests mit der Windows-Sandbox
Das Windows-Paket-Manager-Repository enthält ein Skript, das den Windows-Paket-Manager zum Testen von Manifestübermittlungen in einer Sandbox installiert. Navigieren Sie zum Ausführen des PowerShell-Skripts zum Repository „winget-pkgs“. Geben Sie in PowerShell den folgenden Befehl ein:
powershell .\Tools\SandboxTest.ps1 manifests\m\Microsoft\VisualStudioCode\1.56.0
Aktualisieren Sie das Skript bei Bedarf mit dem richtigen Pfad zu Ihrer Manifestdatei: .\Tools\SandboxTest.ps1 <path to manifest or manifest folder>
Das vollständige Sandbox-Testskript im Repository „winget-pkgs“ finden Sie hier.
Schritt 3: Klonen des Repositorys
Gehen Sie wie folgt vor, um einen Fork des Windows-Paket-Manager-Community-Repositorys zu erstellen und das Repository auf Ihrem lokalen Computer zu klonen:
Navigieren Sie im Browser zu https://github.com/microsoft/winget-pkgs, und wählen Sie Fork aus.
Verwenden Sie an der Windows-Eingabeaufforderung oder in PowerShell den folgenden Befehl, um Ihren Fork zu klonen.
git clone <your-fork-name>Wenn Sie mehrere Übermittlungen eingeben, erstellen Sie einen Branch anstelle eines Forks. Derzeit ist nur eine Manifestdatei pro Übermittlung zulässig.
git checkout -b <branch-name>
Schritt 4: Hinzufügen Ihres Manifests zum lokalen Repository
Sie müssen die Manifestdateien dem Repository in der folgenden Ordnerstruktur hinzufügen:
manifests / letter / publisher / application / version
- Der Ordner manifests ist der Stammordner für alle Manifeste im Repository.
- Der Ordner letter ist der erste Buchstabe des Herausgebernamens in Kleinbuchstaben, z. B. m für den HerausgeberMicrosoft.
- Der Ordner publisher gibt den Namen des Unternehmens an, das die Software veröffentlicht. Dieser kann z. B. Microsoft lauten.
- Der Ordner application gibt den Namen der Anwendung oder des Tools an. Beispiel: VSCode.
- Der Ordner version ist die Version der Anwendung oder des Tools. Beispiel: 1.0.0.
Die Werte PackageIdentifier und PackageVersion im Manifest müssen mit dem Herausgeber, den Anwendungsnamen und der Version im Manifestordnerpfad übereinstimmen. Weitere Informationen finden Sie unter Erstellen des Paketmanifests.
Schritt 5: Übermitteln des Manifests an das Remoterepository
Nun können Sie das neue Manifest per Push an das Remoterepository übermitteln.
Verwenden Sie den Befehl
commit, um Dateien hinzuzufügen, einen Commit der Änderung auszuführen und Informationen zur Übermittlung anzugeben.git commit -m "Submitting ContosoApp version 1.0.0" --allÜbermitteln Sie mit dem
push-Befehl die Änderungen per Push an das Remoterepository.git push
Schritt 6: Erstellen eines Pull Requests
Nachdem Sie Ihre Änderungen per Push übertragen haben, kehren Sie zu https://github.com/microsoft/winget-pkgs zurück, und erstellen Sie eine Pull Request, um die Verzweigung oder den Branch mit dem Hauptbranch zusammenzuführen.
Einreichungsprozess
Beim Erstellen eines Pull Request wird ein automatisierter Prozess gestartet, der die Manifeste validiert und Ihre Pull Request überprüft. Während dieses Prozesses führen wir Tests für das Installationsprogramm und die installierten Binärdateien aus, um die Übermittlung zu überprüfen.
Wir fügen der Pull Request Bezeichnungen hinzu, damit Sie den Fortschritt nachverfolgen können. Weitere Informationen zu Bezeichnungen und zum Prozess finden Sie weiter unten im Abschnitt Pull Request-Beschriftungen.
Nach Abschluss der Validierung wird Ihre Übermittlung manuell von einem Moderator überprüft, und nach der Genehmigung wird Ihre Anwendung dem Windows-Paket-Manager hinzugefügt.
Wenn während des Vorgangs ein Fehler auftritt, werden Sie darüber benachrichtigt, und unsere Bezeichnungen und der Bot unterstützen Sie bei der Korrektur Ihrer Übermittlung. Eine Liste der allgemeinen Fehler finden Sie weiter unten im Abschnitt „Validierungsprozess“.
Validierungsprozess
Wenn Sie einen Pull Request erstellen, um Ihr Manifest an das Windows-Paket-Manager-Repository zu übermitteln, wird ein Automatisierungsprozess gestartet, der das Manifest validiert und Ihren Pull Request verarbeitet. GitHub-Bezeichnungen werden verwendet, um den Fortschritt zu teilen und Ihnen die Kommunikation mit uns zu ermöglichen.
Erwartungen hinsichtlich der Übermittlung
Alle Anwendungsübermittlungen an das Windows-Paket-Manager-Repository sollten die Windows-Paket-Manager-Repositoryrichtlinien einhalten.
Erwartungen an Übermittlungen:
- Das Manifest entspricht den Schemaanforderungen.
- Alle URLs im Manifest führen zu sicheren Websites.
- Installer und Anwendung sind virenfrei. Das Paket kann versehentlich als Schadsoftware identifiziert werden. Wenn Sie der Meinung sind, dass es sich um ein falsch positives Ergebnis handelt, können Sie das Installationsprogramm an das Microsoft Defender-Team zur Analyse senden.
- Die Anwendung kann sowohl von Administratoren als auch von Nicht-Administratoren ordnungsgemäß installiert und deinstalliert werden.
- Der Installer unterstützt nicht interaktive Modi.
- Alle Manifesteinträge sind genau und nicht irreführend.
- Der Installer stammt direkt von der Website des Herausgebers.
Eine vollständige Liste der Richtlinien finden Sie unter Windows-Paket-Manager-Richtlinien.
Pull Request-Beschriftungen
Während der Validierung wird eine Reihe von Bezeichnungen auf den Pull Request angewendet, um den Fortschritt zu kommunizieren. Bei einigen Bezeichnungen werden Sie zum Ergreifen von Maßnahmen angeleitet, während sich andere an das Windows-Paket-Manager-Technikteam wenden.
Statusbezeichnungen
In der folgenden Tabelle werden die Statusbezeichnungen beschrieben, die Sie möglicherweise sehen werden.
| Bezeichnung | Details |
|---|---|
| Azure-Pipeline-Passed (Azure-Pipeline bestanden) | Das Manifest hat den Testlauf erfolgreich abgeschlossen. Es wartet auf Genehmigung. Wenn während des Testlaufs keine Probleme auftreten, wird es automatisch genehmigt. Wenn ein Test fehlschlägt, wird es möglicherweise für die manuelle Überprüfung gekennzeichnet. |
| Blocking-Issue (Blockierendes Problem) | Diese Bezeichnung gibt an, dass der Pull Request nicht genehmigt werden kann, weil ein blockierendes Problem vorliegt. Anhand der eingeschlossenen Fehlerbezeichnung können Sie häufig erkennen, welches blockierende Problem vorliegt. |
| Needs-Attention | Diese Bezeichnung gibt an, dass der Pull Request vom Windows-Paket-Manager-Entwicklungsteam untersucht werden muss. Dies liegt entweder an einem fehlgeschlagenen Test, der manuell überprüft werden muss, oder einem Kommentar, der dem Pull Request von der Community hinzugefügt wurde. |
| Needs-Author-Feedback | Gibt an, dass bei der Übermittlung ein Fehler aufgetreten ist. Der Pull Request wird Ihnen erneut zugewiesen. Wenn Sie das Problem nicht innerhalb von 10 Tagen beheben, schließen der Bot den Pull Request. Needs-Author-Feedback-Bezeichnungen (Erforderlich: Feedback des Autors) werden in der Regel hinzugefügt, wenn bei dem Pull Request ein Fehler aufgetreten ist, der aktualisiert werden sollte, oder wenn die Person, die den Pull Request überprüft, eine Frage hat. |
| Validation-Completed (Validierung abgeschlossen) | Gibt an, dass der Testlauf erfolgreich abgeschlossen wurde und Ihr Pull Request zusammengeführt wird. |
Fehlerbezeichnungen
In der folgenden Tabelle werden die Fehlerbezeichnungen beschrieben, die Sie möglicherweise sehen werden. Nicht alle Fehlerfälle werden Ihnen sofort zugewiesen. Einige lösen möglicherweise eine manuelle Validierung aus.
| Bezeichnung | Details |
|---|---|
| Binary-Validation-Error (Binärdateien-Validierungsfehler) | Die in diesem Pull Request enthaltene Anwendung hat den Installers Scan (Überprüfung von Installationsprogrammen) nicht bestanden. Dieser Test soll sicherstellen, dass die Anwendung in allen Umgebungen ohne Warnungen installiert werden kann. Weitere Detailinformationen zu diesem Fehler finden Sie weiter unten im Abschnitt Binärdateien-Validierungsfehler. |
| Error-Analysis-Timeout (Fehleranalyse-Timeout) | Beim Binary-Validation-Test-Test ist ein Timeout aufgetreten. Der Pull Request wird einem Windows-Paket-Manager-Techniker zur Untersuchung zugewiesen. |
| Error-Hash-Mismatch (Fehlerhashkonflikt) | Das übermittelte Manifest konnte nicht verarbeitet werden, weil der für InstallerURL bereitgestellte InstallerSha256-Hash nicht übereinstimmte. Aktualisieren Sie den InstallerSha256-Hash im Pull Request, und versuchen Sie es noch mal. |
| Error-Installer-Availability (Fehler wegen Verfügbarkeit des Installationsprogramms) | Der Validierungsdienst konnte das Installationsprogramm nicht herunterladen. Dies kann damit in Zusammenhang stehen, dass Azure-IP-Adressbereiche blockiert sind, oder dass die Installer-URL möglicherweise falsch ist. Überprüfen Sie, ob die InstallerURL richtig ist, und versuchen Sie es noch mal. Wenn Sie der Meinung sind, dass dies fehlerhaft fehlgeschlagen ist, fügen Sie einen Kommentar hinzu, und der Pull Request wird einem Windows-Paket-Manager-Techniker zur Untersuchung zugewiesen. |
| Manifest-Installer-Validation-Error | Bei der Bewertung eines MSIX-Pakets gibt es entweder Inkonsistenzen oder Werte, die nicht im Manifest enthalten sind. |
| Manifest-Path-Error (Manifestpfadfehler) | Die Manifestdateien müssen in einer bestimmten Ordnerstruktur abgelegt werden. Diese Bezeichnung weist auf ein Problem mit dem Pfad Ihrer Übermittlung hin. Die Ordnerstruktur weist beispielsweise nicht das erforderliche Format auf. Aktualisieren Sie Ihr Manifest und den Pfad, und übermitteln Sie Ihren Pull Request erneut. |
| Manifest-Validation-Error (Manifestvalidierungfehler) | Das übermittelte Manifest enthält einen Syntaxfehler. Beheben Sie das Syntaxproblem mit dem Manifest, und übermitteln Sie es erneut. Weitere Detailinformationen zum Manifestformat und -schema finden Sie unter Erforderliches Format. |
| PullRequest-Error (Pull Request-Fehler) | Der Pull Request ist ungültig, weil sich nicht alle übermittelten Dateien im Manifestordner befinden, oder weil der Pull Request mehrere Pakete oder Versionen enthält. Aktualisieren Sie Ihren Pull Request, um das Problem zu beheben, und versuchen Sie es noch mal. |
| URL-Validation-Error (URL-Validierungsfehler) | Der Validierungstest für URLs konnte die URL nicht finden und hat mit einem HTTP-Fehlerstatuscode (403 oder 404) geantwortet, oder der URL-Zuverlässigkeitstest ist fehlgeschlagen. Sie können ermitteln, welche die fragliche URL ist, indem Sie sich die Details der Pull Request-Überprüfung ansehen. Um dieses Problem zu beheben, aktualisieren Sie die fraglichen URLs, um den HTTP-Fehlerstatuscode zu beheben. Wenn das Problem nicht durch einen HTTP-Fehlerstatuscode verursacht wird, können Sie die URL zur Überprüfung übermitteln, um den Zuverlässigkeitsfehler zu vermeiden. |
| Validation-Defender-Error (Defender-Fehler bei Validierung) | Microsoft Defender hat während dynamischer Tests ein Problem gemeldet. Um dieses Problem zu reproduzieren, installieren Sie Ihre Anwendung, und führen Sie dann eine vollständige Microsoft Defender-Überprüfung aus. Wenn Sie das Problem reproduzieren können, korrigieren Sie die Binärdatei, oder übermitteln Sie sie zur Analyse, um Unterstützung bei falsch positiven Ergebnissen zu erhalten. Wenn Sie das Problem nicht reproduzieren können, fügen Sie einen Kommentar hinzu, damit die Windows-Paket-Manager-Techniker es untersuchen. |
| Validation-Domain (Domänenvalidierung) | Der Test hat ermittelt, dass die Domäne der InstallerURL nicht mit der erwarteten Domäne übereinstimmt. Die Windows-Paket-Manager-Richtlinien erfordern, dass die InstallerUrl direkt vom Releasestandort des ISV stammt. Wenn Sie der Meinung sind, dass dies eine fälschliche Erkennung ist, fügen Sie dem Pull Request einen Kommentar hinzu, damit die Windows-Paket-Manager-Techniker ihn untersuchen. |
| Validation-Error (Validierungsfehler) | Die Validierung des Windows-Paket-Managers ist während der manuellen Genehmigung fehlgeschlagen. Sehen Sie sich den Begleitkommentar für die nächsten Schritte an. |
| Validation-Executable-Error (Validierung: Fehler bei ausführbaren Dateien) | Während der Installationstests konnte der Test die primäre Anwendung nicht finden. Stellen Sie sicher, dass sich die Anwendung auf allen Plattformen ordnungsgemäß installieren lässt. Wenn Ihre Anwendung keine Anwendung installiert, aber trotzdem in das Repository aufgenommen werden sollte, fügen Sie dem Pull Request einen Kommentar hinzu, damit die Windows-Paket-Manager-Techniker ihn untersuchen. |
| Validation-Hash-Verification-Failed (Validierung: Hashverifizierungsfehler) | Während der Installationstests kann die Anwendung nicht installiert werden, da der InstallerSha256-Hash nicht mehr mit dem InstallerURL-Hash übereinstimmt. Dies kann passieren, wenn sich die Anwendung hinter einer Vanity-URL befindet und das Installationsprogramm aktualisiert wurde, ohne den InstallerSha256-Hash zu aktualisieren. Um dieses Problem zu beheben, aktualisieren Sie den InstallerSha256-Hash, der der InstallerURL zugeordnet ist, und übermitteln Sie noch mal. |
| Validation-HTTP-Error (Validierung: HTTP-Fehler) | Die für das Installationsprogramm verwendete URL verwendet nicht das HTTPS-Protokoll. Aktualisieren Sie die InstallerURL so, dass sie HTTPS verwendet, und übermitteln Sie den Pull Request erneut. |
| Validation-Indirect-URL (Validierung: indirkete URL) | Die URL stammt nicht direkt vom Server des ISV. Bei Tests wurde festgestellt, dass ein Redirector verwendet wurde. Dies ist nicht zulässig, weil die Windows-Paket-Manager-Richtlinien erfordern, dass die InstallerUrl direkt vom Releasestandort des ISV stammt. Entfernen Sie die Umleitung, und übermitteln Sie erneut. |
| Validation-Installation-Error (Validierung: Installationsfehler) | Während der manuellen Validierung dieses Pakets ist ein allgemeiner Fehler aufgetreten. Sehen Sie sich den Begleitkommentar für die nächsten Schritte an. |
| Validation-Merge-Conflict (Validierung: Zusammenführungskonflikt) | Dieses Paket konnte aufgrund eines Zusammenführungskonflikts nicht validiert werden. Beheben Sie den Zusammenführungskonflikt, und übermitteln Sie Ihren Pull Request erneut. |
| Validation-MSIX-Dependency (Validierung: MSIX-Abhängigkeit) | Das MSIX-Paket besitzt eine Abhängigkeit von einem Paket, die nicht aufgelöst werden konnte. Aktualisieren Sie das Paket, um die fehlenden Komponenten einzuschließen, oder fügen Sie die Abhängigkeit der Manifestdatei hinzu, und übermitteln Sie den Pull Request erneut. |
| Validation-Unapproved-URL (Validierung: nicht genehmigte URL) | Der Test hat ermittelt, dass die Domäne der InstallerURL nicht mit der erwarteten Domäne übereinstimmt. Die Windows-Paket-Manager-Richtlinien erfordern, dass die InstallerUrl direkt vom Releasestandort des ISV stammt. |
| Validation-Unattended-Failed (Validierung: automatische Installation fehlgeschlagen) | Während der Installation ist beim Test ein Timeout aufgetreten. Der wahrscheinlichste Grund hierfür ist, dass sich die Anwendung nicht automatisch installieren lässt. Der Grund könnte auch ein anderer Fehler sein, der auftritt und den Test beendet. Vergewissern Sie sich, dass Sie Ihr Manifest ohne Benutzereingabe installieren können. Wenn Sie Hilfe benötigen, fügen Sie dem Pull Request einen Kommentar hinzu, damit die Windows-Paket-Manager-Techniker ihn untersuchen. |
| Validation-Uninstall-Error (Validierung: Fehler bei Deinstallation) | Während des Deinstallationstests hat die Anwendung nach der Deinstallation keine vollständige Bereinigung durchgeführt. Sehen Sie sich den Begleitkommentar für die weitere Details an. |
| Validation-VCRuntime-Dependency (Validierung: VCRuntime-Abhängigkeit) | Das Paket besitzt eine Abhängigkeit von der C++-Runtime, die nicht aufgelöst werden konnte. Aktualisieren Sie das Paket, um die fehlenden Komponenten einzuschließen, oder fügen Sie die Abhängigkeit der Manifestdatei hinzu, und übermitteln Sie den Pull Request erneut. |
Inhaltsrichtlinienbezeichnungen
In der folgenden Tabelle sind die Inhaltsrichtlinienbezeichnungen aufgeführt. Wenn eine dieser Bezeichnungen hinzugefügt wird, hat etwas in den Manifestmetadaten eine zusätzliche manuelle Inhaltsüberprüfung ausgelöst, um sicherzustellen, dass die Metadaten die Windows-Paket-Manager-Richtlinien einhalten.
| Bezeichnung | Details |
|---|---|
| Policy-Test-2.1 (Richtlinientest 2.1) | Siehe Allgemeine Anforderungen für Inhalte. |
| Policy-Test-2.2 (Richtlinientest 2.2) | Siehe Inhalte einschließlich Namen und Logos (original und von Drittanbietern). |
| Policy-Test-2.3 (Richtlinientest 2.3) | Siehe Schadensrisiko. |
| Policy-Test-2.4 (Richtlinientest 2.4) | Siehe Diffamierung, Verleumdung, Beleidigung oder Bedrohung. |
| Policy-Test-2.5 (Richtlinientest 2.5) | Siehe Anstößiger Inhalt. |
| Policy-Test-2.6 (Richtlinientest 2.6) | Siehe Alkohol- oder Tabakprodukte, Waffen und Drogen. |
| Policy-Test-2.7 (Richtlinientest 2.7) | Siehe Jugendgefährdender Inhalt. |
| Policy-Test-2.8 (Richtlinientest 2.8) | Siehe Illegale Aktivitäten. |
| Policy-Test-2.9 (Richtlinientest 2.9) | Siehe Übermäßige oder unnötige Obszönitäten. |
| Policy-Test-2.10 (Richtlinientest 2.10) | Siehe Spezifische Anforderungen für Länder/Regionen. |
| Policy-Test-2.11 (Richtlinientest 2.11) | Siehe Altersfreigaben. |
| Policy-Test-2.12 (Richtlinientest 2.12) | Siehe Benutzergenerierte Inhalte. |
Interne Bezeichnungen
In der folgenden Tabelle sind interne Fehlerbezeichnungen aufgeführt. Wenn interne Fehler auftreten, wird Ihr Pull Request den Windows-Paket-Manager-Technikern zur Untersuchung zugewiesen.
| Bezeichnung | Details |
|---|---|
| Internal-Error-Domain (Interner Fehler: Domäne) | Bei der Domänenvalidierung der URL ist ein Fehler aufgetreten. |
| Internal-Error-Dynamic-Scan (Interner Fehler: dynamische Überprüfung) | Fehler bei der Validierung der installierten Binärdateien. |
| Internal-Error-Keyword-Policy (Interner Fehler: Schlüsselwortrichtlinie) | Bei der Validierung des Manifests ist ein Fehler aufgetreten. |
| Internal-Error-Manifest (Interner Fehler: Manifest) | Bei der Validierung des Manifests ist ein Fehler aufgetreten. |
| Internal-Error-NoArchitectures (Interner Fehler: keine Architekturen) | Ein Fehler ist aufgetreten, weil der Test die Architektur der Anwendung nicht bestimmen konnte. |
| Internal-Error-NoSupportedArchitectures (Interner Fehler: keine unterstützten Architekturen) | Ein Fehler ist aufgetreten, weil die aktuelle Architektur nicht unterstützt wird. |
| Internal-Error-PR (Interner Fehler: Pull Request) | Während der Verarbeitung des Pull Request ist ein Fehler aufgetreten. |
| Internal-Error-Static-Scan (Interner Fehler: statische Überprüfung) | Während der statischen Analyse des Installationsprogramms ist ein Fehler aufgetreten. |
| Internal-Error-URL (Interner Fehler: URL) | Während der Zuverlässigkeitsvalidierung des Installationsprogramms ist ein Fehler aufgetreten. |
| Internal-Error (Interner Fehler) | Während des Testdurchlaufs ist ein generischer oder unbekannter Fehler aufgetreten. |
Binärdateien-Validierungsfehler
Wenn bei einer Pull Request-Validierung der Test zur Überprüfung von Installationsprogrammen nicht erfolgreich ist und die Bezeichnung Binary-Validation-Error (Fehler bei Binärdateivalidierung) empfangen wird, bedeutet dies, dass Ihre Anwendung nicht in allen Umgebungen installiert werden konnte.
Test zur Überprüfung von Installationsprogrammen
Um ein optimales Benutzererlebnis bei der Installation von Anwendungen zu gewährleisten, muss der Windows-Paket-Manager sicherstellen, dass alle Anwendungen unabhängig von der Umgebung fehlerfrei auf einem PC installiert werden. Ein wichtiger Test besteht darin, sicherzustellen, dass alle Anwendungen ohne Warnungen in verschiedenen gängigen Antivirenkonfigurationen installiert werden. Windows bietet das integrierte Antivirenprogramm Microsoft Defender, aber viele Unternehmenskunden und Benutzer verwenden andere Antivirensoftware.
Jede Übermittlung an das Windows-Paket-Manager-Repository wird von verschiedenen Antivirenprogrammen überprüft. Jedes dieser Programme verfügt über unterschiedliche Virenerkennungsalgorithmen, um potenziell unerwünschte Anwendungen (Potentially Unwanted Application, PUA) und Schadsoftware zu identifizieren.
Beheben von Fehlern bei der Binärdateivalidierung
Wenn eine Anwendung nicht erfolgreich validiert wird, versucht Microsoft zunächst mit dem Anbieter der Antivirensoftware zu klären, ob es sich um eine falsch positive Warnung handelt. In vielen Fällen aktualisiert der Anbieter der Antivirensoftware nach der Benachrichtigung und Überprüfung seinen Algorithmus, und die Anwendung besteht den Test.
Gelegentlich kann der Anbieter der Antivirensoftware nicht feststellen, ob es sich bei der erkannten Codeanomalie um einen Fehlalarm handelt. In diesem Fall kann die Anwendung dem Windows-Paket-Manager-Repository nicht hinzugefügt werden. Der Pull Request wird mit der Bezeichnung Binary-Validation-Error abgelehnt.
Wenn Sie für Ihren Pull Request die Bezeichnung Binary-Validation-Error erhalten, aktualisieren Sie Ihre Software, um den als PUA erkannten Code zu entfernen.
Mitunter werden echte Tools, die für das Debuggen und für Low-Level-Aktivitäten verwendet werden, in der Antivirensoftware als PUA angezeigt. Dies liegt daran, dass der erforderliche Debuggingcode eine ähnliche Signatur wie unerwünschte Software aufweist. Auch wenn dies eine legitime Programmierpraxis ist, können diese Anwendungen im Windows-Paket-Manager-Repository leider nicht akzeptiert werden.
Problembehandlung bei der Übermittlung
Wenn die Übermittlung des Windows-Paket-Managers nicht erfolgreich war, können Sie die oben beschriebenen Bezeichnungen verwenden, um den Grund für den Fehler zu untersuchen.
Führen Sie die folgenden Schritte aus, um Pull Request-Fehler zu untersuchen:
Unten auf der Webseite wird ein Pull Request-Fehler mit dem Text Einige Überprüfungen waren nicht erfolgreich angezeigt. Wählen Sie den Link Details neben einer fehlgeschlagenen Validierung aus, um die Azure Pipelines-Seite aufzurufen.
Wählen Sie auf der Azure Pipelines-Seite den Link 0 Fehler / 0 Warnungen aus.
Wählen Sie auf der nächsten Seite den fehlerhaften Auftrag aus.
Die nächste Seite zeigt die Ausgabe für den fehlerhaften Auftrag an. Die Ausgabe sollte Ihnen dabei helfen, die erforderliche Änderung zu identifizieren, um das Manifest zu korrigieren.
Im folgenden Beispiel trat der Fehler während der Aufgabe Installation Validation (Validierung der Installation) auf.
Windows developer
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für