ErControl

Ziel¶

Ein Benutzer mit einem ANT+-Ergometer (FE-C) oder einem ANT+-Pulsgurt soll nach der
Installation von ErControl ohne weitere Schritte testen können, ob ErControl mit seinem
Gerät funktioniert.

Vorher ging das nicht: AntInterface.exe wurde nicht mitinstalliert, und der Pfad zur Datei
war in den Einstellungen standardmäßig leer. Prefs.AntInterfaceReady prüfte nur
File.Exists auf diesem leeren Pfad und war damit false. Die Testknöpfe in der
Geräteverwaltung brachen deshalb mit "AntInterface ist nicht konfiguriert" ab – unabhängig
davon, ob ein funktionierendes ANT+-Gerät angeschlossen war.

Entscheidung¶

AntInterface wird immer installiert. Keine Checkbox, keine Komponente, kein Opt-in.

Begründung:

• Die Datei ist inert: kein Treiber, kein Dienst, keine Registry-Einträge, kein Autostart.
  Sie startet ausschließlich, wenn ErControl sie mit einem Pfad explizit aufruft. Sie kann
  also keine Fehlwirkung verursachen – sie kann nur fehlen.
• Der Nutzer, der den Test braucht, weiß in der Regel nicht, was "AntInterface" ist. Eine
  abgewählte Komponente hätte exakt das alte Problem reproduziert: Datei fehlt, Testknopf tot.
• Kosten: 21,7 MB im Archiv – gegenüber ErControl (205,8 MB) vertretbar.

Umsetzung¶

1. Installer (Misc/Setup/ErControl.iss): Release\AntInterface\* wird nach {app}\AntInterface
   kopiert, ohne Checkbox und ohne Komponente. Eigenes Unterverzeichnis, weil die
   x86-Selbstpublish-Version rund 100 Laufzeit-DLLs mitbringt, die sonst im Anwendungsordner
   neben ErControl.WPF.exe lägen. THIRD-PARTY-NOTICES.txt wird an dieser Stelle
   ausgeschlossen, da ErControl die Datei bereits nach {app} installiert (in den
   Release-Ständen vom 14.09. fehlte sie noch, das korrigiert der nächste Build mit).

2. Pfadauflösung (Prefs.AntInterfaceExePath): liefert die mitinstallierte Datei, sobald sie
   vorhanden ist, sonst den hinterlegten Override (AntInterfaceExePathOverride, gleicher
   Preferences-Key AntPowerBridge|ExePath wie bisher). Die Reihenfolge ist bewusst so: ein
   früher von Hand eingetragener Pfad würde nach einem Update sonst unbemerkt weiter auf eine
   veraltete AntInterface zeigen – so gewinnt immer die Version, die mit diesem ErControl
   ausgeliefert und mit ihm getestet wurde. Im Debug-Build liefert AntInterfaceBundled per
   #if DEBUG pauschal false, dort liegt die exe nicht neben der Anwendung und der Pfad
   muss weiterhin von Hand gesetzt werden.

3. Einstellungen (PreferencesView/PreferencesViewModel): Das Feld zeigt den Pfad, den
   ErControl tatsächlich startet, und ist gesperrt (Browse-Button ausgeblendet), solange die
   mitinstallierte Datei gewinnt – eine Eingabe würde ohnehin ignoriert. Die bisherige
   Sichtbarkeitslogik für die ganze Zeile entfällt dadurch.

4. Neu AntInterface/ANT-Stick.txt: kurzer Hinweistext für Anwender (Voraussetzungen,
   Testknopf, Logpfad) mit dem ausdrücklichen Hinweis, dass der 32-Bit-Treiber für den
   ANT-Stick nicht mitgeliefert wird, sondern vom Hersteller des Sticks stammt – ohne
   diesen Hinweis wäre ein neues "warum geht das nicht" zu erwarten gewesen.

5. Versionierung: ErControl und AntInterface teilen sich jetzt eine Versionsnummer, die nur
   noch in Directory.Build.props steht (3.1.1.0 auf 3.1.2.0 angehoben).
   AntInterface.csproj pflegt keine eigene <Version> mehr, sondern erbt sie und
   überschreibt projektlokal nur <Product> (damit die exe in den Dateieigenschaften nicht
   "ErControl" heißt). Grund: AntInterface gehört jetzt zum Auslieferungsumfang des Setups,
   ein eigener Versionsstrang hätte zwei Nummern für eine einzige Lieferung erzeugt. Bump auf
   3.1.2 statt 3.1.1, weil 3.1.1 bereits am 24.09. ohne mitgelieferte AntInterface erschienen
   ist. Die Testwerkzeuge (AntFecTester, BleFtmsTester, BleFtmsReceiver, SerialTester)
   behalten bewusst eigene Versionen – eigenständige Downloads mit eigener Redmine-Version.

6. Protokoll-Datei (AntInterface/Program.cs, ConfigureLogging): landet jetzt im selben
   Ordner wie das ErControl-Protokoll (%LOCALAPPDATA%\ErControl3\logs\) statt in einem
   eigenen AntInterface-Ordner. AntInterface wird seit diesem Ticket nur noch über den
   Testknopf in der Geräteverwaltung gestartet, ein zweiter Log-Ordner hätte die Fehlersuche
   unnötig auf zwei Orte verteilt. ANT-Stick.txt und AntInterface/README.md sind auf den
   neuen Pfad angepasst.

Frühere offene Frage – jetzt entschieden¶

Die Einstellung "Pfad zur AntInterface.exe" wurde nicht entfernt: Der Override bleibt als
Notnagel für den Entwicklungsbetrieb (Debug-Build, dort liegt die exe nicht neben
ErControl.WPF.exe) und für eine unvollständige Installation erhalten, ist im Feld aber
gesperrt/ausgeblendet, solange die mitinstallierte Datei automatisch gewinnt.

Nicht Bestandteil¶

• Kein Ausbau des Testwerkzeugs AntFecTester, kein zusätzlicher Testdialog, keine
  Schnittstellenänderung. Der Knopf "Testen" in der Geräteverwaltung deckt FE-C und
  ANT+-Puls ab und bleibt der Weg für Anwender.
• Keine Änderung am Pipe-Protokoll (ErControl.AntProtocol, ProtocolVersion = 1).

Geprüft / nicht geprüft¶

Geprüft: dotnet build (Debug und Release) mit 0 Warnungen/0 Fehlern, ErControl.Core.Tests
128/128 grün, beide exe melden Version 3.1.2.0.

Nicht geprüft: der Installer-Build selbst (auf dem Entwicklungsrechner ist kein InnoSetup
installiert) und die Wirkung nach einer echten Installation ohne angeschlossenes
ANT+-Gerät.