Zitat von
Jürgen Thomas:
Alles, was Du mir zum Bereich <system.data> und der Einbindung des FirebirdClient geschrieben hast, ist klar; es handelt sich ja in der Tat 'nur' um das Verschieben von machine.config nach app.config.
Genau!
Zitat:
Mit #D kann ich in den Projektoptionen keine Settings direkt einstellen.
Schaue dir mal C# Express an. Du kannst dort die gleichen Projektdateien wie in #D öffnen, aber du hast ebenfalls solche netten Spielereien wie das autom. Generieren einer Wrapperklasse für deine Settings.
Zitat:
Du registrierst eine sectionGroup "applicationSettings", die NET-Doku verwendet immer "appSettings". Ist das nur ein Unterschied in der Schreibweise oder ein wirklicher Unterschied?
Ist vom VS so generiert, aber ich kann die Section in meiner App.config auch als Hallo.Du.Da deklarieren. Wichtig ist nur, dass jeder Section/SectionGroup der richtige Handlerzugewisen wird.
Zitat:
In Deinem C#-Quellcode schreibst Du:
Code:
... Settings.Default.DefaultProviderName ...
'Settings' finde ich in der NET-Doku nur als AppSettingsSection-Eigenschaft, auf die z.B. über ConfigurationManager.AppSettings zugegriffen werden kann; 'Default' finde ich überhaupt nicht in diesem Zusammenhang.
Diese Settings werden als key-value-Collection angegeben, während Dein DefaultProviderName über name-value arbeitet; auch das kann ich nicht miteinander verbinden.
Wie gesagt, das VS generiert automatisch eine Wrapperklasse für die definierten Settings.
Zitat:
Kannst Du mir vielleicht noch einen Code-Schnipsel nennen mit vollständigen Angaben von Namespace, Klassen und Eigenschaften, mit denen ich zunächst sicherstellen kann, dass ich den richtigen String erhalte?
Code:
// der invariantName den du dem Provider verpasst hast
// ich nahm den hier:
DbProviderFactory factory = DbProviderFactories.GetFactory("FirebirdSql.Data.FirebirdClient");
using (IDbConnection connection = factory.CreateConnection())
{
Console.WriteLine(connection);
}
Zitat:
Nachtrag zur FirebirdClientFactory: Welche Information habe ich überlesen, dass dies eine Singleton-Klasse ist? Hätte mich vor allem die Eigenschaft 'Instance' darauf hinweisen sollen?
Genau. Ob du es Singleton nennst oder wie auch immer. Ein privater Konstruktor und ein statisches Feld, das die einzige Instanz hält, sieht für mich sehr danach aus.
Zitat:
Hier teile ich Deine Einschätzung, dass dies als Singleton eher Quatsch ist: Für mehrere DBs benutzt man doch wohl auch mehrere Instanzen von DbProviderFactory, oder?
Die Klasse hat keine Felder pro Instanz. Ein Singleton zu haben hat hier
IMHO keinen wirklichen Vorteil. Selbst der gesparte Speicherplatz ist komplett vernachlässigbar, aber die statische Instanz macht das Laden und Entladen der Assembly durch eine AppDomain teurer als es sein müsste.
Diese Macke haben alle DbProviderFactories, vllt werden sie irgendwo über Referenzen verglichen. Keine Ahnung, wirklich...
