Reconfiguration in referenced assemblies

Question

Say we have Assembly1 and Assembly2.

Assembly2 is the C # class library used by Assembly1.

Links to websites and services are configured and saved in Asembly2 / app.Config.

In addition, the EF connection string is in Assembly2 / app.Config.

When I use Assembly2 in Assembly1, the configuration file for Assembly2 is not used. In fact, in this case, access to the default settings is only possible with the Assembly1 configuration.

As a result, I need to copy the contents of the Assembly2 configuration to the Assembly1 configuration.

This worked for me for many projects.

Is there another way? The best way?

It seems wrong to repeat the configuration data.

Do you have a recommendation or technique that works?

Thanks.

Answer 1

You need to apply the changes to the exe assembly configuration file at the entry point. Assembly library (dll) configuration files are never used. They are created using Visual Studio, so you can easily copy the settings into exe configuration files, if necessary.

The following is an example configuration file for an exe assembly that has both parameters from the ClassLibrary1 class ClassLibrary1 and settings from the exe assembly MainAssembly . You can see that both connection strings are in the same connectionStrings setting. However, if you need to set other settings, next to the connection string you need to add an additional section.

If you are already using this technique, this is the right way. This method is flexible. For example, if in one window there are several projects with the same connection strings, you can specify the connection strings in the machine.config file. You can also override settings in some projects.

 <?xml version="1.0"?> <configuration> <configSections> <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > <!--This section declaratrion pasted here from dll conifg file --> <section name="ClassLibrary1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" /> <!--This section declaratrion was here in the first place --> <section name="MainAssembly.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" /> </sectionGroup> </configSections> <connectionStrings> <!--This connection string was here in the first place --> <add name="MainAssembly.Properties.Settings.MainAssemblyConnectionString" connectionString="MainConnectionStringValue" /> <!--This connection string pasted here from dll config file --> <add name="ClassLibrary1.Properties.Settings.LibraryConnectionString" connectionString="LibraryConnectionStringValue" providerName="" /> </connectionStrings> <applicationSettings> <!--This settings section pasted here from dll config file --> <ClassLibrary1.Properties.Settings> <setting name="LibrarySetting" serializeAs="String"> <value>LibrarySettingValue</value> </setting> </ClassLibrary1.Properties.Settings> <!--This strings section was here in the first place --> <MainAssembly.Properties.Settings> <setting name="MainAssemblySetting" serializeAs="String"> <value>MainSettingValue</value> </setting> </MainAssembly.Properties.Settings> </applicationSettings> </configuration> 

Answer 2

The DLL (or other referenced assembly) is not intended to port its own app.config, but rather everything is configured by the caller. So, everything should go in app.config exe.

Consider, for example, a shared data access library that needs database connection strings. The library must be available for use in various applications with different connection requirements. A connection string bound strictly to a shared library will not work; it must be executed on the client using the library.

You can set system settings that affect all applications running on the machine in the machine.config file, but use this approach with caution, as this will affect all applications on the machine.