# Deployment / IIS Handoff 2026-05-19

Letzter Nachtrag: 2026-05-20

## Ziel

`TrafagSalesExporter` bleibt das fuehrende Projekt, wird aber fuer den Server als ASP.NET/IIS-Webanwendung im bisherigen `BiDashboard`-Schema veroeffentlicht.

Das separate lokale Projekt `..\BiDashboard` wird fuer die aktuelle Weiterarbeit nicht benoetigt. Die relevanten Publish-/Hosting-Einstellungen wurden in `TrafagSalesExporter` uebernommen.

## Server / URL / Publish-Pfad

Server / DNS:

```text
trch-webapp-bidashboard.trafagch.local
tragvapp401.trafagch.local
10.120.1.17
```

Publish-Share:

```text
\\trch-webapp-bidashboard.trafagch.local\BiDashboard$\
```

Wahrscheinliche Browser-URL:

```text
https://trch-webapp-bidashboard.trafagch.local/BiDashboard/
```

Hinweis: Ohne `/BiDashboard` bzw. ueber HTTP kam lokal weiterhin `404 Microsoft-HTTPAPI/2.0`. Mit `https://.../BiDashboard` meldete der Browser laut Test `500`, was bedeutet, dass IIS die Application erreicht.

## Aktueller Publish-Stand

Das Projekt `TrafagSalesExporter.csproj` erzeugt jetzt eine `BiDashboard`-Publish-Ausgabe:

```text
BiDashboard.dll
BiDashboard.deps.json
BiDashboard.runtimeconfig.json
BiDashboard.staticwebassets.endpoints.json
web.config
wwwroot
runtimes
trafag_exporter.db
Microsoft.AspNetCore.Authentication.Negotiate.dll
```

Bewusst:

- keine EXE / kein AppHost
- `UseAppHost=false`
- `AssemblyName=BiDashboard`
- `RootNamespace=TrafagSalesExporter`
- `Microsoft.AspNetCore.Authentication.Negotiate` ist enthalten wie im alten `BiDashboard`-Projekt
- lokale Build-/Probe-Ordner werden vom Publish ausgeschlossen

Relevante Commits:

```text
8d10372 Configure Trafag web publish profile
f128d35 Publish web app without apphost
e9b616f Align Trafag publish output with BiDashboard
1533570 Exclude local build artifacts from web publish
5087a7c Enable IIS publish diagnostics
e3b9d8d Switch IIS hosting to out-of-process
1dc336d Enable IIS detailed startup diagnostics
```

## Veroeffentlichen

Standard-Publish:

```powershell
dotnet publish .\TrafagSalesExporter.csproj -c Release --no-restore /p:PublishProfile=FolderProfile --verbosity minimal
```

Das Publish-Profil liegt hier:

```text
Properties/PublishProfiles/FolderProfile.pubxml
```

## Diagnose-web.config

Im Repo liegt eine explizite `web.config`, damit IIS/ANCM Diagnoseinformationen liefern kann:

```xml
<httpErrors errorMode="Detailed" existingResponse="PassThrough" />
<aspNetCore processPath="dotnet"
            arguments=".\BiDashboard.dll"
            stdoutLogEnabled="true"
            stdoutLogFile=".\logs\stdout"
            hostingModel="outofprocess">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_DETAILEDERRORS" value="true" />
  </environmentVariables>
</aspNetCore>
```

Der Ordner `logs` wurde auf dem Share angelegt:

```text
\\trch-webapp-bidashboard.trafagch.local\BiDashboard$\logs
```

Nach einem Browser-Reload mit `500` war der Ordner weiterhin leer. Das deutet auf eines der folgenden Themen:

- App-Pool darf nicht in `logs` schreiben.
- Fehler passiert auf IIS/ANCM-Ebene vor dem App-Start.
- fehlendes oder defektes .NET 8 Hosting Bundle / AspNetCoreModuleV2.

## Nachtrag 2026-05-20: aktueller 500-Befund

Geprueft:

- `diag.txt` wurde direkt in den Publish-Ordner geschrieben:

```text
\\trch-webapp-bidashboard.trafagch.local\BiDashboard$\diag.txt
```

- Browser-Test:

```text
https://trch-webapp-bidashboard.trafagch.local/BiDashboard/diag.txt
```

- Ergebnis im Browser:

```text
BiDashboard publish folder reached 2026-05-20T08:19:14.2667783+02:00
```

Schlussfolgerung:

- IIS-URL `/BiDashboard` zeigt auf den richtigen Publish-Ordner.
- Binding/virtueller Pfad/Physical Path sind fuer statische Dateien korrekt.
- Der `500` kommt nicht mehr von einer falschen URL.
- Der Fehler entsteht beim ASP.NET-Core-App-Start oder im ASP.NET-Core-IIS-Modul.

Zusaetzlich geprueft:

- `BiDashboard.dll` konnte aus dem Publish-Ordner per `dotnet .\BiDashboard.dll` gestartet werden und brach nicht sofort mit einer Exception ab.
- Dabei blieb ein lokaler Testprozess `dotnet` kurz aktiv und sperrte `BiDashboard.dll`; Prozess wurde beendet und danach erfolgreich neu publiziert.
- Nach erneutem Browser-Aufruf blieb `logs` weiterhin leer.
- HTTPS-Test von der Entwickler-Maschine per `curl` scheitert vor HTTP wegen Schannel/Client-Credentials:

```text
SEC_E_NO_CREDENTIALS (0x8009030e)
```

Diese lokale `curl`-Einschraenkung ist nicht der IIS-500-Fehler im Browser.

Aktueller Verdacht in Prioritaet:

1. .NET 8 Hosting Bundle / AspNetCoreModuleV2 fehlt oder ist nicht korrekt installiert.
2. App Pool ist nicht passend fuer ASP.NET Core eingestellt.
3. App-Pool-Identity hat noch nicht alle noetigen Rechte fuer Start, SQLite oder Logs.
4. Details stehen nur im Windows Event Viewer, weil stdout nicht erzeugt wird.

Wichtig:

- Der Server braucht kein installiertes Microsoft Excel.
- XLSX wird ueber ClosedXML/OpenXML gelesen und geschrieben.
- Eine Umstellung auf CSV ist fuer dieses Deployment-Problem nicht noetig.

## Rechtebefund

ACL auf dem Publish-Ordner zeigte:

```text
IIS_IUSRS: ReadAndExecute
TRAFAGCH\koi: FullControl
```

Versuch, Rechte selbst zu setzen:

```powershell
icacls "\\trch-webapp-bidashboard.trafagch.local\BiDashboard$" /grant "IIS_IUSRS:(OI)(CI)M" /T
```

Ergebnis:

```text
Zugriff verweigert
```

Auch per SID fuer `IIS_IUSRS` wurde es abgelehnt. Wir koennen publishen und Dateien schreiben, aber keine NTFS-/Share-Rechte auf dem Server aendern.

Spaeterer Befund:

- Auf Publish-Ordner und `logs` war eine konkrete App-Pool-SID mit `Modify` sichtbar.
- `IIS_IUSRS` hatte weiterhin nur `ReadAndExecute`.
- Trotz dieser sichtbaren App-Pool-SID blieben stdout-Logs leer; daher reicht der ACL-Befund allein nicht zur Erklaerung.

## Wahrscheinlichster aktueller Fehler

Die App startet in `Program.cs` sofort die Datenbankinitialisierung:

```text
DatabaseInitializationService.InitializeAsync()
db.Database.EnsureCreatedAsync()
PRAGMA journal_mode=WAL
Schema-Wartung
SeedDefaults
```

SQLite schreibt bzw. aendert dabei mindestens:

```text
trafag_exporter.db
trafag_exporter.db-shm
trafag_exporter.db-wal
```

Wenn der App-Pool nur Lesen/Ausfuehren hat, kann das beim Start als `500` enden. Da spaeter aber eine konkrete App-Pool-SID mit `Modify` sichtbar war, muessen zusaetzlich .NET Hosting Bundle, App-Pool-Konfiguration und Event Viewer geprueft werden.

## Server-Spezialist: konkrete Bitte

Bitte auf dem Server `tragvapp401` pruefen:

1. IIS Application `/BiDashboard` zeigt auf genau den Ordner mit dieser Datei:

```text
\\trch-webapp-bidashboard.trafagch.local\BiDashboard$\web.config
```

oder auf den entsprechenden lokalen physischen Pfad.

2. App-Pool-Identity ermitteln.

3. Dieser konkreten App-Pool-Identity `Modify` geben auf:

```text
Publish-Ordner
logs\
trafag_exporter.db
trafag_exporter.db-shm
trafag_exporter.db-wal
```

Alternativ voruebergehend `IIS_IUSRS` mit `Modify`, wenn die genaue App-Pool-Identity nicht klar ist.

4. App-Pool neu starten.

5. URL testen:

```text
https://trch-webapp-bidashboard.trafagch.local/BiDashboard/
```

6. Wenn weiter `500`, bitte pruefen:

```text
\\trch-webapp-bidashboard.trafagch.local\BiDashboard$\logs
```

und Windows Event Viewer:

```text
IIS AspNetCore Module V2
Application Error
.NET Runtime
```

## Kurzmeldung an Server-Spezialist

```text
diag.txt unter https://trch-webapp-bidashboard.trafagch.local/BiDashboard/diag.txt ist erreichbar.
Der IIS-Pfad stimmt also.

Die App selbst liefert weiterhin 500, und \\...\BiDashboard$\logs bleibt leer, obwohl stdoutLogEnabled=true gesetzt ist.
Die App ist als .NET 8 ASP.NET-Core-App publiziert, ohne EXE/AppHost, Start via:
dotnet .\BiDashboard.dll

Bitte am Server pruefen:
1. .NET 8 Hosting Bundle installiert/repariert?
2. AspNetCoreModuleV2 im IIS vorhanden?
3. App Pool:
   - .NET CLR Version = No Managed Code
   - Managed Pipeline Mode = Integrated
   - Enable 32-bit Applications = False
4. Event Viewer > Windows Logs > Application:
   - IIS AspNetCore Module V2
   - .NET Runtime
   - Application Error
5. App-Pool-Identity hat Modify auf Publish-Ordner, logs und trafag_exporter.db*

Microsoft Excel muss nicht installiert sein; XLSX wird ueber ClosedXML/OpenXML gelesen.
```

## Aktueller Restzustand im Git-Working-Tree

Es gibt weiterhin alte/unabhaengige lokale Dateien und geloeschte Alt-Dokumente im Working Tree. Diese wurden bewusst nicht committed:

```text
../BiDashboard/
.tmp_tools/
Tools/FinanceProbe/.tmp_tools/
verify_probe_out*/
docs/CFO_Kurzbericht_270515_NEU.docx
docs/FINANCE_AMPEL_LAENDER_2026-05-19.xlsx
financeprobe.*.log
mainapp.*.log
```

Ausserdem sind mehrere alte Dateien als geloescht markiert. Nicht blind committen, bevor klar ist, ob sie wirklich entfernt werden sollen.

## Nachtrag 2026-05-20 IIS /BiDashboard PathBase

Die App ist fuer Betrieb unter `/BiDashboard` vorbereitet.

Relevant:

- `web.config` setzt:

```xml
<environmentVariable name="ASPNETCORE_PATHBASE" value="/BiDashboard" />
```

- `Program.cs` liest `ASPNETCORE_PATHBASE` und ruft `UsePathBase(...)` auf.
- `Components/App.razor` setzt `<base href>` dynamisch:
  - lokal ohne PathBase: `/`
  - Server mit PathBase: `/BiDashboard/`

Damit ist die erwartete Server-URL:

```text
https://trch-webapp-bidashboard.trafagch.local/BiDashboard/
```

Wenn die App im stdout-Log startet, aber Browser weiter `404` zeigt, zuerst IIS Application/Binding pruefen:

- Ist `BiDashboard` eine echte IIS Application und nicht nur ein Ordner?
- Zeigt sie auf `C:\inetpub\wwwcust\BiDashboard` bzw. den aktuellen Publish-Ordner?
- Stimmen Hostname, Port 443 und Zertifikat?

Bekannter Login-Stand:

- Wenn ein Browser-Popup `Diese Website fordert Sie auf, sich anzumelden` erscheint, ist das IIS/Windows Authentication.
- Die App selbst hat in `appsettings.json` aktuell `Security.Enabled=false`.
- Ein Login-Popup kommt daher von IIS, nicht von den App-internen HR-/Finance-Passwortseiten.