Microsoft vereinfacht die Veröffentlichung von Anwendungen im Microsoft Store für Unternehmen. Firmen müssen für ein Entwicklerkonto künftig keine Registrierungsgebühr mehr bezahlen. Außerdem können sie sich mit Microsoft-Entra-ID-Arbeitskonten anmelden. Ein überarbeiteter Registrierungsprozess soll den Weg von der Kontoerstellung bis zur ersten App-Veröffentlichung verkürzen.

Der Microsoft Store ist Microsofts zentrale Plattform für die Verteilung von Anwendungen unter Windows. Entwickler können dort Apps bereitstellen, aktualisieren und sowohl Endanwender als auch Unternehmenskunden erreichen. In Unternehmensumgebungen lassen sich Anwendungen unter anderem über Microsoft Intune verwalten und verteilen. Nach Angaben von Microsoft zählt der Store mehr als 250 Millionen monatlich aktive Nutzer.

Unterstützt werden verschiedene Anwendungstypen, darunter klassische Win32-Anwendungen, UWP-Apps, Progressive Web Apps (PWA), .NET-MAUI- und Electron-Anwendungen. Microsoft versucht seit einigen Jahren, den Store auch für Anbieter klassischer Desktopsoftware attraktiver zu machen.

Kostenloses Entwicklerkonto für Unternehmen

Die auffälligste Änderung betrifft die Registrierungskosten. Bislang mussten Unternehmen eine einmalige Gebühr von 99 US-Dollar entrichten, um ein Entwicklerkonto für den Microsoft Store anzulegen. Diese Gebühr entfällt nun.

Microsoft hatte bereits im vergangenen Jahr die Registrierungsgebühr für Einzelentwickler abgeschafft. Nun gilt die Gebührenfreiheit auch für Unternehmen. Im Vergleich zu anderen großen App-Plattformen fällt Microsoft damit aus der Reihe: Apple verlangt für die Teilnahme am Apple Developer Program weiterhin 99 US-Dollar pro Jahr, während Google für ein Entwicklerkonto in der Play Console eine einmalige Gebühr von 25 US-Dollar erhebt.

Anmeldung mit Microsoft Entra ID

Neu ist außerdem die Anmeldung über Microsoft Entra ID. Die Plattform, die früher unter dem Namen Azure Active Directory bekannt war, dient Unternehmen zur Verwaltung von Identitäten und Zugriffsrechten.

Mitarbeiter können damit ihr bestehendes Firmenkonto nutzen, statt ein separates Microsoft-Konto anzulegen. Laut Microsoft vereinfacht das die Zuordnung von Entwicklerkonten zu Organisationen und reduziert den Verwaltungsaufwand.

Einfachere Verifizierung

Parallel dazu hat Microsoft den Registrierungsprozess überarbeitet. Die neue Oberfläche führt Unternehmen schrittweise durch die Anmeldung, prüft Eingaben frühzeitig auf mögliche Fehler und zeigt den Status von Verifizierungen in Echtzeit an. Viele Prüfungen laufen laut Microsoft automatisch ab.

Benachrichtigungen per E-Mail informieren über den Fortschritt und weisen auf fehlende Angaben oder erforderliche Nachweise hin. Das soll Rückfragen reduzieren und den Zeitraum bis zur ersten App-Einreichung verkürzen.

Für eine möglichst schnelle Freischaltung empfiehlt Microsoft Unternehmen, bereits vor der Registrierung bestimmte Informationen bereitzuhalten. Besonders hilfreich sei eine D‑U‑N‑S-Nummer. Mit der von Dun & Bradstreet vergebenen Unternehmenskennung lassen sich Firmendaten automatisch abgleichen, was die Verifizierung beschleunigen kann.

Unternehmen ohne D‑U‑N‑S-Nummer können stattdessen Dokumente wie Handelsregisterauszüge, Gewerbenachweise oder andere offizielle Nachweise hochladen. Damit kann die Prüfung jedoch länger dauern. Zudem sind Verifizierungsversuche auf maximal drei Einreichungen begrenzt, weshalb Microsoft empfiehlt, nur korrekte und vollständige Dokumente hochzuladen. Außerdem empfiehlt Microsoft die Verwendung einer E-Mail-Adresse aus der eigenen Unternehmensdomäne, da andernfalls zusätzliche Nachweise erforderlich sein können.

Mehr Einnahmen für Entwickler

Mit den Änderungen will Microsoft den Store als Vertriebskanal für Windows-Anwendungen attraktiver machen. Der Konzern verweist darauf, dass sich viele Anwendungen ohne größere Anpassungen veröffentlichen lassen. Für Nicht-Spiele-Anwendungen erlaubt Microsoft weiterhin eigene In-App-Bezahlsysteme. In diesen Fällen behalten Entwickler die gesamten Umsätze. Die Neuerungen sollen vor allem die Einstiegshürden für Softwareanbieter und interne Entwicklungsteams senken, schreibt Microsoft in seinem Blogbeitrag zur vereinfachten Veröffentlichung von Unternehmensanwendungen im Microsoft Store.

(fo)

Microsoft hat mit Dev Configs for Windows eine Open-Source-Sammlung von Konfigurationen veröffentlicht, die Entwicklerarbeitsplätze unter Windows automatisiert einrichtet. Die Konfigurationen bauen auf der WinGet-Funktion winget configure auf und sollen einen frisch installierten Rechner mit einem einzigen Befehl in eine einsatzbereite Entwicklungsumgebung verwandeln. Sie sind deklarativ aufgebaut, durchlaufen automatisierte Tests und lassen sich laut Microsoft gefahrlos mehrfach ausführen.

Das Projekt zielt auf Entwickler, die ihre Arbeitsumgebung reproduzierbar aufsetzen wollen – auf einem neuen Notebook, einer Testmaschine oder in Teams mit standardisierten Setups. Statt eigene Installationsskripte zu pflegen, beschreiben die Konfigurationen den gewünschten Endzustand eines Systems. Microsoft unterscheidet drei Anwendungsfälle: einen vollständigen Entwicklerarbeitsplatz für Windows, eine erweiterte Shell-Umgebung für WSL sowie einzelne Sprach- und Framework-Workloads.

Komplettes Entwickler-Setup für Windows 11

Die umfangreichste Variante heißt „Windows Dev Config“. Sie installiert typische Entwicklerwerkzeuge, darunter PowerShell 7, Git, GitHub CLI, Visual Studio Code, .NET SDK 10, Python 3.13 mitsamt dem Paketmanager uv, Node.js, Oh My Posh und die PowerToys. Zusätzlich passt die Konfiguration Windows selbst an und aktiviert etwa den Entwicklermodus, lange Dateipfade und den Dark Mode. Auch Datei-Explorer, Startmenü, Suche und Edge erhalten neue Voreinstellungen.

Einen Schwerpunkt legt Microsoft auf das Windows-Subsystem für Linux (WSL). Die Konfiguration installiert WSL samt Ubuntu und überbrückt den dafür nötigen Neustart automatisch. Dazu nutzt sie den Windows-Mechanismus RunOnce, der eine Aufgabe nach dem nächsten Anmelden einmalig ausführt. Anwender müssen nach dem Reboot nicht eingreifen – die Installation läuft selbstständig durch.

Komfortable Shell-Umgebung mit WSL Comfort

Ferner bietet Microsoft mit „WSL Comfort“ eine Konfiguration speziell für die Arbeit mit Linux unter Windows. Sie läuft wahlweise interaktiv oder mit dem Schalter -NonInteractive unbeaufsichtigt und richtet sowohl die Windows- als auch die Linux-Seite ein. Anwender wählen zwischen Bash und Zsh und können optional den Prompt-Generator Starship, Homebrew oder verschiedene moderne Kommandozeilenwerkzeuge dazunehmen. Das Linux-Skript comfort-shell-bootstrap.sh läuft auch eigenständig auf jedem Ubuntu-Host.

Zu diesen Werkzeugen zählen rg (ripgrep) für schnelle Volltextsuchen im Quellcode, bat als Alternative zu cat mit Syntaxhervorhebung, zoxide für eine lernfähige Verzeichnisnavigation sowie fzf, fd, eza und jq. Auf der Windows-Seite richtet die Konfiguration ein angepasstes Profil für das Windows-Terminal sowie die Schriftart Cascadia Code Nerd Font ein. Nerd Fonts enthalten zusätzliche Symbole, die moderne Shell-Prompts etwa für Git-Branches oder Statusanzeigen nutzen.

Einzelne Workloads statt Komplettpaket

Wer keine vollständige Entwicklungsumgebung benötigt, kann stattdessen einzelne Workloads installieren. Microsoft nennt unter anderem TypeScript, Python, .NET, Go, Java, Rust, PHP, WinForms und WinUI 3. Jede dieser Konfigurationen bringt eine eigene Datei configuration.winget mit sowie ein Hilfsskript install.ps1, das die Installation anstößt und die PATH-Variable in der aktuellen Shell-Sitzung aktualisiert.

Technisch knüpfen die Dev Configs an die vorhandenen Konfigurationsfunktionen von WinGet an. Die Dateien beschreiben Pakete, Systemeinstellungen und Nachinstallationsschritte deklarativ. Da sie den Zielzustand statt einzelner Schritte definieren, lassen sich Setups zuverlässig wiederholen und auf weitere Rechner übertragen. Voraussetzung ist eine aktuelle Version des App Installers; falls winget configure nicht verfügbar ist, lässt sich die Funktion einmalig mit winget configure --enable aktivieren.

Erweiterung für die PowerToys angekündigt

Bereits angekündigt ist eine Erweiterung für die Command Palette der PowerToys. Sie soll die im Projekt definierten Konfigurationsabläufe direkt als auswählbare Einträge anbieten, sodass Anwender die jeweiligen Konfigurationsdateien nicht mehr manuell angeben müssen.

Mit den Dev Configs verfolgt Microsoft einen Ansatz, der an Dotfile-Sammlungen, Infrastructure as Code und automatisierte Entwickler-Setups unter Linux oder macOS erinnert. Weitere Details und die vollständige Liste der unterstützten Toolchains finden sich in der Dokumentation auf Microsoft Learn sowie im GitHub-Repository des Projekts.

(fo)

GitHub hat im Rahmen der Microsoft Build 2026 eine eigenständige Desktop-Anwendung für seinen KI-Assistenten Copilot vorgestellt. Wie das Unternehmen in der Ankündigung ausführt, soll die Copilot-App als zentrale Oberfläche dienen, über die sich mehrere KI-Agentensitzungen parallel starten, beobachten und steuern lassen. Verfügbar ist die Software zunächst als Technical Preview für Abonnenten der Tarife Copilot Pro, Pro+, Business und Enterprise. In den beiden Business-Plänen müssen Administratoren vorab Preview-Funktionen sowie die Copilot-CLI in den Richtlinieneinstellungen freischalten.

Als Motivation hinter der neuen App führt GitHub in seinem Blog an, dass die bislang verfügbaren Werkzeuge nicht auf den parallelen Einsatz mehrerer Agenten ausgelegt seien. Kontextinformationen verteilten sich über verschiedene Fenster, laufende Prozesse seien schwer nachzuverfolgen, und von Agenten erzeugter Code lande in Pull-Requests, ohne dass die Vorgeschichte dokumentiert sei. Nach Angaben des Unternehmens hat sich die Zahl der Commits auf der Plattform im Jahresvergleich nahezu verdoppelt und liegt bei mehr als 1,4 Milliarden pro Monat, parallel werden über zwei Milliarden Minuten GitHub Actions pro Woche verbraucht. Daraus leitet GitHub die Notwendigkeit ab, die zugrunde liegenden Systeme für agentengetriebene Arbeitsabläufe zu härten.

My Work und isolierte Worktrees pro Sitzung

Zentrales Element der Anwendung ist eine Ansicht namens „My Work“. Sie führt aktive Agentensitzungen, Issues, Pull-Requests und Hintergrundautomatisierungen aus mehreren Repositories in einer gemeinsamen Oberfläche zusammen. Damit sollen Entwicklerinnen und Entwickler auf einen Blick erkennen, wo Handlungsbedarf besteht – etwa wenn ein Agent einen Bug in der Produktion analysiert, ein zweiter eine Backlog-Aufgabe abarbeitet und ein dritter Feedback aus einem Code-Review umsetzt. Über einen Posteingang lassen sich aus offenen Issues oder Pull-Requests direkt neue Sessions starten, ohne zwischen Browser-Tabs und lokalen Werkzeugen wechseln zu müssen.

Technisch läuft jede Agentensitzung in einem eigenen git worktree, also einer realen, isolierten Kopie des jeweiligen Branches. Dadurch sollen mehrere Agenten parallel an demselben Repository arbeiten können, ohne sich gegenseitig Änderungen zu überschreiben. Die App verwaltet diese Worktrees laut GitHub vollständig selbst: Sie legt sie automatisch an, trennt sie pro Session und entfernt sie nach Abschluss wieder. Allerdings verhindere diese Architektur Merge-Konflikte nur innerhalb der einzelnen Arbeitsverzeichnisse; beim späteren Zusammenführen in gemeinsame Branches könnten divergierende Änderungen weiterhin zu Konflikten führen. Zudem belegen parallele Worktrees lokale Ressourcen wie Speicherplatz und Dateihandles – das sollten Entwicklungsteams bei CI- und Backup-Konzepten unbedingt berücksichtigen.

Agent Merge und bestehende Freigaberegeln

Mit „Agent Merge“ hat GitHub zudem eine Funktion vorgestellt, die Pull-Requests durch Review, Continuous Integration und Merge begleiten soll. Das Werkzeug überwacht die CI-Pipelines, verfolgt erforderliche Reviewer, reagiert auf fehlgeschlagene Checks und wartet, bis alle Bedingungen erfüllt sind. Für Organisationen mit etablierten CI/CD-Prozessen betont der Hersteller, dass bestehende Review- und Merge-Anforderungen weiterhin gelten. Branch Protection Rules, verpflichtende Status-Checks und Reviewer-Vorgaben blieben aktiv. Teams können laut Ankündigung konfigurieren, wie weit Agent Merge eingreifen darf – ob es lediglich CI-Läufe wiederholt, Feedback aus Reviews umsetzt oder unter definierten Bedingungen auch automatisch Merges vollzieht.

Standardmäßig fordert der Cloud-Agent vor jedem schreibenden Vorgang eine Erlaubnis ein, etwa vor dem Anlegen eines Issues oder dem Hinterlassen eines Kommentars. Erst wenn ein Team genügend Vertrauen in die Automatisierung gefasst hat, lässt sich ein Autopilot-Modus aktivieren. GitHub betont, dass die Verantwortung für Richtlinien und für die Frage, welche Automatisierungen erlaubt sind, bei den jeweiligen Organisationen bleibt. Für mehr Nachvollziehbarkeit sollen sogenannte „Canvases“ sorgen. Damit sind bidirektionale Arbeitsflächen für Menschen und Agenten gemeint, auf denen Pläne, Zwischenstände und Entscheidungen sichtbar bleiben, anstatt im Chatverlauf unterzugehen.

Sandboxes, erweitertes Code-Review und SDK

Ergänzend führt GitHub lokale und cloudbasierte Sandboxes ein, in denen Agenten Code ausführen, testen und iterieren sollen, ohne bereits Produktivsysteme zu berühren. Bei lokaler Ausführung läuft Copilot in einer isolierten Umgebung mit eingeschränktem Zugriff auf das Dateisystem, das Netzwerk und die Systemfunktionen. Cloud-Sandboxes nutzen dazu kurzlebige Linux-Umgebungen, die GitHub selbst betreibt. Die Richtlinien dafür legen Organisationen jeweils selbst fest – ein Punkt, der für Unternehmen mit strengen Compliance-Anforderungen relevant sein dürfte.

Die Copilot-Code-Review wurde um einen „Medium Tier“ erweitert, der Pull-Requests an ein leistungsfähigeres Modell weiterreicht. Auf Repository-Ebene können Administratoren entscheiden, ob ein kostengünstigeres oder ein präziseres Modell eingesetzt wird, etwa stärkere Modelle für sicherheitskritische Codebasen. Ergänzt wird das Review durch spezielle Skills wie /security-review und /rubberduck. Das GitHub-Copilot-SDK steht ab sofort generell zur Verfügung (GA), unter anderem für Node.js, Python, Go, .NET, Rust und Java. Teams sollen damit eigene agentische Werkzeuge auf demselben Runtime-Unterbau entwickeln können.

Auch die Copilot-CLI hat GitHub überarbeitet. Eine neue textbasierte Oberfläche mit Tabs gehört ebenso zu den Neuerungen wie eine On-Device-Spracherkennung, bei der Audiodaten das Gerät nach Angaben des Anbieters nicht verlassen, sowie geplante Aufgaben über den Befehl /every. Als Partner im Ökosystem nennt GitHub unter anderem LaunchDarkly, PagerDuty, Sonar und Miro, die als Agent-Apps in Copilot integriert werden sollen.

(map)