EntLib und Interop: es funktioniert, und wo die Konfigurationsdatei gehen?

Question

Ich versuche, die EntLib 3.1 innerhalb .net-Code für eine DLL zu verwenden, die für COM-Interop registriert ist. Wo setze ich die Config-Datei?

Alternativ ist es eine Möglichkeit, innerhalb des DLL-Code angeben, wo sie die EntLib config bekommen sollten? Da meine dll wird von COM aufgerufen werden, weiß ich nicht immer, was exe es nennen wird.

Ich habe eine einfache Anwendung, die EntLib Logging verwendet, mit zwei Klassen: ‚CallingApp‘ und ‚MyComThing‘. Wenn ich ein Verfahren zur Herstellung von MyComThing CallingApp Ruflisten es die Konfiguration in CallingApp config-Datei. Wenn ich die Methode von MyComThing von einem vbs Skript aufrufen, dh durch COM, erhalte ich eine Fehlermeldung „Der Konfigurationsabschnitt für Logging nicht in der Konfigurationsquelle gefunden werden kann“. Meine COMThing.dll.config Datei im selben Ordner wie die registrierten COMThing.dll, dh in der bin \ debug \ Ordner.

Danke!

Answer 1

Die Antwort ist, dass Enterprise Library standardmäßig die Konfigurationsdatei exe verwendet. Wenn Sie eine DLL sind Herstellung, einschließlich COM, dann aus gutem Grund können Sie nicht auf dem anrufenden ausführbaren abhängen wollen. Eine Lösung für diese (möglicherweise gibt es andere sein) ist die Enterprise Library zum Erstellen von Objekten selbst, anstatt die Standardeinstellungen verwenden, und ihnen sagen, wo die Konfiguration von bekommen. Dies ist nicht so gefährlich, wie es scheint, und erfordert keine EntLib oder so etwas neu zu kompilieren.

Statt einfach mit Logger.Write () Ich habe folgende Möglichkeiten: Erstellen Sie a) den Log-Writer, mit der Config-Datei DLL:

        string dllConfigFilename = Assembly.GetExecutingAssembly().Location + ".config";
        FileConfigurationSource exceptionsSource = new FileConfigurationSource(dllConfigFilename);
        LogWriterFactory writerFactory = new LogWriterFactory(exceptionsSource);
        logWriter = writerFactory.Create();

b) Verwenden Sie dann diese Protokollschreiber im Code:

        LogEntry log = new LogEntry();
        log.Message = message;
        log.Categories = new string[] { "General" };
        logWriter.Write(log);

Hier ist der vollständige Code für ein Musterobjekt I erstellt. Die Referenzen waren Microsoft.Practices.EnterpriseLibrary.Common, Microsoft.Practices.EnterpriseLibrary.Logging, Microsoft.Practices.ObjectBuilder, System, System.Data, System.Windows.Forms, System.XML:

using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.InteropServices;
using System.Windows.Forms;
using System.Reflection;
using System.IO;
using Microsoft.Practices.EnterpriseLibrary.Logging;
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;

namespace COMThing
{
    [ComVisible(true)]
    public class MyComThing : MyComInterface
    {
        LogWriter logWriter; 

        public MyComThing()
        {
            string dllConfigFilename = Assembly.GetExecutingAssembly().Location + ".config";
            FileConfigurationSource exceptionsSource = new FileConfigurationSource(dllConfigFilename);
            LogWriterFactory writerFactory = new LogWriterFactory(exceptionsSource);
            logWriter = writerFactory.Create();
        }

        public bool ProcessMessage(string message)
        {
            LogEntry log = new LogEntry();
            log.Message = message;
            log.Categories = new string[] { "General" };
            logWriter.Write(log);
            MessageBox.Show(message);
            return true;
        }
    }

}

Das Projekt umfasste eine COMThing.dll.config Datei, die i ‚kopiert Ausgabeverzeichnis‘ auf ‚Copy immer‘. Dies ist eine triviale Config, die Informationen an das Anwendungsereignisprotokoll schreibt anmelden. Der Inhalt der Konfigurationsdatei ist:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <section name="loggingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings, Microsoft.Practices.EnterpriseLibrary.Logging, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
    <section name="dataConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DatabaseSettings, Microsoft.Practices.EnterpriseLibrary.Data, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
  </configSections>
  <loggingConfiguration name="Logging Application Block" tracingEnabled="true"
    defaultCategory="General" logWarningsWhenNoCategoriesMatch="true">
    <listeners>
      <add source="COMThing Logger" formatter="Text Formatter" log="Application"
        machineName="" listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.FormattedEventLogTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
        traceOutputOptions="None" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.FormattedEventLogTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
        name="Formatted EventLog TraceListener" />
    </listeners>
    <formatters>
      <add template="Timestamp: {timestamp}&#xD;&#xA;Message: {message}&#xD;&#xA;Category: {category}&#xD;&#xA;Priority: {priority}&#xD;&#xA;EventId: {eventid}&#xD;&#xA;Severity: {severity}&#xD;&#xA;Title:{title}&#xD;&#xA;Machine: {machine}&#xD;&#xA;Application Domain: {appDomain}&#xD;&#xA;Process Id: {processId}&#xD;&#xA;Process Name: {processName}&#xD;&#xA;Win32 Thread Id: {win32ThreadId}&#xD;&#xA;Thread Name: {threadName}&#xD;&#xA;Extended Properties: {dictionary({key} - {value}&#xD;&#xA;)}"
        type="Microsoft.Practices.EnterpriseLibrary.Logging.Formatters.TextFormatter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
        name="Text Formatter" />
    </formatters>
    <categorySources>
      <add switchValue="All" name="General">
        <listeners>
          <add name="Formatted EventLog TraceListener" />
        </listeners>
      </add>
    </categorySources>
    <specialSources>
      <allEvents switchValue="All" name="All Events">
        <listeners>
          <add name="Formatted EventLog TraceListener" />
        </listeners>
      </allEvents>
      <notProcessed switchValue="All" name="Unprocessed Category" />
      <errors switchValue="All" name="Logging Errors &amp; Warnings">
        <listeners>
          <add name="Formatted EventLog TraceListener" />
        </listeners>
      </errors>
    </specialSources>
  </loggingConfiguration>
</configuration>

In den Projekteigenschaften unter Übersetzungsprüfung ‚für COM-Interop registrieren‘. Erstellen Sie das Projekt, erstellen Sie die folgende VBS-Datei:

Set obj = CreateObject("COMThing.MyComThing")
obj.ProcessMessage("called from com by vbs")

Wenn Sie einen Doppelklick auf dieser Datei vbs sollte es ein Meldungsfeld mit dem Text ‚von com von vbs genannten‘ zeigen und einen Beitrag für Ihr Anwendungsereignisprotokoll schreiben. Dies zeigt, dass während der Ausführung Prozess ist. C: \ WINDOWS \ System32 \ WScript.exe (oder ähnlich), es ist die Config aus dem DLL-Konfigurationsdatei bekommen

I basierte dies auf den Informationen hier unter ‚Verwendung mehrerer ConfigurationSources‘.

Beachten Sie, dass der Logger-Klasse viele nette Helfer Methoden mit verschiedenen Argumenten enthält. Da wir die LogWriter Klasse verwenden bekommen wir nicht diese Magie. Persönlich werde ich eine andere Klasse in meiner Bibliothek erschaffen die gleiche Arbeit auszuführen, basierend auf Logger.

Der zitierte Artikel zeigt das gleiche Prinzip angewandt Datenbank und Exception-Applikationsbausteine. Vermutlich kann das gleiche Modell für die meisten / alle von ihnen angewendet werden.

Answer 2

Überprüfen Sie die damit zusammenhängende Frage, die ich gestellt hatte. Vielleicht ist es eine Hilfe.

Wie COM-Komponenten auf einem veröffentlichten aufzunehmen. Net Website?