C # DLL-Konfigurationsdatei

Ich versuche, meiner DLL eine app.config-Datei hinzuzufügen, aber alle Versuche sind fehlgeschlagen.

Laut MusicGenesis unter " Konfigurationsinformationen in eine DLL einfügen" sollte dies kein Problem sein. Also mache ich offensichtlich etwas falsch ...

Der folgende Code sollte meinen ConnectionString von meiner DLL zurückgeben:

return ConfigurationManager.AppSettings["ConnectionString"];

Wenn ich jedoch die Datei app.config in meine Konsolenanwendung kopiere, funktioniert dies einwandfrei.

Irgendwelche Ideen?

Es ist aus gutem Grund nicht trivial, eine .NET-Konfigurationsdatei für eine DLL zu erstellen. Der .NET-Konfigurationsmechanismus verfügt über zahlreiche integrierte Funktionen, die das einfache Aktualisieren / Aktualisieren der App erleichtern und die installierten Apps vor dem gegenseitigen Trampeln der Konfigurationsdateien schützen.

Es gibt einen großen Unterschied zwischen der Verwendung einer DLL und der Verwendung einer Anwendung. Es ist unwahrscheinlich, dass mehrere Kopien einer Anwendung für denselben Benutzer auf demselben Computer installiert sind. Möglicherweise verfügen Sie jedoch über 100 verschiedene Apps oder Bibliotheken, die alle eine .NET-DLL verwenden.

Während es selten erforderlich ist, Einstellungen für verschiedene Kopien einer App innerhalb eines Benutzerprofils separat zu verfolgen, ist es sehr unwahrscheinlich, dass alle unterschiedlichen Verwendungen einer DLL die Konfiguration miteinander teilen sollen. Aus diesem Grund ist das Objekt, das Sie zurückerhalten, beim Abrufen eines Konfigurationsobjekts mit der "normalen" Methode an die Konfiguration der App-Domäne gebunden, in der Sie ausgeführt werden, und nicht an die bestimmte Assembly.

Die App-Domäne ist an die Root-Assembly gebunden, die die Assembly geladen hat, in der sich Ihr Code tatsächlich befindet. In den meisten Fällen ist dies die Assembly Ihrer Haupt-EXE-Datei, die die DLL geladen hat. Es ist möglich, andere App-Domänen innerhalb einer Anwendung zu starten, Sie müssen jedoch explizit Informationen zur Stammassemblierung dieser App-Domäne bereitstellen.

Aus diesem Grund ist das Verfahren zum Erstellen einer bibliotheksspezifischen Konfigurationsdatei nicht so bequem. Dies ist der gleiche Prozess, den Sie zum Erstellen einer beliebigen tragbaren Konfigurationsdatei verwenden würden, die nicht an eine bestimmte Assembly gebunden ist, für die Sie jedoch das XML-Schema, den Konfigurationsabschnitt und die Konfigurationselementmechanismen von .NET usw. verwenden möchten. Dazu müssen Sie ein ExeConfigurationFileMapObjekt erstellen Laden Sie die Daten, um festzustellen, wo die Konfigurationsdatei gespeichert wird, und rufen Sie dann aufConfigurationManager . OpenMappedExeConfigurationum es in eine neue ConfigurationInstanz zu öffnen . Dadurch werden Sie vom Versionsschutz abgeschnitten, den der automatische Pfadgenerierungsmechanismus bietet.

Statistisch gesehen verwenden Sie diese Bibliothek wahrscheinlich in einer internen Umgebung, und es ist unwahrscheinlich, dass Sie mehrere Apps auf einem Computer / Benutzer verwenden. Aber wenn nicht, gibt es etwas , das man im Auge behalten sollte. Wenn Sie eine einzelne globale Konfigurationsdatei für Ihre DLL verwenden, müssen Sie sich unabhängig von der App, auf die sie verweist, über Zugriffskonflikte Gedanken machen. Wenn zwei Apps, die auf Ihre Bibliothek verweisen, gleichzeitig ausgeführt werden und jeweils ein eigenes ConfigurationObjekt geöffnet ist, wird beim Speichern von Änderungen beim nächsten Versuch, Daten in der anderen App abzurufen oder zu speichern, eine Ausnahme ausgelöst.

Der sicherste und einfachste Weg, dies zu umgehen, besteht darin, zu verlangen, dass die Assembly, die Ihre DLL lädt, auch einige Informationen über sich selbst bereitstellt, oder diese zu erkennen, indem Sie die App-Domäne der referenzierenden Assembly untersuchen. Verwenden Sie diese Option, um eine Art Ordnerstruktur zu erstellen, in der separate Benutzerkonfigurationsdateien für jede App gespeichert werden, die auf Ihre DLL verweist.

Wenn Sie sicher sind , dass Sie globale Einstellungen für Ihre DLL haben möchten, unabhängig davon, wo auf sie verwiesen wird, müssen Sie Ihren Speicherort dafür bestimmen, anstatt .NET automatisch einen geeigneten zu ermitteln. Sie müssen auch aggressiv bei der Verwaltung des Zugriffs auf die Datei sein. Sie müssen so viel wie möglich zwischenspeichern und die ConfigurationInstanz NUR so lange behalten, wie sie zum Laden oder Speichern benötigt wird. Sie muss unmittelbar vor und sofort nach dem Öffnen geöffnet werden. Und schließlich benötigen Sie einen Sperrmechanismus, um die Datei zu schützen, während sie von einer der Apps bearbeitet wird, die die Bibliothek verwenden.

Wenn Sie Einstellungen aus der Konfigurationsdatei der DLL lesen möchten, jedoch nicht aus den Stammanwendungen web.config oder app.config, verwenden Sie den folgenden Code, um die Konfiguration in der DLL zu lesen.

var appConfig = ConfigurationManager.OpenExeConfiguration(Assembly.GetExecutingAssembly().Location);
string dllConfigData = appConfig.AppSettings.Settings["dllConfigData"].Value;

Ich hatte das gleiche Problem und suchte mehrere Stunden im Internet, konnte aber keine Lösung finden, also machte ich meine eigene. Ich habe mich gefragt, warum das .net-Konfigurationssystem so unflexibel ist.

Hintergrund: Ich möchte, dass meine DAL.dll eine eigene Konfigurationsdatei für Datenbank- und DAL-Einstellungen hat. Ich benötige auch die app.config für Enterprise Library und ihre eigenen Konfigurationen. Ich brauche also sowohl die app.config als auch die dll.config.

Was ich nicht wollte, ist, jede Eigenschaft / Einstellung von der App an meine DAL-Ebene weiterzuleiten!

Das Biegen der "AppDomain.CurrentDomain.SetupInformation.ConfigurationFile" ist nicht möglich, da ich sie für das normale Verhalten von app.config benötige.

Meine Anforderungen / Standpunkte waren:

• KEINE manuelle Kopie von ClassLibrary1.dll.config nach WindowsFormsApplication1.exe.config, da dies für andere Entwickler nicht reproduzierbar ist.
• Behalten Sie die Verwendung der starken Eingabe "Properties.Settings.Default.NameOfValue" (Einstellungsverhalten) bei, da ich denke, dass dies eine wichtige Funktion ist und ich sie nicht verlieren wollte
• Ich habe festgestellt, dass ApplicationSettingsBase nicht vorhanden ist, um Ihre eigene / benutzerdefinierte Konfigurationsdatei oder Verwaltung einzufügen (alle erforderlichen Felder sind in diesen Klassen privat).
• Die Verwendung der Dateiumleitung "configSource" ist nicht möglich, da wir die ClassLibrary1.dll.config kopieren / neu schreiben und mehrere XML-Dateien für mehrere Abschnitte bereitstellen müssten (das hat mir auch nicht gefallen).
• Ich wollte nicht meinen eigenen SettingsProvider für diese einfache Aufgabe schreiben, wie MSDN vorschlägt, weil ich dachte, das wäre einfach zu viel
• Ich benötige nur Abschnitte applicationSettings und connectionStrings aus der Konfigurationsdatei

Ich habe die Datei Settings.cs geändert und eine Methode implementiert, die die ClassLibrary1.dll.config öffnet und die Abschnittsinformationen in einem privaten Feld liest. Danach habe ich "this [string propertyName]" überschrieben, damit die generierten Settings.Desginer.cs anstelle der Basisklasse meine neue Eigenschaft aufrufen. Dort wird die Einstellung aus der Liste ausgelesen.

Schließlich gibt es den folgenden Code:

internal sealed partial class Settings
{
    private List<ConfigurationElement> list;

    /// <summary>
    /// Initializes a new instance of the <see cref="Settings"/> class.
    /// </summary>
    public Settings()
    {
        this.OpenAndStoreConfiguration();
    }

    /// <summary>
    /// Opens the dll.config file and reads its sections into a private List of ConfigurationElement.
    /// </summary>
    private void OpenAndStoreConfiguration()
    {
        string codebase = System.Reflection.Assembly.GetExecutingAssembly().CodeBase;
        Uri p = new Uri(codebase);
        string localPath = p.LocalPath;
        string executingFilename = System.IO.Path.GetFileNameWithoutExtension(localPath);
        string sectionGroupName = "applicationSettings";
        string sectionName = executingFilename + ".Properties.Settings";
        string configName = localPath + ".config";
        ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
        fileMap.ExeConfigFilename = configName;
        Configuration config = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);

        // read section of properties
        var sectionGroup = config.GetSectionGroup(sectionGroupName);
        var settingsSection = (ClientSettingsSection)sectionGroup.Sections[sectionName];
        list = settingsSection.Settings.OfType<ConfigurationElement>().ToList();

        // read section of Connectionstrings
        var sections = config.Sections.OfType<ConfigurationSection>();
        var connSection = (from section in sections
                           where section.GetType() == typeof(ConnectionStringsSection)
                           select section).FirstOrDefault() as ConnectionStringsSection;
        if (connSection != null)
        {
            list.AddRange(connSection.ConnectionStrings.Cast<ConfigurationElement>());
        }
    }

    /// <summary>
    /// Gets or sets the <see cref="System.Object"/> with the specified property name.
    /// </summary>
    /// <value></value>
    public override object this[string propertyName]
    {
        get
        {
            var result = (from item in list
                         where Convert.ToString(item.ElementInformation.Properties["name"].Value) == propertyName
                         select item).FirstOrDefault();
            if (result != null)
            {
                if (result.ElementInformation.Type == typeof(ConnectionStringSettings))
                {
                    return result.ElementInformation.Properties["connectionString"].Value;
                }
                else if (result.ElementInformation.Type == typeof(SettingElement))
                {
                    return result.ElementInformation.Properties["value"].Value;
                }
            }
            return null;
        }
        // ignore
        set
        {
            base[propertyName] = value;
        }
    }

Sie müssen lediglich Ihre ClassLibrary1.dll.config aus dem ClassLibrary1-Ausgabeverzeichnis in das Ausgabeverzeichnis Ihrer Anwendung kopieren. Vielleicht findet es jemand nützlich.

Bei Verwendung von ConfigurationManager bin ich mir ziemlich sicher, dass die Prozess- / AppDomainKonfigurationsdatei (app.config / web.config) geladen wird. Wenn Sie eine bestimmte Konfigurationsdatei laden möchten, müssen Sie diese Datei speziell nach ihrem Namen fragen ...

Du könntest es versuchen:

var config = ConfigurationManager.OpenExeConfiguration("foo.dll");
config.ConnectionStrings. [etc]

ConfigurationManager.AppSettings gibt die für die Anwendung definierten Einstellungen zurück, nicht für die spezifische DLL. Sie können darauf zugreifen, aber es werden die Anwendungseinstellungen zurückgegeben.

Wenn Sie Ihre DLL aus einer anderen Anwendung verwenden, befindet sich der ConnectionString in den App-Einstellungen der Anwendung.

Ich weiß, dass dies zu spät für die Party ist, aber ich dachte, ich würde die Lösung, die ich für DLLs verwende, teilen.

Ich bin eher ein KISS-Denker. Wenn ich also eine .NET-DLL habe, die externe Datenpunkte speichern möchte, die steuern, wie es funktioniert oder wohin es geht usw., erstelle ich einfach eine "config" -Klasse, die nur öffentliche Eigenschaften hat das speichert alle Datenpunkte, die es benötigt, und dass ich in der Lage sein möchte, außerhalb der DLL zu steuern, um zu verhindern, dass es neu kompiliert wird, um die Änderungen vorzunehmen. Dann verwende ich die XML-Serialisierung von .Net, um die Objektdarstellung der Klasse zu speichern und in eine Datei zu laden.

Es gibt dann viele Möglichkeiten, es zu lesen und darauf zuzugreifen, von einem Singleton, einer statischen Dienstprogrammklasse bis hin zu Erweiterungsmethoden usw. Dies hängt davon ab, wie Ihre DLL strukturiert ist und welche Methode am besten zu Ihrer DLL passt.

Wenn Sie richtig sind, können Sie die Konfigurationsdatei einer DLL lesen. Ich hatte einen Tag lang damit zu kämpfen, bis ich herausfand, dass meine Konfigurationsdatei das Problem war. Siehe meinen Code unten. es konnte rennen.

        ExeConfigurationFileMap map = new ExeConfigurationFileMap();
        map.ExeConfigFilename = Assembly.GetExecutingAssembly().Location + ".config";
        Configuration libConfig = ConfigurationManager.OpenMappedExeConfiguration(map, ConfigurationUserLevel.None);
        AppSettingsSection section = (libConfig.GetSection("appSettings") as AppSettingsSection);
        Console.WriteLine(section.Settings["dnd_shortcodes"].Value);

mein Plugin1.dll.configsah aus wie unten;

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
 <appSettings>
  <add key="cmd_location" value="http://..."/>
  <add key="dnd_shortcodes" value="142,145,146,157,165,167,168,171,173,176,178,404,40"/>
 </appSettings>
</configuration>

Ich habe herausgefunden, dass in meiner Konfigurationsdatei das <appSettings>Tag fehlt. Schauen Sie sich also um, Ihr Problem hätte anders sein können, aber nicht so weit von meinem entfernt.

Da sich die Assembly in einem temporären Cache befindet, sollten Sie den Pfad kombinieren, um die Konfiguration der DLL abzurufen:

var appConfig = ConfigurationManager.OpenExeConfiguration(
    Path.Combine(Environment.CurrentDirectory, Assembly.GetExecutingAssembly().ManifestModule.Name));

Wenn Sie Bibliotheken verwenden, die hinter den Kulissen eine große Menge an Verwirrung nachschlagen, wie z. B. WCF, sollten Sie Folgendes in Betracht ziehen:

AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", "MyWcfClientWrapper.dll.config");

Oder in PowerShell:

[AppDomain]::CurrentDomain.SetData("APP_CONFIG_FILE", "MyWcfClientWrapper.dll.config")

IMO diese Technik ist ein Code-Geruch und ist wirklich nur für die Verwendung in Ad-hoc-Skripten geeignet. Wenn Sie dies im Produktionscode tun möchten, ist es möglicherweise Zeit für eine Überprüfung der Architektur.

Folgendes wird NICHT empfohlen: Aus
technischen Gründen gibt es hier eine Variation des Themas. Sie können einen statischen Konstruktor in einer der in der DLL enthaltenen Klassen erstellen und diesen Aufruf von dort aus ausführen. Ich würde dies nur als letzten Ausweg empfehlen.

Die vollständige Lösung wird nicht oft an einem Ort gefunden ...

1) Erstellen Sie eine App-Konfigurationsdatei und nennen Sie sie "yourDllName.dll.config".
2) Klicken Sie mit der rechten Maustaste auf die oben im VS Solution Explorer erstellte Konfigurationsdatei und klicken Sie auf Eigenschaften
--- set "Build Action" = Content
--- set "Copy To Output Directory" = Always
3) Fügen Sie der Konfigurationsdatei (yourDllName.dll.config) mit IhremKeyName und IhremKeyValue einen Abschnitt appSettings hinzu

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="yourKeyName" value="yourKeyValue"/>
  </appSettings>
</configuration>

4) Fügen Sie System.Configuration zu Ihren DLL- / Klassen- / Projektreferenzen hinzu.
5) Fügen Sie die using-Anweisungen zu Ihrem Code hinzu, in dem Sie auf die Konfigurationseinstellung zugreifen möchten

using System.Configuration;
using System.Reflection;

6) Um auf den Wert zuzugreifen

string keyValue = ConfigurationManager.OpenExeConfiguration(Assembly.GetExecutingAssembly().Location).AppSettings.Settings["yourKeyName"].Value;

7) freue dich, es funktioniert

IMHO sollte dies nur bei der Entwicklung einer neuen DLL / Bibliothek verwendet werden.

#if (DEBUG && !FINALTESTING)
   string keyValue = ConfigurationManager.OpenExeConfiguration...(see 6 above)
#else
   string keyValue = ConfigurationManager.AppSettings["yourKeyName"];
#endif

Die Konfigurationsdatei ist eine hervorragende Referenz, wenn Sie die appSettings der DLL zu Ihrer eigentlichen Anwendung hinzufügen.

Diese Konfigurationsdateien scheinen wirklich verwirrend zu sein, da sich ihr Verhalten von der Entwicklungsumgebung zur Bereitstellung ändert. Anscheinend kann eine DLL eine eigene Konfigurationsdatei haben, aber sobald Sie die DLL (zusammen mit ihrer Konfigurationsdatei) an eine andere Stelle kopieren und einfügen, funktioniert das Ganze nicht mehr. Die einzige Lösung besteht darin, die app.config-Dateien manuell in einer einzigen Datei zusammenzuführen, die nur von der Exec verwendet wird. Zum Beispiel hat myapp.exe eine myapp.exe.config-Datei, die alle Einstellungen für alle von myapp.exe verwendeten DLLs enthält. Ich benutze VS 2008.

Ich habe eine gute Lösung für dieses Problem gefunden. Ich verwende VS 2008 C #. Meine Lösung beinhaltet die Verwendung unterschiedlicher Namespaces zwischen mehreren Konfigurationsdateien. Ich habe die Lösung in meinem Blog veröffentlicht: http://tommiecarter.blogspot.com/2011/02/how-to-access-multiple-config-files-in.html .

Beispielsweise:

Dieser Namespace liest / schreibt DLL-Einstellungen:

var x = company.dlllibrary.Properties.Settings.Default.SettingName;
company.dlllibrary.Properties.Settings.Default.SettingName = value;

Dieser Namespace liest / schreibt die exe-Einstellungen:

company.exeservice.Properties.Settings.Default.SettingName = value;
var x = company.exeservice.Properties.Settings.Default.SettingName;

Im Artikel werden einige Einschränkungen erwähnt. HTH

Wie Marc sagt, ist dies nicht möglich (obwohl Sie mit Visual Studio eine Anwendungskonfigurationsdatei in ein Klassenbibliotheksprojekt einfügen können).

Vielleicht möchten Sie die AssemblySettings- Klasse überprüfen, die Assembly- Konfigurationsdateien zu ermöglichen scheint.

In diesem Beitrag wurde ein ähnliches Problem besprochen und mein Problem gelöst. Wie lade ich eine separate Anwendungseinstellungsdatei dynamisch und füge sie mit den aktuellen Einstellungen zusammen? könnte helpfu sein

Für eine DLL sollte dies nicht von der Konfiguration abhängen, da die Konfiguration der Anwendung und nicht der DLL gehört.

Dies wird bei erklärt hier

Sie können diesen Code verwenden:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.InteropServices;
using System.Text;
using System.Threading.Tasks;

namespace GClass1
{
[Guid("D6F88E95-8A27-4ae6-B6DE-0542A0FC7039")]
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
public interface _GesGasConnect
{
    [DispId(1)]
    int SetClass1Ver(string version);


}

[Guid("13FE32AD-4BF8-495f-AB4D-6C61BD463EA4")]
[ClassInterface(ClassInterfaceType.None)]
[ProgId("InterfacesSMS.Setting")]
public class Class1 : _Class1
{
    public Class1() { }


    public int SetClass1(string version)
    {
        return (DateTime.Today.Day);
    }
}
}