Я не вижу файл 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.
Если вы хотите настроить ведение журнала проекта с помощью 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 внутри приложения, которое ее потребляет, поэтому наиболее правильным способом реализации конфигурации для библиотек классов в .net в VS является подготовка app.config в приложение для настройки всего, что он потребляет, например, настройки библиотеки.
Я немного поработал с log4net и обнаружил, что у того, кто готовил приложение, всегда был раздел для конфигурации log4net внутри main app.config.
Надеюсь, вы найдете эту информацию полезной.
До встречи и оставляйте комментарии о найденном решении.
EDIT:
По следующей ссылке у вас есть app.config с разделом для log4net:
http://weblogs.asp.net/tgraham/archive/2007/03/15/a-realistic-log4net-config.aspx
Собственно, для некоторых редких случаев вы можете хранить app.config в библиотеках классов (добавив вручную) и проанализировать его OpenExeConfiguration.
var fileMap =
new ExeConfigurationFileMap {ExeConfigFilename =
@"C:\..somePath..\someName.config"};
System.Configuration.Configuration config =
ConfigurationManager.OpenMappedExeConfiguration(fileMap,
ConfigurationUserLevel.None);
Вы действительно должны оценить реальную потребность в этом. Для абстрактных данных это не самое лучшее решение, но "Config Sections" может быть очень полезно!
Например, мы организовали нашу N-Tier WCF-архитектуру без каких-либо метаданных, просто используя Unity Container и Injection Factory на основе Channel Factory T. Мы добавили DLL externall ClassLibrary с помощью только интерфейсов [Service Contract] и обычный app.config для того, чтобы читать конечные точки от клиентов и легко добавлять/изменять их в одном месте.
Вы хотите добавить App.config в свою библиотеку классов тестов, если вы используете трассировщик/регистратор. Иначе ничего не регистрируется при запуске теста через тестовый бегун, например TestDriven.Net.
Например, я использую TraceSource в своих программах, но выполнение тестов не регистрирует ничего, если я не добавлю файл App.config с конфигурацией трассировки/журнала в библиотеку тестовых классов тоже.
В противном случае добавление App.config в библиотеку классов ничего не делает.
Ответом для создания app.config без ручного управления является вкладка Свойства/настройки проекта Visual Studio.
Когда вы добавляете настройки и сохраняете, ваш 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. с небольшими изменениями вставляем файл конфигурации библиотеки классов в исполняемый файл конфигурации. (есть метод, в котором вы можете сохранить внешний файл конфигурации библиотеки классов и просто ссылаться на него из исполняемого файла конфигурации.
Таким образом, у вас может быть 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>];