Hallo Newsgroup,

habe eine auf .NET 2.0 beruhende Windows-Forms Applikation, die wir mit
einer App.config-Datei bestückt haben. Wenn man die entsprechende Datei
"<Applikationsname>.exe.config" nachträglich manuell ändert und dabei
einen Fehler macht, so dass kein korrektes XML mehr vorliegt, kommt beim
Programmstart die Fehlermeldung:

"Die Anwendung konnte nicht gestartet werden, weil die
Anwenungskonfiguration nicht korrekt ist. Zur Problembehebung sollten
Sie die Anwendung neu installieren".

(der Rechtschreibfehler steht da wirklich so drin, den hab ich mir nicht
ausgedacht).

Die Meldung wird offenbar vom Framework erzeugt, und zwar noch vor
Aufruf der Main-Routine. Gibt es einen Weg, diese Fehlermeldung durch
eine eigene Meldung auszutauschen?

Grüße

- Michael -

Hallo Michael,

> "Die Anwendung konnte nicht gestartet werden, weil die
> Anwenungskonfiguration nicht korrekt ist. Zur Problembehebung sollten Sie
> die Anwendung neu installieren".

ich kenne die Meldung (sie hat die Nr 14001) aus dem
Setup / C++ / vcredist_x86 - SideBySide - Bereich ... etwa,
wenn man die falsche vcredist_x86 benutzt, aber im
C# Bereich kenne ich sie bei falschen Manifest- und nicht
Konfigurations-Dateien (ja, der Schreibfehler ist so).

BTW: Englisches Pendant zur Fehlermeldung:
"this application failed to start because the application configuration is
incorrect. Reinstalling the application may fix the problem."
__________

BTW: Ich kenne da auch ein paar andere Meldungen,
die kommen könnten, die Du dann auch *alle* abfangen
müsstest. Es ist deswegen für meine Begriffe besser, die
Konfiguration sauber über eine Windows-Form vom
Programm führen zu lassen, sodass keine Fehler
dadurch entstehen können, dass jemand in einer
XML-Datei was falsch eingibt.


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET

Hallo Frank,
>
> BTW: Ich kenne da auch ein paar andere Meldungen,
> die kommen könnten, die Du dann auch *alle* abfangen
> müsstest.
> Es ist deswegen für meine Begriffe besser, die
> Konfiguration sauber über eine Windows-Form vom
> Programm führen zu lassen, sodass keine Fehler
> dadurch entstehen können, dass jemand in einer
> XML-Datei was falsch eingibt.

erst mal vielen Dank. Wenn dir schon nichts anderes einfällt, scheint es
wahrscheinlich wirklich keine bessere Lösung zu geben :-)

Eine eigene Form wollen wir nur ungern machen. Das wäre nämlich extra
eine eigene Anwendung nur für die Administratoren (unsere
Hauptapplikation läuft ohne Admin-Rechte und kann daher die .exe.config
nicht schreiben), und die exe.config muss nach der Installation auch
nur selten geändert werden. Da steht der Aufwand bei uns nicht im
Verhältnis zum Nutzen. Und dann setzen die Admins die Anwendung evtl.
gar nicht ein, sondern editieren die Datei trotzdem von Hand. Ich hatte
gehofft, man hätte mit wenig Aufwand einfach eine Meldung

"Die Datei ...exe.config ist beschädigt. Löschen Sie diese und führen
Sie eine Reparaturinstallation durch."

erzeugen können - wenn man unsere Anwendung nämlich neu installiert,ohne
die exe.config zu löschen, bringt das nix, dann bleibt nämlich die
vorhandene .exe.config erhalten.

Grüße

- Michael -

Hallo Michael,

> Eine eigene Form wollen wir nur ungern machen. Das wäre nämlich
> extra eine eigene Anwendung nur für die Administratoren (unsere
> Hauptapplikation läuft ohne Admin-Rechte und kann daher die
> .exe.config nicht schreiben), und die exe.config muss nach der
> Installation auch nur selten geändert werden. Da steht der Aufwand
> bei uns nicht im Verhältnis zum Nutzen. Und dann setzen die Admins
> die Anwendung evtl. gar nicht ein, sondern editieren die Datei
> trotzdem von Hand. Ich hatte gehofft, man hätte mit wenig Aufwand
> einfach eine Meldung
>
> "Die Datei ...exe.config ist beschädigt. Löschen Sie diese und
> führen Sie eine Reparaturinstallation durch."
>
> erzeugen können - wenn man unsere Anwendung nämlich neu
> installiert,ohne die exe.config zu löschen, bringt das nix, dann
> bleibt nämlich die vorhandene .exe.config erhalten.

Das sieht mir nach einem Szenario aus, bei dem eine
Administration/Konfiguration über Gruppenrichtlinien (GPO) die
passende Lösung wäre.

Siehe z.B.:
http://www.msxfaq.net/verschiedenes/gpo.htm
-> Abschnitt: GPOs für Entwickler -> GPO mit .NET (ziemlich weit unten
in dem Artikel)


Viele Grüße

Harald M. Genauck

"VISUAL STUDIO one" - http://www.visualstudio1.de (Chefredakteur)
"ABOUT Visual Basic" - http://www.aboutvb.de (Hrsg. + Redaktion)

Hallo Harald,
>> erzeugen können - wenn man unsere Anwendung nämlich neu
>> installiert,ohne die exe.config zu löschen, bringt das nix, dann
>> bleibt nämlich die vorhandene .exe.config erhalten.
>
> Das sieht mir nach einem Szenario aus, bei dem eine
> Administration/Konfiguration über Gruppenrichtlinien (GPO) die passende
> Lösung wäre.

unsere Anwendung wird von verschiedenen Kunden in recht
unterschiedlichen Szenarien eingesetzt. Einige davon verwenden
Gruppenrichtlinien, einige nicht. Bei einigen installieren sich die
Anwender ihre Software selber, bei einigen läuft's über eine separate
Abteilung für Systemadministration. Wir legen daher sehr großen Wert auf
Fehlermeldungen in der Applikation, die den Anwender oder den Admin
nicht "in die Wüste" schicken, weil wir sonst die Kunden unnötig an der
Hotline haben.


Grüße

- Michael -

Hallo Michael,

>> BTW: Ich kenne da auch ein paar andere Meldungen,
>> die kommen könnten, die Du dann auch *alle* abfangen
>> müsstest.
>> Es ist deswegen für meine Begriffe besser, die
>> Konfiguration sauber über eine Windows-Form vom
>> Programm führen zu lassen, sodass keine Fehler
>> dadurch entstehen können, dass jemand in einer
>> XML-Datei was falsch eingibt.
>
> erst mal vielen Dank.

gern.


> Wenn dir schon nichts anderes einfällt, scheint es wahrscheinlich wirklich
> keine bessere Lösung zu geben :-)

die von mir vorgeschlagene ist IMHO eine sehr empfehlenswerte,
evtl. formulierst Du das so, weil Du denkst, die Admins könnten
dann trotzdem in der config herumfuhrwerken.
Nun, Du brauchst nicht unbedingt eine "app.exe.config".
Du kannst sie löschen (sie ist ja letztlich nur ein Fallback, den
Du in ähnlicher Form über das DefaultSettingValueAttribute
bestimmen kannst).
Du kannst die Settings ja alle als UserSettings halten.
In der Form selber kannst Du abfragen, ob der Benutzer
Administrator ist und ggf. dementsprechend angepasste
Einstellungs-Dialoge anzeigen.


> Eine eigene Form wollen wir nur ungern machen. Das wäre nämlich extra eine
> eigene Anwendung nur für die Administratoren

nein, das kann die gleiche sein. (s.o.)


> (unsere Hauptapplikation läuft ohne Admin-Rechte

best practice - Standard


> Da steht der Aufwand bei uns nicht im Verhältnis zum Nutzen. Und dann
> setzen die Admins die Anwendung evtl. gar nicht ein, sondern editieren die
> Datei trotzdem von Hand. Ich hatte gehofft, man hätte mit wenig Aufwand
> einfach eine Meldung

zum einen, es ist nicht wirklich Aufwand zu nennen, wenn Du
Dir mal die Konfigurations-Artikel von meiner Webseite anschaust.
Man kann das perfekt und einfach ans PropertyGrid binden.
Gut, der Umweg über eine eigene Einstellungs-Klasse ist da,
aber auch nicht wirklich Aufwand zu nennen.
Dazu hat man eben die Möglichkeit der Erklärung der
Einstellungen, sodass weniger Konfigurationsfehler durch
Verständnisschwierigkeiten erzeugt werden - neben der
Möglichkeit von Vorschlag-ComboBoxen etc. und der Verhinderung
von Falscheingaben durch Validierung oder begrenzte Auswählbarkeit.
Zum anderen hängen die Admins ggf. trotzdem an Eurer
Hotline, wenn sie die von Dir gewünschte "config" Meldung
bekommen, weil sie gerne wissen wollen, wie man das richtig
im XML formatiert ... und was das bedeutet ;-)


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET

Hallo zusammen,

nach den Antworten hier im Forum denke ich, dass es keinen wirklich
einfachen Weg gibt, die Meldung/Execption bzgl. der App.config im direkt
im zugehörigen Programm abzufangen. Franks Vorschläge funktionieren
sicher recht gut in anderen Szenarien, bei uns klappt das leider so
nicht (will ich aber im Einzelnen jetzt nicht weiter darauf eingehen).

Der Vollständigkeit halber vielleicht hier noch die zwei möglichen
Lösungen, die ich jetzt für uns sehe:

a) wir nennen die Konfigurationsdatei nicht <Anwendung>.exe.config,
sondern geben ihr einen anderen Namen (Aufwand zur Umstellung der
Zugriffe ist minimal). In unserem Fall geht das, da wir gerade ein
Major-Release vorbereiten, bei dem diese Konfigurationsdatei mehrere
alte Ini-Dateien ablöst.

b) Oder wir sorgen dafür, dass unsere Setup-Routine bei einer bereits
vorhandenen Config-Datei im Zielverzeichnis deren Integrität prüft, und
ggf. auf Nachfrage das Original wiederherstellt. Dann führt die Meldung
auch nicht mehr in die Irre.

Grüße

- Michael -