Настройки. Значение по умолчанию. <свойство> всегда возвращает значение по умолчанию вместо значения в персистентном устройстве хранения данных (XML-файл)

Я использую эту технику все время времени. Часто у меня есть блок библиотеки, который требует определенных настроек, и мне нужны они набор оба путем тестирования проектов, а также основных "исполняемых" блоков - быть ими проекты службы Windows или веб-проекты.

Вы корректны в этом при создании файла настроек для любого проекта он добавляет файл конфигурации приложения. Значение Вы вводите для любой установки, хранится в двух местах - файл конфигурации И в атрибутах на классах, созданных инфраструктурой настроек. Когда файл конфигурации не найден, значения, встроенные в атрибуты, используются.

Вот отрывок, который показывает такой атрибут:

Вот отрывок, который показывает значение по умолчанию ConcordanceServicesEndpointName в сгенерированном классе:

    [global::System.Configuration.ApplicationScopedSettingAttribute()]
    [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
    [global::System.Configuration.DefaultSettingValueAttribute("InternalTCP")]

    public string ConcordanceServicesEndpointName {
        get {
            return ((string)(this["ConcordanceServicesEndpointName"]));
        }
    }

То, что Вы хотите сделать, скопировать раздел конфигурации из app.config файла из проекта блока библиотеки и объединить его (тщательно) в применимый web.config или app.config для основного блока. Во времени выполнения это - единственный файл конфигурации, который используется.

Вот пример:

<configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
      <section name="LitigationPortal.Documents.BLL.DocumentsBLLSettings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <applicationSettings>
    <LitigationPortal.Documents.BLL.DocumentsBLLSettings>
      <setting name="ConcordanceServicesEndpointName" serializeAs="String">
        <value>InternalTCP</value>
      </setting>
    </KayeScholer.LitigationPortal.Documents.BLL.DocumentsBLLSettings>
  </applicationSettings>

Необходимо скопировать эти разделы в "истинный" файл конфигурации.

У меня была эта та же проблема в течение долгого времени - это является раздражающим.

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

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

Например, у меня есть класс, который использует LINQ-SQL, чтобы говорить с DB. Таким образом, это имеет файл Setting1.settings, в котором это хранит строку подключения к базе данных. Значение по умолчанию, которое вводится (после перетаскивания таблиц базы данных в разработчика) является строкой подключения dev базы данных.

После того как у меня есть файл DBML, созданный базирующийся прочь тестовой базы данных, я могу войти и отредактировать файл Настроек и тип на имя базы данных как "FAKE_DATABASE".

Тот путь, если Вы используете DLL в другом проекте и затем забываете объединять файлы конфигурации для добавления в надлежащем значении конфигурации для DLL, по крайней мере, Вы получите ошибку при высказывании, что что-то как "Не может соединиться с FAKE_DATABASE".

Конечно, если необходимо работать с разработчиком снова, необходимо будет возвратить значение к значению dev базы данных.

Огромная боль. Они имеют, должен изменить это так или иначе.

По-видимому, Ваше приложение пытается читать из файла конфигурации по умолчанию (который является, вероятно, файлом конфигурации приложения). Для проверки добавьте пару "ключ-значение" в файле конфигурации dll к файлу конфигурации приложения, запустите приложение и посмотрите, читается ли это на этот раз.

Я видел подобную проблему при использовании app.config. Попытайтесь запустить свое приложение от .exe вместо из Visual Studio и посмотрите, ведет ли это затем себя как ожидалось.

Возможно, что в Вашем DLL у Вас есть модификатор доступа (для Settings1. Настройки) набор к Внутреннему (Друг для VB). Попытайтесь изменить Модификатор Доступа на Общественность и посмотрите, позволяет ли это Вашим значениям чтения-записи приложения от конфигурации dll.

Я думаю, что просто нашел объяснение того, почему это не работает на мой DLL и мое тестовое приложение. Вот заключительное исключение из блога некоторого парня:

Фиксация для этого должна или удостовериться, Ваше приложение и блоки поддержки имеют то же пространство имен или удостоверяться, что Вы объединяете содержание AppName.exe.config и DllName.dll.config (да при компиляции .dll теперь, это генерирует этот файл, однако проигнорировано, копируете ли Вы его в каталог приложения, и автоматически не объединяется),

Так любой я должен сохранить DLL и Приложение в том же пространстве имен - или я должен объединить содержание файла конфигурации DLL с файлом конфигурации Приложения.

(Не этот вид поражения цель DLL? Я думал, что DLL, как предполагалось, был независимой библиотекой.)

Возможно, это - то, почему это работает на моего коллегу. Производственное приложение совместно использует то же пространство имен как DLL. (Мое тестовое приложение ясно не делает...),

ОБНОВЛЕНИЕ: Я просто сел со своим коллегой недавно и говорил об этой проблеме снова, и кажется, что это никогда не работало на него также, но он не понял это, потому что он установил начальное значение для совпадения с устройством, которое мы пытались использовать. Таким образом, конечно, это, казалось, работало сначала, но как только мы развернули его в другом месте с немного отличающимися настройками, это было повреждено снова.