app.config dla biblioteki klas

Nie widzę pliku app.config wygenerowanego dla biblioteki klas przez kreatora VS2008. W moich badaniach odkryłem, że w aplikacji istnieje tylko jeden plik app.config.

Czy ręczne dodawanie pliku app.config do biblioteki klas jest złą rzeczą, czy też istnieją inne metody, które będą służyć jako plik app.config w bibliotece klas?

Muszę przechowywać informacje konfiguracyjne log4net w pliku app.config.

Generalnie nie należy dodawać app.configpliku do projektu biblioteki klas; nie będzie używany bez bolesnego zginania i skręcania z twojej strony. W ogóle nie szkodzi projektowi biblioteki - po prostu nic nie da.

Zamiast tego konfigurujesz aplikację, która korzysta z Twojej biblioteki; więc wymagane informacje o konfiguracji będą tam trafiać. Każda aplikacja, która może korzystać z Twojej biblioteki, prawdopodobnie będzie miała inne wymagania, więc ma to również sens.

Nie wiem, dlaczego ta odpowiedź nie została jeszcze udzielona:

Różni wywołujący z tej samej biblioteki będą na ogół używać różnych konfiguracji. Oznacza to, że konfiguracja musi znajdować się w aplikacji wykonywalnej , a nie w bibliotece klas.

Możesz utworzyć plik app.config w ramach projektu biblioteki klas. Będzie zawierać domyślne konfiguracje dla elementów tworzonych w bibliotece. Na przykład będzie zawierał parametry połączenia, jeśli utworzysz model Entity Framework w bibliotece klas.

Jednak te ustawienia nie będą używane przez aplikację wykonywalną wywołującą bibliotekę. Zamiast tego te ustawienia można skopiować z pliku library.dll.config do pliku app.config lub web.config wywołującego, aby można je było zmienić tak, aby były specyficzne dla dzwoniącego i środowiska, w którym dzwoniący jest rozmieszczony.

Tak jest z .NET od pierwszego dnia.

Jon, wydano wiele opinii, które nie były poprawną odpowiedzią na twoje pytanie.

Przekażę MOJĄ OPINIĘ, a następnie powiem ci, jak zrobić dokładnie to, o co prosiłeś.

Nie widzę powodu, dla którego zespół nie mógłby mieć własnego pliku konfiguracyjnego. Dlaczego pierwszy poziom atomicy (czy to prawdziwe słowo?) Znajduje się na poziomie aplikacji? Dlaczego nie na poziomie rozwiązania? To arbitralna decyzja oparta na najlepszym przypuszczeniu i jako taka OPINIA. Jeśli miałbyś napisać bibliotekę rejestrowania i chciałbyś dołączyć do niej plik konfiguracyjny, który byłby używany globalnie, dlaczego nie mógłbyś podłączyć się do wbudowanej funkcji ustawień? Wszyscy to zrobiliśmy ... próbowaliśmy zapewnić „potężną” funkcjonalność innym programistom. W jaki sposób? Przyjmując założenia, które nieodłącznie przekładają się na ograniczenia. To jest dokładnie to, co MS zrobił z frameworkiem ustawień, więc musisz trochę "oszukać".

Aby bezpośrednio odpowiedzieć na pytanie, po prostu dodaj ręcznie plik konfiguracyjny (xml) i nazwij go tak, aby pasował do Twojej biblioteki i zawierał rozszerzenie „config”. Przykład:

MyDomain.Mylibrary.dll.Config

Następnie użyj menedżera konfiguracji, aby załadować plik i uzyskać dostęp do ustawień:

string assemblyPath = new Uri(Assembly.GetExecutingAssembly().CodeBase).AbsolutePath;
Configuration cfg = ConfigurationManager.OpenExeConfiguration(assemblyPath);
string result = cfg.AppSettings.Settings["TEST_SETTING"].Value;

Zauważ, że to w pełni obsługuje heierarchię machine.config, nawet jeśli jawnie wybrałeś plik konfiguracyjny aplikacji. Innymi słowy, jeśli ustawienia nie ma, rozwiąże to wyżej. Ustawienia zastąpią również wpisy machine.config.

W rzeczywistości implementowana biblioteka klas pobiera informacje z app.config wewnątrz aplikacji, która je zużywa, więc najbardziej poprawnym sposobem implementacji konfiguracji dla bibliotek klas w .net w VS jest przygotowanie pliku app.config w aplikacja do konfigurowania wszystkiego, co zużywa, na przykład konfiguracja bibliotek.

Pracowałem trochę z log4net i odkryłem, że ten, który przygotował aplikację, zawsze miał sekcję konfiguracji log4net w głównym pliku app.config .

Mam nadzieję, że te informacje były przydatne.

Do zobaczenia i opublikuj komentarze na temat znalezionego rozwiązania.

EDYTOWAĆ:

W następnym linku masz plik app.config z sekcją dla log4net:

http://weblogs.asp.net/tgraham/archive/2007/03/15/a-realistic-log4net-config.aspx

Jeśli chcesz skonfigurować rejestrowanie projektu za pomocą log4Net, korzystając z biblioteki klas, nie ma potrzeby posiadania żadnego pliku konfiguracyjnego. Możesz skonfigurować swój rejestrator log4net w klasie i używać tej klasy jako biblioteki.

Ponieważ log4net zapewnia wszystkie opcje konfiguracji.

Proszę znaleźć kod poniżej.

public static void SetLogger(string pathName, string pattern)
        {
            Hierarchy hierarchy = (Hierarchy)LogManager.GetRepository();

            PatternLayout patternLayout = new PatternLayout();
            patternLayout.ConversionPattern = pattern;
            patternLayout.ActivateOptions();

            RollingFileAppender roller = new RollingFileAppender();
            roller.AppendToFile = false;
            roller.File = pathName;
            roller.Layout = patternLayout;
            roller.MaxSizeRollBackups = 5;
            roller.MaximumFileSize = "1GB";
            roller.RollingStyle = RollingFileAppender.RollingMode.Size;
            roller.StaticLogFileName = true;
            roller.ActivateOptions();
            hierarchy.Root.AddAppender(roller);

            MemoryAppender memory = new MemoryAppender();
            memory.ActivateOptions();
            hierarchy.Root.AddAppender(memory);

            hierarchy.Root.Level = log4net.Core.Level.Info;
            hierarchy.Configured = true;
      }

Teraz zamiast wywoływać XmlConfigurator.Configure (new FileInfo ("app.config")) możesz bezpośrednio wywołać SetLogger z żądaną ścieżką i wzorcem, aby ustawić rejestrator w funkcji uruchamiania aplikacji Global.asax.

I użyj poniższego kodu, aby zarejestrować błąd.

        public static void getLog(string className, string message)
        {
            log4net.ILog iLOG = LogManager.GetLogger(className);
            iLOG.Error(message);    // Info, Fatal, Warn, Debug
        }

Używając poniższego kodu, nie musisz pisać ani jednej linii ani w aplikacji web.config, ani w app.config biblioteki.

Właściwie w rzadkich przypadkach można przechowywać plik app.config w bibliotekach klas (dodając go ręcznie) i przeanalizować go przez OpenExeConfiguration .

 var fileMap =
    new ExeConfigurationFileMap {ExeConfigFilename = 
    @"C:\..somePath..\someName.config"};
 System.Configuration.Configuration config =
    ConfigurationManager.OpenMappedExeConfiguration(fileMap, 
    ConfigurationUserLevel.None);

Naprawdę powinieneś oszacować rzeczywistą potrzebę tego. W przypadku danych abstrakcyjnych nie jest to najlepsze rozwiązanie, ale „Sekcje konfiguracyjne” mogą być bardzo przydatne !!

Na przykład zorganizowaliśmy naszą niezależną architekturę WCF N-Tier, bez żadnych metadanych, po prostu za pomocą Unity Container i Injection Factory w oparciu o Channel Factory T. Dodaliśmy zewnętrzną bibliotekę DLL ClassLibrary z interfejsami [Service Contract] i wspólną konfiguracją app.config w kolejności czytać punkty końcowe z sekcji klientów i łatwo dodawać / zmieniać je w jednym miejscu.

Chcesz dodać App.config do swojej biblioteki klas testów , jeśli używasz śledzenia / rejestratora. W przeciwnym razie nic nie zostanie zarejestrowane po uruchomieniu testu za pomocą programu uruchamiającego testy, takiego jak TestDriven.Net.

Na przykład używam TraceSourcew moich programach, ale uruchamianie testów nie rejestruje niczego, chyba że dodam plik App.config z konfiguracją śledzenia / dziennika również do biblioteki klas testowych.

W przeciwnym razie dodanie App.config do biblioteki klas nic nie da.

Odpowiedzią na nie ręczne tworzenie pliku app.config jest karta Właściwości / Ustawienia projektu programu Visual Studio.

Gdy dodasz ustawienie i zapiszesz, plik app.config zostanie utworzony automatycznie. W tym momencie część kodu jest generowana w przestrzeni nazw { yourclasslibrary .Properties} zawierającej właściwości odpowiadające Twoim ustawieniom. Same ustawienia zostaną umieszczone w ustawieniach applicationSettings pliku app.config.

 <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
        <section name="ClassLibrary.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    </sectionGroup>
</configSections>
<applicationSettings>
    <ClassLibrary.Properties.Settings>
        <setting name="Setting1" serializeAs="String">
            <value>3</value>
        </setting>
    </BookOneGenerator.Properties.Settings>
</applicationSettings>

Jeśli dodano ustawienie w zakresie aplikacji o nazwie Setting1 = 3, zostanie utworzona właściwość o nazwie Setting1. Te właściwości stają się częścią kompilacji pliku binarnego i są ozdobione DefaultSettingValueAttribute, który jest ustawiony na wartość określoną w czasie projektowania.

     [ApplicationScopedSetting]
    [DebuggerNonUserCode]
    [DefaultSettingValue("3")]
    public string Setting1
    {
        get
        {
            return (string)this["Setting1"];
        }
    }

Tak więc, tak jak w kodzie biblioteki klas, używasz tych właściwości, jeśli odpowiednie ustawienie nie istnieje w pliku konfiguracyjnym środowiska uruchomieniowego, zostanie zastosowana wartość domyślna. W ten sposób aplikacja nie ulegnie awarii z powodu braku wpisu ustawień, co jest bardzo mylące za pierwszym razem, gdy nie wiesz, jak te rzeczy działają. Teraz zadajesz sobie pytanie, w jaki sposób można określić naszą własną nową wartość we wdrożonej bibliotece i uniknąć użycia domyślnej wartości ustawienia?

Stanie się tak, gdy odpowiednio skonfigurujemy plik app.config. Dwa kroki. 1. informujemy, że będziemy mieć sekcję ustawień dla tej biblioteki klas i 2. z niewielkimi modyfikacjami wklejamy plik konfiguracyjny biblioteki klas do wykonywalnej konfiguracji. (istnieje metoda, w której możesz zachować zewnętrzny plik konfiguracyjny biblioteki klas i po prostu odwołać się do niego z pliku config.

Możesz więc mieć plik app.config dla biblioteki klas, ale jest on bezużyteczny, jeśli nie zintegrujesz go poprawnie z aplikacją nadrzędną. Zobacz, co kiedyś napisałem: link

Po dodaniu projektu biblioteki klas do rozwiązania nie ma automatycznego dodawania pliku app.config.

O ile mi wiadomo, nie ma przeciwwskazań dotyczących robienia tego ręcznie. Myślę, że to powszechne użycie.

Jeśli chodzi o konfigurację log4Net, nie musisz umieszczać konfiguracji w app.config, możesz mieć dedykowany plik conf w swoim projekcie, a także plik app.config w tym samym czasie.

ten link http://logging.apache.org/log4net/release/manual/configuration.html zawiera przykłady dotyczące obu sposobów (sekcja w app.config i samodzielny plik konfiguracyjny log4net)

Polecam użycie Properties.Settings do przechowywania wartości, takich jak ConnectionStrings i tak dalej, w bibliotece klas. Jest to miejsce, w którym wszystkie parametry połączenia są przechowywane na podstawie sugestii z programu Visual Studio, na przykład podczas próby dodania adaptera tabeli. wprowadź opis obrazu tutaj

A potem będą dostępne za pomocą tego kodu w każdym miejscu w bibliotece clas

var cs=  Properties.Settings.Default.[<name of defined setting>];