Das AirCard-Windows-Repository lässt sich nur mit dem Startverfahren ausführen, das zur enthaltenen Projektstruktur passt. Klone oder entpacke das Repository zunächst in einen normalen Benutzerordner und prüfe danach die README-Datei sowie typische Projektdateien wie package.json, pyproject.toml, requirements.txt, Dockerfile oder eine Visual-Studio-Projektdatei. Diese Dateien entscheiden darüber, welche Laufzeitumgebung und welcher Startbefehl benötigt werden. Führe nicht vorsorglich alle im Internet üblichen Installationsbefehle aus.
Da sich Inhalt und Entwicklungsstand eines Repositories ändern können, wäre ein pauschaler AirCard-Befehl ohne geprüfte Versionsbasis nicht zuverlässig. Die folgende Anleitung führt dich deshalb zuerst zur eindeutigen Erkennung der AirCard-Variante und anschließend in den passenden Installationszweig. So vermeidest du unnötige Laufzeiten, globale Pakete und Änderungen an Windows.
Vor dem Start: AirCard-Version und Projektquelle festhalten
Arbeite nur mit dem vorgesehenen AirCard-Repository und notiere den verwendeten Branch, Tag oder Commit. Das ist besonders wichtig, wenn eine Anleitung später nicht mehr zur Ordnerstruktur passt. Bei einem bereits heruntergeladenen ZIP-Archiv fehlen außerdem die Git-Metadaten; Versions- und Branch-Befehle funktionieren dort nicht.
Für eine Git-Arbeitskopie benötigst du Git für Windows. Öffne Windows Terminal oder PowerShell und prüfe zuerst, ob Git verfügbar ist:
git --versionErscheint eine Versionsangabe, ist Git über den Suchpfad erreichbar. Meldet PowerShell, dass git nicht erkannt wurde, installiere Git für Windows aus der offiziellen Git-Distribution oder verwende das ZIP-Archiv des AirCard-Projekts. Öffne das Terminal nach einer Installation neu, damit die geänderte PATH-Variable übernommen wird.
Die Adresse des vorgesehenen Repositories setzt du im folgenden Befehl anstelle des Platzhalters ein. Der Zielordner AirCard wird dabei neu angelegt:
cd $HOME
mkdir Projects -ErrorAction SilentlyContinue
cd Projects
git clone <REPOSITORY-ADRESSE> AirCard
cd AirCardDie spitzen Klammern kennzeichnen einen Platzhalter und gehören nicht zur echten Adresse. Falls der Zielordner bereits existiert und Dateien enthält, bricht Git ab. Lösche ihn nicht ungeprüft, sondern wechsle in die vorhandene Arbeitskopie und kontrolliere dort den Zustand:
git status
git branch --show-current
git rev-parse --short HEADDiese Befehle lesen den Zustand lediglich aus. git status zeigt lokale Änderungen, der zweite Befehl den aktiven Branch und der dritte die Kurzform des Commits. Bei einem ZIP-Download notierst du stattdessen den Dateinamen des Archivs und eine eventuell angegebene Release-Bezeichnung.
Welche Technik verwendet das AirCard-Repository?
Der Dateibestand ist der verlässlichste Weg, die benötigte Umgebung zu bestimmen. Zeige zunächst die oberste Verzeichnisebene an:
Get-ChildItem -ForceÖffne danach eine vorhandene README-Datei. Der Dateiname kann unterschiedlich geschrieben sein; mit diesem Befehl findest du passende Dateien, ohne Unterordner zu durchsuchen:
Get-ChildItem -File -Filter README*Die folgenden Merkmale führen zu unterschiedlichen Installationswegen:
package.json: Das Projekt verwendet in der Regel Node.js. Die vorhandene Sperrdatei bestimmt, ob npm, Yarn oder pnpm vorgesehen ist.requirements.txt,pyproject.tomlodersetup.py: Es handelt sich wahrscheinlich um ein Python-Projekt. Eine virtuelle Umgebung verhindert Konflikte mit anderen Python-Anwendungen.Dockerfileodercompose.yaml: Das Repository bietet möglicherweise einen Containerweg. Ob dieser der empfohlene Weg ist, muss die AirCard-Dokumentation bestätigen.*.slnoder*.csproj: Das Projekt gehört zum .NET- beziehungsweise Visual-Studio-Umfeld. Die Zieldatei kann Anforderungen an SDK, Architektur und Windows-Komponenten enthalten.CMakeLists.txt,Makefileoder native Quelldateien: Hier können ein Compiler, CMake und weitere Build-Werkzeuge erforderlich sein. Ohne projektspezifische Build-Anweisung sollte kein beliebiger Compilerweg angenommen werden.
Mehrere Merkmale können gleichzeitig auftreten. Ein AirCard-Repository kann beispielsweise ein JavaScript-Frontend und einen Python-Dienst enthalten. Prüfe dann, ob die README getrennte Arbeitsverzeichnisse nennt. Installiere Abhängigkeiten jeweils in dem Ordner, in dem sich die zugehörige Manifestdatei befindet.
AirCard mit dem erkannten Projektverfahren einrichten
Node.js-Projekt anhand der Sperrdatei installieren
Prüfe zunächst, ob Node.js und der npm-Paketmanager erreichbar sind:
node --version
npm --versionEine Versionsausgabe bestätigt nur die Installation, nicht die Kompatibilität mit AirCard. Eine Datei wie .nvmrc, .node-version oder das Feld engines in package.json kann die erwartete Node.js-Version angeben.
Wähle den Paketmanager anhand der vorhandenen Sperrdatei. Führe nur den zutreffenden Zweig aus:
- Bei
package-lock.jsonist npm vorgesehen. - Bei
yarn.lockspricht die Projektstruktur für Yarn. - Bei
pnpm-lock.yamlist pnpm der passende Paketmanager.
Für ein npm-Projekt installiert npm ci exakt die in package-lock.json festgehaltenen Versionen:
npm ciFehlt package-lock.json, ist npm ci nicht geeignet. Verwende dann nur dann npm install, wenn die AirCard-Dokumentation npm nennt:
npm installWelche Startskripte verfügbar sind, zeigt dieser reine Prüfbefehl:
npm runStarte anschließend ausschließlich das in der Ausgabe und README genannte Skript, beispielsweise dev oder start. Ein Skriptname darf nicht geraten werden. Für ein tatsächlich vorhandenes start-Skript lautet der Aufruf:
npm run startPython-Abhängigkeiten in einer virtuellen Umgebung halten
Bei einer Python-Struktur prüfst du zuerst den Python-Launcher für Windows:
py --versionErstelle die virtuelle Umgebung im AirCard-Projektordner und aktiviere sie für die laufende PowerShell-Sitzung:
py -m venv .venv
.venv\Scripts\Activate.ps1Der Aktivierungsbefehl verändert nur die aktuelle Shell-Umgebung. Sollte PowerShell die Skriptausführung blockieren, ändere die Ausführungsrichtlinie nicht dauerhaft und nicht systemweit. Diese temporäre Freigabe gilt ausschließlich für den laufenden PowerShell-Prozess:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.venv\Scripts\Activate.ps1Bei einer vorhandenen requirements.txt installierst du die darin festgehaltenen Pakete so:
python -m pip install --upgrade pip
python -m pip install -r requirements.txtEnthält AirCard stattdessen nur pyproject.toml, ist daraus allein noch kein universeller Installationsbefehl ableitbar. Das Projekt kann pip, Poetry, uv oder ein anderes Werkzeug vorsehen. Verwende den in der README genannten Paketmanager. Auch der Startpunkt muss aus der Dokumentation oder der Projektkonfiguration hervorgehen; ein erfundener Dateiname wie app.py wäre keine belastbare Anleitung.
Die Umgebung verlässt du nach dem Test mit:
deactivateDocker nur bei dokumentierter Containerunterstützung einsetzen
Ein vorhandenes Dockerfile bedeutet nicht automatisch, dass der Containerweg unter Windows vollständig eingerichtet ist. Prüfe, ob AirCard zusätzlich eine Compose-Datei, benötigte Umgebungsvariablen, Ports und persistente Verzeichnisse dokumentiert. Docker Desktop muss laufen; je nach Konfiguration wird außerdem WSL 2 verwendet.
Existiert eine dokumentierte compose.yaml, kannst du die Konfiguration vor dem Start prüfen:
docker compose configDieser Befehl wertet die Compose-Datei aus und meldet unter anderem fehlende Variablen oder Syntaxprobleme. Erst bei erfolgreicher Prüfung folgt der Start:
docker compose up --buildBeendest du den Prozess mit Strg+C, können Container weiterhin vorhanden sein. Der folgende Befehl stoppt und entfernt die von Compose angelegten Container und Netzwerke, löscht aber ohne zusätzlichen Parameter keine benannten Volumes:
docker compose down.NET- oder Visual-Studio-Projekt prüfen
Bei einer .sln– oder .csproj-Datei zeigt der folgende Befehl, ob ein .NET SDK installiert ist:
dotnet --infoEine global.json kann eine bestimmte SDK-Version verlangen. Fehlt diese Version, erscheint beim Build eine entsprechende Meldung. Für ein SDK-basiertes Projekt sind Wiederherstellung und Build typischerweise getrennt prüfbar:
dotnet restore
dotnet buildOb AirCard danach mit dotnet run, über eine bestimmte Projektdatei oder in Visual Studio gestartet wird, richtet sich nach der Solution-Struktur. Bei mehreren Projekten darf nicht willkürlich eines gewählt werden. Die README oder die als Startprojekt markierte Anwendung muss den Einstieg festlegen.
Konfiguration und Zugangsdaten sauber behandeln
Viele Repository-Projekte benötigen Einstellungen, bevor ein lokaler Start möglich ist. Suche nach Dateien wie .env.example, example.env, config.example.json oder einem Konfigurationsabschnitt in der README. Eine Beispieldatei enthält normalerweise Platzhalter und darf nicht mit echten Geheimnissen in das Repository eingecheckt werden.
Mit Git kannst du prüfen, ob eine lokal angelegte Konfigurationsdatei versehentlich zur Aufnahme vorgemerkt wäre:
git status --shortBeginnt die Zeile einer geheimen Datei mit ??, ist sie unversioniert, aber noch nicht automatisch geschützt. Prüfe die vorhandene .gitignore. Ändere sie nur, wenn dies zum Projektverfahren passt. API-Schlüssel, Kennwörter, Sitzungstoken und private Zertifikate gehören weder in einen Commit noch in einen Screenshot einer Fehlermeldung.
Windows kann Dateiendungen ausblenden. Dadurch entsteht leicht eine Datei namens .env.txt, obwohl AirCard .env erwartet. PowerShell zeigt den tatsächlichen Namen:
Get-ChildItem -Force | Select-Object NameStart kontrollieren statt nur auf ein geöffnetes Fenster zu warten
Ein laufender Terminalprozess beweist noch nicht, dass AirCard einsatzbereit ist. Maßgeblich sind die Ausgabe des Programms, ein dokumentierter lokaler Endpunkt und das Fehlen schwerer Fehlermeldungen. Verwende nur die Adresse und den Port, die AirCard beim Start ausgibt oder in seiner Konfiguration festlegt.
Falls die Anwendung einen Port meldet, kannst du dessen Belegung mit PowerShell untersuchen. Ersetze 3000 nur durch den tatsächlich dokumentierten Port:
Get-NetTCPConnection -LocalPort 3000 -ErrorAction SilentlyContinueEine Zeile mit dem Status Listen zeigt, dass ein Prozess auf diesem Port Verbindungen erwartet. Bleibt die Ausgabe leer, ist AirCard möglicherweise noch nicht gestartet, vorzeitig beendet worden oder auf einen anderen Port ausgewichen. Die Prozesskennung aus der Spalte OwningProcess lässt sich auslesen, ohne den Prozess zu beenden:
Get-Process -Id <PROZESS-ID>Setze die angezeigte numerische Prozess-ID ein und entferne die spitzen Klammern. Beende einen unbekannten Prozess nicht, bevor du seine Zugehörigkeit geprüft hast.
Fehler anhand des Zeitpunkts eingrenzen
Der Zeitpunkt des Abbruchs grenzt die Ursache stärker ein als ein erneuter Komplettversuch. Nutze diese Reihenfolge:
- Das Klonen scheitert: Prüfe die Repository-Adresse, Zugriffsrechte und eine eventuell erforderliche Anmeldung. Eine Meldung über ein nicht gefundenes Repository kann auch bedeuten, dass das Projekt privat ist.
- Die Laufzeit wird nicht erkannt: Öffne das Terminal nach der Installation neu und wiederhole den Versionsbefehl. Bleibt er unbekannt, fehlt das Programm oder sein Installationsordner steht nicht in PATH.
- Die Installation der Pakete bricht ab: Vergleiche Laufzeitversion, Sperrdatei und Fehlermeldung. Lösche Sperrdateien nicht als ersten Versuch, weil dadurch andere Paketversionen ausgewählt werden können.
- Der Build scheitert: Suche nach der ersten eigentlichen Fehlermeldung, nicht nur nach nachfolgenden Sammelfehlern. Häufig nennt sie eine fehlende SDK-Version, einen Compiler oder eine nicht gesetzte Variable.
- AirCard startet und beendet sich sofort: Starte es erneut aus dem Terminal, damit die Ausgabe sichtbar bleibt. Fehlende Konfiguration, ein belegter Port oder ein nicht erreichbarer abhängiger Dienst sind mögliche Ursachen.
- Der Prozess läuft, aber die Oberfläche ist nicht erreichbar: Prüfe den ausgegebenen Port und die Bindungsadresse. Eine Firewall-Freigabe ist für einen ausschließlich lokal gebundenen Dienst nicht automatisch nötig und sollte nicht vorsorglich angelegt werden.
Antivirenwarnungen oder Microsoft-Defender-Funde dürfen nicht pauschal ignoriert werden. Prüfe in Windows-Sicherheit unter dem Schutzverlauf, welche Datei beanstandet wurde und welche Erkennung genannt ist. Füge weder den gesamten AirCard-Ordner noch deinen Projektordner ungeprüft zu den Ausschlüssen hinzu.
AirCard aktualisieren, ohne lokale Änderungen zu verlieren
Vor einer Aktualisierung zeigt git status, ob du Dateien verändert hast. Bei einer sauberen Arbeitskopie kannst du die Änderungen des eingerichteten Upstream-Branches abrufen:
git status
git pull --ff-only--ff-only verhindert, dass Git automatisch einen zusätzlichen Merge-Commit erzeugt. Scheitert der Befehl wegen lokaler Änderungen oder auseinander gelaufener Verläufe, sichere deine Arbeit und kläre den Branch-Zustand. Verwende nicht ungeprüft git reset --hard, da dieser Befehl lokale Änderungen verwerfen kann.
Nach einem Update können sich Abhängigkeiten oder Build-Ausgaben geändert haben. Führe den zum Projekt passenden Installations- beziehungsweise Restore-Schritt erneut aus. Welche Migrationen zusätzlich erforderlich sind, muss in den AirCard-Release-Hinweisen oder der README stehen.
Sauberer Rückweg bei einer lokalen Testinstallation
Eine rein im Projektordner installierte AirCard-Arbeitskopie lässt sich meist entfernen, indem du laufende Prozesse stoppst und anschließend den Ordner löschst. Kontrolliere vorher, ob darin eigene Konfigurationsdateien, exportierte Daten oder nicht eingecheckte Änderungen liegen. git status erfasst nur Dateien innerhalb der Arbeitskopie und zeigt keine extern gespeicherten Daten.
Bei Node.js liegen lokale Pakete gewöhnlich im Projektunterordner node_modules; eine Python-Umgebung befindet sich in der hier verwendeten Einrichtung unter .venv. Docker-Ressourcen werden dagegen nicht durch das Löschen des Quellordners entfernt. Verwende dort zuerst docker compose down im zugehörigen Projektverzeichnis und prüfe benannte Volumes gesondert, weil sie Anwendungsdaten enthalten können.
Die entscheidende Regel bleibt: Richte AirCard nicht nach einer vermuteten Programmiersprache ein, sondern nach README, Manifestdateien und Sperrdateien der tatsächlich vorliegenden Version. Sobald Laufzeit, Abhängigkeitsverwaltung und Startskript eindeutig zusammenpassen, wird aus dem Repository eine reproduzierbare Windows-Installation statt einer Folge zufälliger Befehlsversuche.
