2009-03-27 2 views
52

Часто мне нужно создать библиотеку классов .Net, для которой требуется app.config для таких вещей, как строки подключения к базе данных. Однако эти параметры должны быть в app.config или web.config вызывающего приложения. Если я хочу распространять DLL через несколько приложений, это становится больно, потому что я должен скопировать эти параметры в каждый app.config приложения.Использование app.config с библиотекой классов

Я рассмотрел вручную чтение настроек конфигурации с помощью кода изнутри библиотеки классов, но это также большая боль. У кого-нибудь есть предложения по наилучшему способу загрузки параметров app.config внутри библиотеки классов?

+0

Возможный дубликат [создать свои собственные настройки в xml] (http://stackoverflow.com/questions/396139/create-your-own-settings-in-xml) –

ответ

5

Одна вещь, которую вы можете сделать, это иметь отдельный файл настроек только для вашей библиотеки, тогда вам нужно будет иметь ссылку на него в файле конфигурации приложений входа.

См. accepted answer в this question для получения информации по этому вопросу.

15

Я знаю, что это не то, что вы хотите услышать, но конфигурационный файл точки входа является логическим местом для размещения этих настроек. Если бы каждая библиотека нуждалась в собственном файле конфигурации, то было бы утомительно редактировать каждый файл, а не только один.

У меня будет текстовый файл с настройками по умолчанию, входящими в состав вашей библиотеки (и как часть проекта), которые могут быть распространены вместе с библиотекой для настройки параметров по умолчанию (ее можно скопировать и вставить в конфигурацию файл).

+2

Это становится королевской PITA для чего-то вроде проект, который предназначен для ссылки на веб-службу, где вы можете продолжать обновление ссылки и продолжать обновлять связанный файл app.config. Я не согласен с вашим анализом - я говорю, что имеет смысл хранить настройки веб-службы в библиотеке классов, чем все, что ссылается на него. – Jez

+1

@Jez Тогда вы должны представить это как ответ. Несогласие - это хорошо, но сделайте для него дело. =) Тем не менее, проблема в том, что вам нужно предпринять ручные шаги для обновления этого внешнего файла конфигурации, тогда как файл app.config не потребует этих шагов. Кроме того, если вам нужно переключать конечные точки (больше проблем в корпоративных средах/внутренних сетях) в одном приложении, а не в другом, общий подход к наличию отдельного конфигурационного файла для * библиотеки * терпит неудачу из-за ручных обновлений, необходимых для внесите эти изменения. – casperOne

+0

Ну, что было бы лучше в этом случае, так это то, что конфигурация * referencing * переопределяет конфигурацию по умолчанию, указанную в библиотеке классов. Что действительно отстой, так это то, что конфигурация в библиотеке классов полностью игнорируется. Я не представляю его как ответ, потому что это не ответ на вопрос. Хотелось бы, чтобы я знал, как использовать 'app.config' с библиотекой классов. – Jez

3

Пусть каждая библиотека классов определяет параметры конфигурации в настраиваемом ConfigurationSection.

Затем добавьте обработчики пользовательских разделов в файл process.exe.config.

This MSDN article довольно подробный в своем объяснении с примерами как в VB, так и в C#.

Это связано с написанием довольно повторяющегося кода - Dmitryr создал this tool для создания разделов конфигурации из фрагмента XML-конфигурации, что могло бы помочь.

0

Нет проблем (большой) использовать собственный файл конфигурации для каждой библиотеки классов. Если вы используете vb.net, вы можете добавлять значения через панель «Мой проект» на странице «Настройки».

Единственное, что вам нужно сделать, это называть «My.Settings.Save» в настройках библиотеки классов (и не только в файле настроек основного приложения).

Это тоже работает с C# (но, вероятно, требуется больше ручной работы).

0

Если вы используете NUnit, назовите свой файл app.config с тем же именем, что и имя файла проекта * .nunit. Например, если вы назвали свой проект «ClassLibraryA.nunit», тогда назовите файл конфигурации библиотеки классов «ClassLibraryA.config». Они также должны находиться в той же папке/каталоге. На самом деле NUnit использует это как основной файл конфигурации.

Если у вас есть пользовательский код, вам необходимо убедиться, что ваш app.config (или web.config) ссылается на файл app.config библиотеки классов. Приложение заботится только о корневом app.config или web.config. Поэтому вам нужно добавить настраиваемый раздел конфигурации, который указывает на библиотеку классов app.config.

3

Вот альтернатива.

Вместо того чтобы попытаться найти способы «сливаться» ваши app.configs, или даже размещения элементов конфигурации в DLL (и пытается работать вокруг того, что «дизайн»), в первую очередь, попробуйте следующее:

Создайте свою DLL, но там, где вам нужен элемент Config, создайте общедоступное свойство. Когда вы создаете экземпляр класса в DLL, вы заполняете эти свойства элементами конфигурации из приложения-владельца.

Теперь конфигурация управляется на уровне владельца, а DLL переносима, так как вы должны передать то, что вам нужно, во время выполнения.

Нет больше DLL.config!

+3

Весь смысл использования библиотеки классов заключается в том, чтобы * не * иметь, чтобы разработчик хост-приложения должен был знать обо всех этих вещах. «Теперь конфигурация управляется на уровне владельца» именно то, чего мы пытаемся избежать. – as9876

0

Вы можете создать свой собственный XML-файл (назовите его appConfig.xml или что-то, если хотите), используйте System.Xml вместо System.Configuration для его чтения и включите его вместе со своей DLL.

1

Перейти к Свойствам приложения -> вкладка «Настройки»; добавьте свои настройки там.

Используйте Properties.Settings.Default.<SettingName> для доступа к настройке. Это оно!

0

Создайте свою библиотеку классов в другом решении. Если вы сохраните их в одном решении, вместо этого вместо этого будет отображаться app.config в самой высокой иерархии.

Смежные вопросы