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 с первого дня.

Джон, было высказано множество мнений, которые не дали правильного ответа на ваш вопрос.

Я выскажу СВОЕ МНЕНИЕ, а затем расскажу, как сделать именно то, о чем вы просили.

Я не вижу причин, по которым сборка не может иметь собственный файл конфигурации. Почему первый уровень атомики (это настоящее слово?) Находится на уровне приложения? Почему не на уровне решения? Это произвольное решение, основанное на предположении, и как таковое МНЕНИЕ. Если бы вы написали библиотеку журналирования и хотели бы включить для нее файл конфигурации, который будет использоваться глобально, почему бы вам не подключиться к встроенным функциям настроек? Мы все это делали ... пытались предоставить "мощную" функциональность другим разработчикам. Как? Делая предположения, которые по своей сути переводятся в ограничения. Это именно то, что 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 внутри основного 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 (new 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-уровневую архитектуру WCF отдельно, без каких-либо метаданных, просто используя контейнер Unity и фабрику инъекций на основе фабрики каналов T. Мы добавили dll externall ClassLibrary только с интерфейсами [Service Contract] и общим app.config по порядку чтобы читать конечные точки из клиентского раздела и легко добавлять / изменять их в одном месте.

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

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

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

Ваш ответ на создание app.config не вручную - это вкладка Visual Studio Project Properties / Settings.

Когда вы добавляете настройку и сохраняете, ваш app.config будет создан автоматически. На этом этапе создается куча кода в пространстве имен { yourclasslibrary .Properties}, содержащем свойства, соответствующие вашим настройкам. Сами настройки будут помещены в настройки app.config applicationSettings.

 <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. с небольшими изменениями мы вставляем файл конфигурации библиотеки классов в исполняемую конфигурацию. (есть метод, в котором вы можете сохранить внешний файл конфигурации библиотеки классов и просто ссылаться на него из файла config.

Итак, у вас может быть app.config для библиотеки классов, но он бесполезен, если вы не интегрируете его должным образом с родительским приложением. Посмотрите, что я написал некоторое время назад: ссылка

При добавлении проекта библиотеки классов в решение не происходит автоматического добавления файла app.config.

Насколько мне известно, нет никаких указаний на то, что это нужно делать вручную. Я думаю, это обычное дело.

Что касается конфигурации log4Net, вам не нужно помещать конфигурацию в app.config, вы можете иметь специальный файл conf в вашем проекте, а также файл 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>];