Служба Windows, странное поведение с appSettings в app.config - PullRequest
Новая
       16

Служба Windows, странное поведение с appSettings в app.config

2 голосов
/ 24 мая 2011

Я работаю над проектом с общим компонентом ядра, в котором используется раздел <appSettings /> в соответствующем файле конфигурации.

Это прекрасно работает для веб-части asp.net, которая используетweb.config.

Однако есть служба Windows, которая использует этот же компонент общего ядра, который (по разным причинам) получает доступ к данным конфигурации непосредственно изнутри (то есть, к встроенным вызовам ConfigurationManager.AppSettings["key"]), которые я не могу легко изменить.

Это не было бы проблемой, но я обнаружил, что веб-сервис, похоже, не может подобрать значения appSettings, которые я добавил в его app.config.Когда я развертываю это на сервере разработки, он, конечно, становится ServiceName.exe.config, и файл конфигурации в противном случае работает правильно (он также содержит некоторые <applicationSettings /> типобезопасные настройки, которые работают как положено.

Поскольку яя не могу легко изменить общий компонент, я застрял с каким-то образом работать с <appSettings /> в файле app.config службы.

Вещи, которые я проверил: структура выглядит хорошо: 

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
            <section name="xxxxx.UploadManagerService.UploadManager" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
        </sectionGroup>
    </configSections>
    <applicationSettings>
        <xxxxx.UploadManagerService.UploadManager>
            <setting name="NumberOfUploaderThreads" serializeAs="String">
                <value>2</value>
            </setting>
             :
        </xxxxx.UploadManagerService.UploadManager>
    </applicationSettings>

  <appSettings>
    <add key="keyname" value="value" />
     :
  </appSettings>

</configuration>

(где: означает «больше того же самого»: -)

Служба работает нормально, за исключением случаев, когда метод в базовом компоненте пытается получить доступ к любому из значений <appSettings />.

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

Вот фрагмент того места, где он падает: 

return SendEmailViaAmazonSES(
          new List<string> { clientEmailAddress },
            ConfigurationManager.AppSettings["SalesEmail"],
            "Order Confirmation.",
            content);

... который, к счастью, попал в ловушку при попытке: поймать и, следовательно, ничего не падает, кроме тех,ConfigurationManager.AppSettings["key"] вызовы используются повсеместно, и я не могу изменить их без значительного влияния на другие системы, которые уже используют этот основной компонент.

Есть идеи?

Другие вещи, которые я проверял: файл конфигурации службы находится в той же папке, что и служба exe, dev config ДОЛЖЕН содержать правильные значения.

РЕДАКТИРОВАТЬ 25/5

Поскольку служба вызывает только несколько методов, требующих доступа к значениям <appSettings />, я просто обманул, скопировав эти методы в саму службу и используя вместо этого значения в <applicationSettings />.Это не идеально, и я все еще очень хочу выяснить, почему это не работает для Службы Windows, но я не мог позволить себе ждать, поэтому я принял прагматичное решение «выдумать это» тем временем.Я всегда могу вернуться к этому позже или (как это случилось) забыть об этом; -)

1 Ответ

0 голосов
/ 24 мая 2011

Права доступа к файлу

Проверьте, имеет ли пользователь, под которым работает ваша служба Windows, доступ на чтение к своему файлу .config.

Sysinternals Process Monitor

Используйте Sysinternals Process Monitor и выполните фильтрацию по имени вашей службы, чтобы узнать, действительно ли процесс пытается получить доступ к вашему файлу по ожидаемому пути.

...