Почему на некоторых машинах не загружается мой файл DLL.config - PullRequest
Новая
       58

Почему на некоторых машинах не загружается мой файл DLL.config

1 голос
/ 16 февраля 2012

У меня есть надстройка Outlook, написанная на C #, MyAddin.dll, в которой есть файл конфигурации MyAddin.dll.config.Оба хранятся в одном каталоге.Они размещаются там и устанавливаются установщиком.На большинстве установок нет проблем с поиском и чтением файла конфигурации.Но на некоторых установках (точно такая же версия, установка и т. Д.) .Config никогда не открывается.

Содержимое файла конфигурации выглядит следующим образом ... 

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
      ...
    </configSections>
    <system.diagnostics>
      <switches>
        <add name="MySwitch" value="4" />
      </switches>
    </system.diagnostics>
</configuration>

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

internal static TraceSwitch myTraceSwitch = 
    new TraceSwitch("MySwitch", "My Trace Level Switch");

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

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

Дополнительная информация: Надстройка скомпилирована «Любой процессор», она установлена ​​на Windows 7 x6432-разрядная версия Office 2010 (Outlook) установлена.Все эти параметры действительны как для рабочих версий, так и для той, которая не открывает файл конфигурации.

Дополнительная информация (21.02.2012): надстройка построена в режиме выпуска.В VS2008 Project Properties> Build проверяется «Определить константу TRACE».Решение предназначено для .NET 3.5 Framework.Поведение выглядит так, что реализация System.Diagnostics.TraceSwitch на машинах, где это происходит не так, отличается от других машин.Я использовал обозреватель процессов, чтобы сравнить сбойную машину с работающей, и разница главным образом в том, что сбойная машина имеет в основном предварительно скомпилированные сборки, а рабочая - нет.Это должно иметь значение?

1 Ответ

1 голос
/ 16 февраля 2012

Не могли бы вы более явно указать своему коду поиск информации о конфигурации с помощью ConfigurationChannelFactory?

http://msdn.microsoft.com/en-us/library/dd575430%28v=VS.100%29.aspx

...