Why Won't My DLL.config File Load on Some Machines

Question

I have an Outlook Add-in written in C#, MyAddin.dll, that has a configuration file MyAddin.dll.config. Both are stored in the same directory. They are placed there and installed by an installer. On most installations, there is no problem with finding and reading the config file. But, on a few installations (exact same version, install, etc.), the .config is never opened.

The config file contents looks like this...

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

I implicitly load this config file with a call in my addin in one of my classes...

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

Like I said, this works on many installations, but not on a few. I have run PROCMON to watch for the file events on the config file. On systems where the file loads, PROCMON shows it in the trace. On systems where it does not load, PROCMON shows no mention of the config file.

Why would my C# compiled application extension (DLL) correctly load in one instance, but won't even try to load the config file in another? Or, could you please provide suggestions for diagnosing this? where to look, etc.

More info: The Add-in is compiled "Any CPU", it is installed on Windows 7 x64. The 32-bit version of Office 2010 (Outlook) is installed. All of these parameters are true for both the working versions and the one that does not open the config file.

More info(2/21/2012): The addin is built in the release mode. Under VS2008 Project Properties>Build, the "Define TRACE constant" is checked. The solution targets the .NET 3.5 Framework. The behavior appears to be that the System.Diagnostics.TraceSwitch implementation on the machines where this fails is different than on other machines. I've used process explorer to compare a failing machine to a working one, and the difference is mainly that the failing machine has mostly precompiled assemblies while the work one does not. Should that matter?

Answer 1

Could you more explicitly tell your code to find configuration information with a ConfigurationChannelFactory?

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