#.net #asp.net #configuration #web-config
#.net #asp.net #конфигурация #web-config
Вопрос:
У меня есть пользовательская конфигурация в моем инфраструктурном проекте, но при запуске моего приложения распознается только мой web.config.
Я не хочу размещать конфигурацию этого пользовательского файла конфигурации в моем web.config, потому что эта конфигурация отвечает за уровень инфраструктуры.
Как я использую эту пользовательскую конфигурацию из другого проекта в моем веб-проекте?
Комментарии:
1. Какая конфигурация инфраструктуры у вас есть, о которой веб-приложение не должно знать?
2. @Harper — это настройки пути к файлам, которые пользователь сохранит в приложении;
3. ХОРОШО — значит, это внутренняя конфигурация приложения, но на самом деле не «инфраструктура». Для меня это действительно звучит как материал, который принадлежит web.config. Обычно я создаю раздел пользовательской конфигурации для подобных вещей, чтобы у вас не было всевозможных сумасшедших ключей AppSettings.
4. web.config — это файл конфигурации — он доступен для всех уровней. Тот факт, что он находится в проекте «UI», является деталью реализации, а не декларацией того, что это такое.
5. Конечно. В решении Visual Studio файл web.config (или app.config) находится в проекте пользовательского интерфейса. Из-за существующего процесса сборки VS это то, что вы, вероятно, не будете менять. Однако файл конфигурации предназначен для приложения, а не для какого-либо конкретного логического уровня приложения. Вы можете настроить процесс сборки так, чтобы конкретная информация о конфигурации хранилась в отдельном файле, на который можно ссылаться из конечного web.config, не являясь его частью, или (в 2010 году) вы можете создавать преобразования web.config, которые процесс сборки использует для настройки конфигураций. Это всего лишь детали
Ответ №1:
Предыдущие ответы на этот вопрос не сообщают вам о критической точке.
.NET разработан так, чтобы иметь единый процесс настройки для каждого AppDomain . Все библиотеки классов будут использовать файл конфигурации приложения, которое их вызывает. В вашем случае ваша библиотека классов будет использовать web.config. Если бы ваша библиотека классов использовалась из консольного приложения, то для этого использовался бы файл application.exe.config.
Когда вы думаете об этом, это единственное, что имеет смысл. Если ваша библиотека классов используется из двух отдельных приложений, то она будет иметь две отдельные конфигурации. Эти конфигурации должны управляться от имени вызывающего приложения.
Комментарии:
1. Посмотрите на мою ситуацию, мне нужен пользовательский конфигурационный файл, чтобы задать пути, по которым будут сохраняться файлы. Web.config находится на уровне пользовательского интерфейса, вы уверены?
2. Если ваша библиотека классов вызывается с веб-страницы, то да, она должна быть в web.config. Это не вопрос слоев. Это не имеет никакого отношения к слоям. Это связано с тем, какой файл необходимо изменить, чтобы изменить конфигурацию. .NET значительно упрощает настройку, требуя один файл для каждого приложения , а не один файл для каждого компонента, как в случае с INI-файлами или реестром.
3. У вас есть источник, в котором, скажем, .NET предназначен для единого процесса настройки для каждого домена приложения?
4. Смотрите msdn.microsoft.com/en-us/library/ms229689.aspx : «Имя и расположение файла конфигурации приложения зависят от хоста приложения, который может быть одним из следующих»
Ответ №2:
Что-то вроде этого:
var exeMap = new ExeConfigurationFileMap {ExeConfigFilename = @"C:PathToYourFile"};
Configuration myConfig = ConfigurationManager.OpenMappedExeConfiguration(
exeMap, ConfigurationUserLevel.None
);
Комментарии:
1. Существует другой более простой способ?
2. Конечно, вы можете использовать этот
<appSettings file="foo.config">метод, но тогда вы можете использовать только относительный путь к другому файлу. Обычно это используется для упорядочивания настроек приложения и строк конфигурации.3. Я знаю этот подход, но я тоже не хочу их использовать. Я часто вижу пользовательские файлы конфигурации других библиотек, таких как log4net, я не знаю, как они это используют.
4. NHibernate также использует такую настройку, но они написали свою собственную структуру конфигурации.
Ответ №3:
Предполагая, что проект инфраструктуры является библиотекой классов, рассматривали ли вы возможность создания свойств для предоставления настроек app.config (?) интерфейсу?
Вот пример того, что я имею в виду. Имейте в виду, что это всего лишь пример. Это свойство, которое демонстрирует, как предоставить значение конфигурации через свойство. В вашем случае свойство будет извлекать значение из вашего пользовательского файла конфигурации.
public string GetConfigurationValue(string Key)
{
return GetValueFromConfiguration(Key);
}
Мне интересно, почему вы создаете пользовательский файл конфигурации, а не просто создаете раздел конфигурации, который можно интегрировать в файл app.config. Похоже, вы делаете вещи намного сложнее, чем они должны быть.
Комментарии:
1. это не app.config, это пользовательская конфигурация. да, для создания пользовательской конфигурации мне нужно создать класс, производный от ConfigurationSection . Вы имеете в виду получать значения непосредственно из класса, а не получать значения из файла конфигурации?
2. Нет, я имею в виду создание общедоступных свойств, которые извлекают значения из вашего файла конфигурации, чтобы веб-приложение, использующее библиотеку, могло использовать свойства для доступа к значениям конфигурации.
3. -1: почему используется ваш пример
WebConfigurationManager? Это ограничило бы вызов кода из ASP.NET .4. Я очень четко заявил, что это пример, и что он будет отличаться для его реализации. Это должно было продемонстрировать концепцию предоставления значений конфигурации через свойство. Честно говоря, удивлен, что вы бы проголосовали против этого. Я чувствую, что вы не читали мой ответ.
5. Я прочитал комментарий, и я знаю его конкретный пример, но я чувствую, что, когда кто-то приходит к этому ответу в поисках информации о файле конфигурации в целом, ваш пример дает неверное представление.