Vom Entwicklerrechner zum Kunden
Beim Entwickler startet die Anwendung ohne Schwierigkeiten. Auf einem neuen Arbeitsplatz fehlt plötzlich etwas. Vielleicht ist eine andere Laufzeit installiert, vielleicht existiert ein benötigter Ordner nur auf dem ursprünglichen Rechner. Für den Kunden ist der Unterschied wenig tröstlich: Die Software funktioniert nicht wie erwartet.
Ich würde deshalb nicht nur fragen, ob das Programm läuft, sondern ob sein Aufbau und seine Voraussetzungen nachvollziehbar übergeben werden können. Eine einmalig eingerichtete Arbeitsumgebung ist noch kein belastbarer Lieferprozess.
Der aktuelle Anlass: dotnetup
Microsoft stellte am 15. Oktober 2026 die öffentliche Vorabversion von dotnetup vor. Das Werkzeug verwaltet .NET-SDKs und Laufzeiten im Benutzerkonto, insbesondere für macOS und Linux, und berücksichtigt projektbezogene Versionsvorgaben. Es ist kein allgemein verbindlicher Entwicklungsstandard und keine Empfehlung, bestehende Installationen ungeprüft umzustellen. [1]
Der Anlass passt zu einem größeren Thema: Nicht nur der Quellcode, sondern auch die Umgebung muss beschreibbar sein.
Drei Versionen, drei unterschiedliche Fragen
Bei .NET sind das verwendete Entwicklungswerkzeug, das Ziel der Anwendung und die beim Start eingesetzte Laufzeit auseinanderzuhalten. Microsoft dokumentiert diese Auswahl getrennt. Eine global.json kann die SDK-Auswahl beeinflussen; sie ist keine vollständige Beschreibung aller Produktabhängigkeiten. [2]
Für eine Übergabe würde ich deshalb nicht allein „benötigt .NET“ notieren. Ich würde die tatsächlich erforderlichen Voraussetzungen, unterstützten Betriebssysteme und die vorgesehene Installationsart festhalten. Dasselbe Prinzip gilt auch außerhalb von .NET.
Die saubere Umgebung ist der ehrlichere Test
Mein wichtigster Prüfplatz wäre ein geeignetes, getrenntes System ohne die zufälligen Hilfen des Entwicklungsrechners. Dort wird das vorgesehene Lieferpaket verwendet, nicht eine Sammlung von Dateien, die jemand nachträglich zusammensucht.
Ich würde prüfen, ob Installation, erster Start und wesentliche Arbeitsabläufe unter den vorgesehenen Benutzerrechten funktionieren. Benötigte Konfiguration muss erklärt sein. Persönliche Zugangsdaten, lokale Dateipfade oder Testkennwörter dürfen nicht unbemerkt zu Voraussetzungen des Produkts werden.
Festlegen heißt nicht für immer einfrieren
Nachvollziehbare Versionen erleichtern die Wiederherstellung eines Entwicklungsstands. Das bedeutet für mich aber nicht, jede Abhängigkeit unbegrenzt unverändert zu lassen. Zur Festlegung gehört ein geplanter Umgang mit Sicherheitskorrekturen und Kompatibilität.
Ich würde Änderungen gebündelt prüfen und dokumentieren, welchen Stand das ausgelieferte Paket enthält. Ein automatisierter Build kann dabei helfen, wiederkehrende Schritte zuverlässig auszuführen. Sein Erfolg allein beweist jedoch noch nicht, dass die Anwendung auf einem Kundenrechner unter den vorgesehenen Bedingungen funktioniert.
Der Entwicklerrechner aktualisiert keine ausgelieferten Kopien
Microsoft weist bei dotnetup ausdrücklich darauf hin: Selbständig ausgelieferte Anwendungen mit eigener Laufzeit müssen mit dem aktualisierten Runtime-Stand erneut veröffentlicht und verteilt werden. Ein Update des Entwicklungsrechners patcht diese bereits ausgelieferten Kopien nicht. [1]
Für mich folgt daraus eine einfache organisatorische Pflicht: Es muss erkennbar sein, welche Produktversion ausgeliefert wurde und wie ein korrigiertes Paket seine Nutzer erreicht. Ein lokaler Versionswechsel ohne neue Lieferung löst dieses Problem nicht.
Was zur Übergabe gehört
Ich würde ein eindeutig zugeordnetes Lieferpaket, die notwendigen Voraussetzungen, eine kurze Betriebsanleitung und einen geregelten Supportweg erwarten. Bei servergestützter Software kommen Konfiguration, benötigte Gegenstellen und Verantwortlichkeiten hinzu. Geheimnisse werden getrennt und geschützt übergeben, nicht in einer allgemeinen Anleitung veröffentlicht.
Mein Fazit
„Bei mir läuft’s“ ist ein Ausgangspunkt, kein Abschluss. Professionelle Entwicklung macht den Weg vom Quellstand zum nutzbaren Produkt nachvollziehbar und prüft das Ergebnis dort, wo es später arbeiten soll.
Dieser Beitrag erläutert Gestaltungs- und Übergabefragen. Er enthält keine Installationsfreigabe für Vorabsoftware und keinen Nachweis, dass ein bestimmtes Kundenprodukt bereits entsprechend geprüft wurde.
Quellen und Einordnung
Recherchestand: 23. Oktober 2026. Herstellerveröffentlichungen sind keine eigenen Produktprüfungen. Beispiele und Empfehlungen sind im Text als solche eingeordnet.
[1] Microsoft: dotnetup als öffentliche Vorabversion, 15.10.2026
Quelle lesen ↗
[2] Microsoft Learn: Auswahl von SDK, Zielversion und Laufzeit
Quelle lesen ↗