views:

972

answers:

1

I have inherited a rather large project consisting of an application written in VB6 and several DLL's and ActiveX controls written in VB6, VB.NET 1.1 and VB.NET 2. I want to change one of the settings for one of the DLL's written in VB.NET 2 that is in its application.dll.config file, but it seems to be having no effect.

My main VB6 application (I will call it Alpha) has a configuration file (Alpha.exe.cnfig) which contains settings used by my VB.NET 1.1 DLL (which I will call Bravo). After calling Bravo, Alpha calls Charlie (my VB.NET 2 DLL). However, even though I have changed the application settings in Charlie.dll.config in the subdirectory where the DLL lives, it has no effect. I have tried putting Charlie's settings in Alpha's config file but this causes Bravo to fail with an automation error (which I think is because the format of the config files changed from .NET 1.1 and .NET 2).

Below is a simplified directory structure and file location example:

\Application\Alpha\Alpha.exe (my VB6 application)
\Application\Alpha\Alpha.exe.config (this config file is used by Bravo.dll)
\Application\Assembly\Bravo.dll (my VB.NET 1.1 DLL)
\Application\Controls\Charlie\Charlie.dll (my VB.NET 2 DLL)
\Application\Controls\Charlie\Charlie.dll.config (this file is ignored by Charlie.dll)

I have re-compiled my VB.NET 2 DLL with the default settings changed, I did this to check there is no code fault with the setting itself, and this works fine. However, I want to be able to inform the client how to change the config file so he can set it to be anything he wants without me having to re-compile the DLL every time he wants a different setting.

I only want to alter app.config and not machine.config or user.config.

Here is an example of Alpha.exe.config:

<configuration>
    <appSettings>
        <add key="MySetting" value="MyValue" />
    </appSettings>
</configuration>

And here is an example of Charlie.dll.config

<configuration>
    <applicationSettings>
        <Charlie.My.MySettings>
            <setting name="MySetting" serializeAs="String">
                <value>MyValue</value>
            </setting>
        </Charlie.My.MySettings>
    </applicationSettings>
</configuration>

If I try putting the applicationSettings section under directly beneath the appSettings section (i.e. as another child element of the configuration element) in Alpha.exe.config then Bravo.dll fails.

Many thanks in advance for any help you can provide.

A: 

The problem seems to be that because Bravo.dll targets 1.1, the 1.1 version of the framework gets loaded, and, as you say, the applicationSettings section is new in .NET 2.0. The solution is to force the VB exe to load the 2.0 framework. Adding a startup/supportedRuntime element in the Alpha.exe.config file should do the trick. You will also need some comfiguration section declarations, so at the end Alpha.exe.config should look something like this:

<configuration>
    <startup>
        <supportedRuntime version="v2.0.50727" />
    </startup>
    <configSections>
        <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
        <section name="Charlie.My.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
    </configSections>
    <appSettings>
        <add key="MySetting" value="MyValue" />
    </appSettings>
    <applicationSettings>
        <Charlie.My.MySettings>
            <setting name="MySetting" serializeAs="String">
                <value>MyValue</value>
            </setting>
        </Charlie.My.MySettings>
    </applicationSettings>
</configuration>
csgero
That was what I meant by under, as in directly beneath, not within, sorry for the confusion. I have tried what you suggest and it causes an automation error, I am guessing because .NET 1.1 cannot understand the .NET 2 section of the configuration file.
AnturCynhyrfus
I have tried adding the configSections element as you suggested however this still causes Bravo.dll (.NET 1.1) to fail with an automation error, or at least that's what VB6 reports.
AnturCynhyrfus
I have updated again, adding supportedRuntime, I hope this finally solves the issue.
csgero
Alas not, I still get an automation error. I have tried using requiredRuntime as well, to no effect. I fear my only solution is going to be porting Bravo.dll to .NET 2.
AnturCynhyrfus