FAQ

Windows 10 oder neuer (32 oder 64 Bit) und die .NET-10-Laufzeit in der Variante x86. Die 64-Bit-Variante nützt nichts, auch wenn sie installiert ist: FoxServer ist 32-bittig, weil er das COM von Visual FoxPro lädt, und das ist es. Zum Installieren sind Administratorrechte nötig. Visual FoxPro wird nur auf dem Rechner gebraucht, auf dem Sie entwickeln.

Nein, und es ist nicht geplant. Der Host lädt das COM von Visual FoxPro, das zu Windows gehört und 32-bittig ist; es geht also nicht darum, Code zu portieren: der veröffentlichte Motor ist VFP selbst. Möglich ist dagegen, FoxServer hinter einen beliebigen Reverse Proxy zu stellen.

Nein. Die Visual-FoxPro-IDE wird nur auf dem Rechner gebraucht, auf dem Sie die Controller entwickeln, denn init, controller-add und build geben an ein vfp9.exe weiter. Auf dem Server genügt es, die Dateien der VFP-9-Laufzeit (vfp9t.dll, vfp9r.dll, vfp9renu.dll und msvcr71.dll) neben die DLL Ihrer Anwendung zu kopieren und die 32-bittige .NET-10-Laufzeit zu haben.

Die nach Plätzen verkaufte, und sie dient allein der Entwicklung: der Server antwortet auf jede Anfrage, die nicht von 127.0.0.1 kommt, mit 403. Damit ein anderer Rechner Ihre API aufrufen kann, brauchen Sie eine Runtime-Lizenz, das zweite Produkt im Shop. Das ist das Missverständnis Nummer eins: es sieht nach einem Rechteproblem aus und ist die Lizenz.

Sie laden die Datei foxserver.lic aus der Detailansicht Ihrer Lizenz im Portal herunter und kopieren sie in den Ordner config der Installation, der standardmäßig C:\Programas\FoxServer\config\foxserver.lic lautet (bis 0.9.34 C:\Program Files (x86)\FoxServer). Danach FoxServer neu starten. Internet ist nicht nötig.

Der Kauf gibt Ihnen eine unbefristete Lizenz: die gekaufte Version läuft für immer, und daran ändert sich nichts. Die Wartung begrenzt Ihren Anspruch auf neue Versionen, und das Portal setzt ihn beim Herunterladen durch: es bietet Ihnen die neueste Version an, auf die Sie Anspruch haben, nicht die neueste überhaupt. Fällt kein Build in Ihren Zeitraum, antwortet der Download mit 403 und nennt den Grund.

Nein. Die Lizenz wird lokal gegen einen öffentlichen Schlüssel im Programm geprüft. Es gibt weder bei der Installation noch im Betrieb Anfragen an externe Server, und es gibt keine Telemetrie.

Ja. Jedes Projekt hat sein Manifest in config\servers\ und seinen Port. Alle kommen beim Start von FoxServer hoch. Vor dem Hinzufügen lohnt die Prüfung, ob nicht schon eines denselben Schlüssel host:port:prefix hat: foxserver deploy prüft das und bricht bei einer Kollision mit 11 ab, denn sonst startet der Host das eine und überspringt das andere mit einer Warnung, die nur im Protokoll steht.

Mit einem Zertifikat im .pfx-Format und den Schlüsseln issecure, certificatename und certificatepassword des Manifests. Das Kennwort wird mit foxserver middleware-set verschlüsselt abgelegt, wie jedes Geheimnis: das Manifest liest keine Umgebungsvariablen, und ein Klartextgeheimnis lässt den Motor mit 500 antworten.

Sie aktivieren auth im Manifest. Jeder Endpunkt ohne das Wort public in seinem HELP ist geschützt. Der Login-Endpunkt ist eine Ausnahme: das Token stellt die Middleware aus, wenn Ihr Controller mit dem Header X-Auth-Status und einem data-Objekt mit id, name und role antwortet. Der vollständige Vertrag steht auf der Seite Middleware.

Mit den Ergebnissen, die ApiController mitbringt: this.BadRequest(Meldung, Code), this.NotFound(Meldung), this.Forbidden(...) oder this.Fail(Status, Meldung, Code). Sie kommen als Problem Details (RFC 9457) heraus, mit application/problem+json, und Ihre Meldung reist in detail. Die Protokoll-Middleware zeichnet sie von selbst auf; für alles Weitere gibt es LogWarning, LogError und LogFromException.

Entscheidend ist nicht das interne Semaphor mit 50, sondern der STA-Threadpool von VFP: ein Thread je Kern, mindestens 2 und höchstens 8, JE SERVER. Und jeder Thread ist eine ganze VFP-Umgebung, mit ihrem Lifecycle und ihren Verbindungen: drei Manifeste auf einem Rechner mit 16 Kernen ergeben 24 VFP-Umgebungen und ebenso viele Datenbankverbindungen. Der Aufruf nach VFP ist synchron, ein langsamer Endpunkt belegt seinen Thread also, solange er dauert, und überschreitet er seine Frist, antwortet der Wachhund mit 503. Eingestellt wird das über FOXSERVER_WORKERS.

Sie wird nicht mehr gebraucht. Bis 0.8 lud der Motor ein mit TlbImp erzeugtes Interop-Assembly; seit 0.9 aktiviert er Ihren Code per ProgID direkt aus der MTDLL, und der dllpath des Manifests zeigt auf diese native MTDLL. Bringt Ihr Projekt noch sein Interop mit, bleibt es als Rückfalloption, falls die ProgID nicht registriert ist: nichts zu löschen und keine Eile mit der Migration.

Automatisch nicht: FoxServer überwacht die Festplatte nicht. Es gibt einen Schalter, und der genügt. Nach dem Neukompilieren mit foxserver build gibt ein POST an den Status-Endpunkt mit /reload und dem Header X-Status-Pin die COM-Objekte des Servers frei, und die nächste Anfrage erzeugt sie sauber neu, mit Ihrer neuen DLL.

Ja, und der Installer erledigt es bereits für Sie. Von Hand: bin\FoxServer.Host.exe --install-service, aus einer erhöhten Konsole. In services.msc lassen sich automatischer Start und Neustart bei Fehlern einstellen. Der Dienst liefert die Manifeste aus config\servers\ der Installation aus, nicht die eines einzelnen Projekts.

Sie werden nicht aus dem Code ausgelöst, sondern deklariert. Mit foxserver webhook-add-out tragen Sie Route, Abonnenten-URL und Geheimnis ein, und beim Bedienen dieses Endpunkts geht der Rumpf der Antwort signiert hinaus. FoxServer setzt Standard Webhooks um, mit der Signatur v1,<base64 des HMAC-SHA256>, einstellbaren Wiederholungen und einer Warteschlange für Fehlgeschlagenes. Getestet wird mit foxserver webhook-test.

Die Anfrageprotokolle liegen in logging.path und heißen {fileprefix}_{Typ}_{yyyyMMdd}.log. Das Protokoll des Hosts ist ein anderes: logs\FoxServer_<Datum>.log im Wurzelordner der Installation, eines pro Tag, bei 10 MB geteilt und nach 30 Tagen gelöscht. Die Windows-Ereignisanzeige erhält nichts, auch im Dienstmodus nicht: dort wird nur geschrieben, wenn das Schreiben des Protokolls selbst scheitert.

Sie kaufen eine Lizenz mit 1, 4 oder 8 Plätzen und kopieren die neue .lic nach config\. Ihr Code und Ihre Konfiguration bleiben unverändert. Wenn Sie andere Rechner bedienen müssen, brauchen Sie eine Runtime-Lizenz und keinen weiteren Platz.

Es gibt eine kostenlose 30-Tage-Trial-Lizenz zur Bewertung, die das Portal selbst ausstellt, sobald Sie Ihre E-Mail bestätigt haben. Und wenn es nach dem Kauf doch nicht passt, gewähren die Erstattungsbedingungen 30 Tage ab dem Kauf, über das gesetzliche vierzehntägige Widerrufsrecht hinaus.

Indem Sie mir an soporte@irwinrodriguez.dev schreiben. Es gibt keine Foren und keinen öffentlichen Issue-Tracker: Sie lesen es, und ich lese es, so ist das, wenn eine einzelne Person das Produkt macht.

Innerhalb einer Anfrage gibt es keine Parallelität: der Endpunkt belegt seinen Thread, bis er zurückkehrt, und jenseits von requesttimeoutseconds (standardmäßig 120 s) antwortet der Watchdog mit 503. Für Aufgaben von Sekunden: warten und antworten. Für lange Aufgaben verwendet die Branche das asynchrone Anfrage-Antwort-Muster: der Endpunkt trägt den Auftrag in eine Aufgabentabelle ein, gibt 202 Accepted mit einer Kennung und einem Location-Header auf /tasks/{id} zurück, und der Client fragt dort nach, bis der Status „fertig“ ist. Die Arbeit erledigt ein anderer Prozess, nicht FoxServer: eine VFP-Anwendung, die diese Tabelle überwacht, oder FoxCore.Runtime. FoxServer hat heute keinen Ort, an dem nach der Antwort noch Code läuft; das ist als offene Entscheidung vermerkt.

Nicht im Host: die MTDLL läuft auf der VFP-Laufzeit, die keinen Debugger hat, deshalb bewirkt SET STEP ON dort nichts. Dafür gibt es FoxServerBench (FoxForge › Aktuelles Projekt › Testbank): sie führt Ihre Prozedur ohne MTDLL, ohne Server und ohne http.sys aus, mit req und res so gefüllt, wie die Engine sie füllen würde, und mit dem Debugger auf Ihrem eigenen Quelltext. Es ist eine Testbank, kein Emulator: Middlewares und Authentifizierung werden nicht durchlaufen. Sie ist Schritt 8 der Anleitung im Paket, und JSONFox.fxp muss in build\ liegen, damit req.json gefüllt wird.

Ja: dafür gibt es den ApplicationLifecycle. Eine olepublic-Klasse, abgeleitet von ApplicationLifecycle, in einer .prg des Projekts; in OnApplicationStarting erzeugen Sie die Verbindung und bewahren sie mit this.SetResource("db", loVerbindung) auf, und in jedem Endpunkt holen Sie sie mit this.GetGlobalResource("db") zurück, das .NULL. liefert, wenn sie fehlt. Der Hook füllt den Block lifecycle des Manifests beim Kompilieren. Seit 0.9.16 läuft das einmal pro Thread des Pools, nicht pro Anfrage: mit vier Threads haben Sie vier Verbindungen, was in VFP das Richtige ist. Das vollständige Rezept steht im RECETARIO des Pakets, §2.