app.config для бібліотеки класів

Я не бачу файл app.config, створений для бібліотеки класів майстром VS2008. У своєму дослідженні я виявив, що в додатку існує лише одне app.config.

Це погано додавати app.config вручну до бібліотеки класів чи є інші методи, які слугуватимуть цілі app.config у бібліотеці класів?

Мені потрібно зберігати інформацію про конфігурацію log4net у файлі app.config.

Як правило, не слід додавати app.configфайл до проекту бібліотеки класів; він не буде використовуватися без болючого згинання та скручування з вашого боку. Бібліотечному проекту це зовсім не шкодить - воно взагалі нічого не зробить.

Натомість ви налаштовуєте програму, яка використовує вашу бібліотеку; отже, потрібна інформація про конфігурацію буде надходити туди. Кожна програма, яка може використовувати вашу бібліотеку, матиме різні вимоги, тому насправді це теж має логічний сенс.

Не знаю, чому ця відповідь ще не дана:

Взагалі, різні абоненти однієї бібліотеки використовуватимуть різні конфігурації. Це означає, що конфігурація повинна знаходитись у виконуваній програмі, а не в бібліотеці класів.

Ви можете створити app.config в рамках проекту бібліотеки класів. Він міститиме конфігурації за замовчуванням для елементів, які ви створюєте в бібліотеці. Наприклад, він буде містити рядки підключення, якщо ви створите модель Entity Framework у бібліотеці класів.

Однак ці налаштування не будуть використовуватися виконуваною програмою, що викликає бібліотеку. Натомість ці налаштування можна скопіювати з файлу library.dll.config у app.config або web.config абонента, щоб їх можна було змінити, щоб вони були специфічними для абонента та середовища, в яке абонент розгорнуто.

Так було з .NET з 1-го дня.

Джон, було дано багато думок, які не правильно відповіли на ваше запитання.

Я дам СВОЮ ДУМКУ, а потім розповім, як робити саме те, про що ви просили.

Я не бачу причини, чому збірка не могла мати власний файл конфігурації. Чому перший рівень атомічності (це справжнє слово?) Має бути на рівні програми? Чому б не на рівні рішення? Це довільне, найкраще вгадане рішення і, як таке, ДУМКА. Якщо ви хочете написати бібліотеку журналу і хочете включити для неї файл конфігурації, який буде використовуватися у всьому світі, чому б ви не могли підключитись до вбудованої функції налаштувань? Ми всі це зробили ... намагалися надати "потужну" функціональність іншим розробникам. Як? Висловлюючи припущення, що по суті перекладаються на обмеження. Це саме те, що MS зробила із структурою налаштувань, тому вам доведеться трохи «обдурити» це.

Щоб безпосередньо відповісти на ваше запитання, просто додайте файл конфігурації вручну (xml) і назвіть його відповідно до вашої бібліотеки та включіть розширення "config". Приклад:

MyDomain.Mylibrary.dll.Config

Далі використовуйте ConfigurationManager для завантаження файлу та налаштувань доступу:

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

Зверніть увагу, що це повністю підтримує ієрархію machine.config, навіть якщо ви явно вибрали файл конфігурації програми. Іншими словами, якщо налаштування відсутнє, воно вирішить вище. Параметри також замінять записи machine.config.

Насправді бібліотека класів, яку ви реалізуєте, отримує інформацію з app.config усередині програми, яка її споживає, отже, найбільш правильним способом реалізації конфігурації для бібліотек класів у .net у VS є підготовка app.config у додаток для налаштування всього, що споживає, наприклад, конфігурації бібліотек.

Я трохи попрацював з log4net, і виявив, що той, хто готував додаток, завжди мав розділ для конфігурації log4net всередині main app.config .

Сподіваюсь, ця інформація вам стане в нагоді.

До зустрічі та розміщуйте коментарі щодо знайденого рішення.

РЕДАГУВАТИ:

За наступним посиланням у вас є app.config із розділом для log4net:

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

Якщо ви хочете налаштувати ведення журналу проекту за допомогою log4Net, використовуючи бібліотеку класів, фактично не потрібен будь-який конфігураційний файл. Ви можете налаштувати реєстратор log4net у класі і використовувати його як бібліотеку.

Оскільки log4net надає всі можливості для його налаштування.

Знайдіть код нижче.

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;
      }

Тепер замість виклику XmlConfigurator.Configure (новий FileInfo ("app.config")) ви можете безпосередньо зателефонувати SetLogger з потрібним шляхом та шаблоном, щоб встановити реєстратор у функції запуску програми Global.asax.

І використовуйте наведений нижче код для реєстрації помилки.

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

Використовуючи наступний код, вам не потрібно писати жодного рядка ні в програмі web.config, ні всередині бібліотеки app.config.

Насправді, у деяких рідкісних випадках ви можете зберігати app.config у бібліотеках класів (додаючи вручну) та аналізувати його за допомогою OpenExeConfiguration .

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

Ви повинні реально оцінити реальну потребу в цьому. Для абстрактних даних це не найкраще рішення, але "Налаштування розділів" може бути дуже корисним !!

Наприклад, ми організували нашу архітектуру N-Tier WCF, відокремлену без будь-яких метаданих, просто використовуючи Unity Container and Injection Factory на основі Channel Factory T. Ми додали зовнішню DLL ClassLibrary лише з інтерфейсом [Service Contract] та загальним app.config для того, щоб читати кінцеві точки з клієнтської секції та легко додавати / змінювати їх в одному місці.

Ви хочете додати App.config до бібліотеки класів тестів , якщо ви використовуєте індикатор / реєстратор. В іншому випадку нічого не реєструється під час запуску тесту через тест-драйвер, такий як TestDriven.Net.

Наприклад, я використовую TraceSourceв своїх програмах, але при запуску тестів нічого не реєструється, якщо я також не додаю файл App.config із конфігурацією трасування / журналу до бібліотеки тестових класів.

В іншому випадку додавання App.config до бібліотеки класів нічого не робить.

Ваша відповідь за неручне створення app.config - це вкладка Властивості / налаштування проекту Visual Studio.

Коли ви додасте налаштування та збережете, ваш app.config буде створений автоматично. На цьому етапі в просторі імен { yourclasslibrary .Properties} генерується купа коду, що містить властивості, що відповідають вашим налаштуванням. Самі налаштування будуть розміщені в налаштуваннях програми 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>

Якщо ви додали налаштування сфери застосування, яке називається Setting1 = 3, тоді буде створено властивість Setting1. Ці властивості стають частиною компіляції двійкового файлу, і вони прикрашені DefaultSettingValueAttribute, якому встановлено значення, яке ви вказали під час розробки.

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

Таким чином, як і в коді бібліотеки класів, ви використовуєте ці властивості, якщо відповідний параметр не існує у конфігураційному файлі середовища виконання, для резервного використання буде використано значення за замовчуванням. Таким чином додаток не вийде з ладу через відсутність параметра налаштування, що дуже бентежить перший раз, коли ви не знаєте, як ці речі працюють. Тепер ви задаєтеся питанням, як можна вказати наше власне нове значення в розгорнутій бібліотеці та уникнути використання значення за замовчуванням?

Це станеться, коли ми правильно налаштуємо виконуваний файл app.config. Два кроки. 1. ми усвідомлюємо, що у нас буде розділ налаштувань для цієї бібліотеки класів; 2. з невеликими змінами ми вставляємо конфігураційний файл бібліотеки класів у виконуваний конфігураційний файл. (існує метод, за допомогою якого ви можете зберігати конфігураційний файл бібліотеки класів зовнішнім, і ви просто посилаєтесь на нього з конфігурації виконуваного файлу.

Отже, ви можете мати app.config для бібліотеки класів, але це марно, якщо ви неправильно інтегруєте його з батьківським додатком. Подивіться тут, що я писав колись тому: посилання

Немає автоматичного додавання файлу app.config, коли ви додаєте проект бібліотеки класів до свого рішення.

Наскільки мені відомо, жодних протизаконних вказівок щодо того, щоб робити це вручну. Я думаю, що це звичне вживання.

Щодо конфігурації log4Net, вам не потрібно поміщати конфігурацію в app.config, ви можете одночасно мати у своєму проекті спеціальний файл конф, а також файл app.config.

це посилання http://logging.apache.org/log4net/release/manual/configuration.html надасть вам приклади обох способів (розділ в app.config та автономний файл конф. файлу log4net)

Я б рекомендував використовувати Properties.Settings для зберігання таких значень, як ConnectionStrings тощо у бібліотеці класів. Тут зберігаються всі рядки підключень за пропозицією Visual Studio при спробі додати адаптер таблиці, наприклад. введіть тут опис зображення

І тоді вони будуть доступні за допомогою цього коду скрізь у бібліотеці clas

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