Do binding redirects in app.config for class libraries do anything?

Question

The VS solutions I often work with consist of a single executable project (console app, web app) and many class library projects that are all referenced by the executable.

When working with NuGet and installing packages, there's often an app.config file created for each project, usually containing nothing else than a list of binding redirects that consolidate versions of referenced assemblies. Sometimes there's some third-party library-specific content (like Entity Framework config section), but let's leave that aside for now.

When I build the solution and use the binaries of the main executable project, I see all the class library project assemblies in the build output together with the corresponding *.config files (the app.config file gets renamed to AssemblyName.config when built).

When launching the main executable, do the config files of the class library assemblies take any effect? Or is it just the app.config file of the executable that has an effect in this case? What if there are some binding redirects set up on some of the class library projects, and some different binding redirects set up on the main executable project — How are these combined, which take priority?

I've tried to research this online and from what I've read, it looks to me like the app.config files for non-executable assemblies are useless (with regards to binding redirects). Can someone confirm this or elaborate a bit more on the topic?

If it is that way, is it actually undesirable to have these app.config files created by NuGet in class libraries if they contain just the binding redirects? It feels to me that NuGet shouldn't create those binding redirects for class library projects, as it will only increase the confusion about what settings are actually applied.

---

I found these existing Stack Overflow questions on the topic, but their accepted answers are actually contradictory even when they're marked as duplicates of each other.

• Why NuGet adds app.config with assemblyBinding to LIBRARY projects during a NuGet package update?

• Is the bindingRedirect .config file needed or all assemblies in an application?

The accepted answer to the first question mentions that app.config files are actually used during compile-time, which means they could have effect. Sources like MSDN and MSBuild source code are cited there as a proof it's used during compile-time. Unfortunately, I'm not proficient enough in MSBuild to understand how it's being used, and if it's really a valid argument.

Can anybody describe an example scenario to prove that an app.config with binding redirects for a class library can do anything?

Rather

Check out this answer: #43366236 – Marco

@Marco that's talking about the main executable project's app.config. The configs for all the class libraries in the solution won't have that effect. – Nope

Answer 1

I have multiple applications with similar setup - Web application referencing multiple library projects each having their own nuget packages etc., Based on my personal experience the assembly bindings in the library projects are not considered during run time.

The bindings specified web or app config in the root application (web/console) is that only matters. All my library projects are setup with "Copy to Output Directory" setting as "Do not copy" for the app.config file - that way my output folder is not cluttered with dll and their config files.

Here is the link which says how the assembly is loaded and where is it being searched and the sequence of it. No where in the article they talk about individual project config files.

Hope that helps.

Syndrome

As far as I know, the app.config files are set to "Do not copy" by default, and they still get to the build output. Just note they'll no longer be called "app.config", but "YourAssemblyName.dll.config", that is the standard behavior. Also, can you address the claims that app.config is used during compile-time I reference in the question? I cited sources like MSDN or MSBuild source code in the question, which point to the fact that there's some behavior during compile-time. – Nope

Answer 2

The answer is maybe. Depending on the type of project the library file is. Some library projects run in contexts where the library's config file is respected (e.g. Azure Web Roles), but that is not the norm.

See my answer here for more details.

Kadner

Answer 3

According to this old msdn article:

An application configuration file is an XML file used to control assembly binding. It can redirect an application from using one version of a side-by-side assembly to another version of the same assembly. This is called per-application configuration. An application configuration file applies only to a specific application manifest and dependent assemblies. Isolated components compiled with an embedded [ISOLATIONAWARE_MANIFEST_RESOURCE_ID] manifest require a separate application configuration file. Manifests managed with CreateActCtx require a separate application configuration file.

So only dll's with the ISOLATIONAWARE_MANIFEST_RESOURCE_ID set actually use an independent application config, otherwise it's deferred to the main process config file.

For more info on what ISOLATIONAWARE is you can read this other MSDN article that goes more in depth.

ISOLATIONAWARE_MANIFEST_RESOURCE_ID is used primarily for DLLs. It should be used if the dll wants private dependencies other than the process default. For example, if an dll depends on comctl32.dll version 6.0.0.0. It should have a resource of type RT_MANIFEST, ID ISOLATIONAWARE_MANIFEST_RESOURCE_ID to depend on comctl32.dll version 6.0.0.0, so that even if the process executable wants comctl32.dll version 5.1, the dll itself will still use the right version of comctl32.dll.

Leoleod

How about the use of app.configs during compile-time that I mention in the question (below the line)? – Nope

in the first quote it specifies that only the main app.configs redirects are used on compile time unless the depended library was compiled with the [ISOLATIONAWARE_MANIFEST_RESOURCE_ID] flag. – Leoleod

And if you go to the [MSBUILD source][1], it only loads the redirects from one app config [1]: github.com/Microsoft/msbuild/blob/… – Leoleod

Thank you for looking into this. Isn't the ISOLATIONAWARE_MANIFEST_RESOURCE_ID related only to runtime? How are any of these flags used in compile-time? Regarding the MSBuild, can't it mean that if I'm building the class library project, it's using one app.config file -- the app.config file of the class library project? – Nope

Answer 4

Generally there is only one configuration file and thats the configuration file of the executeable (.exe.config, web.config).

Any assembly redirects have to be placed in the configuration file of the executable.

Configuration files of dlls need to be loaded manually using the ConfigurationManager class. See also this question Equivalent to 'app.config' for a library (DLL)

Impress

I agree with you, I think the same. But can you provide some source for that claim? Also, please read the part of the question below the line about related questions. There are some contradictory claims there and they cite sources like MSDN and MSBuild source code saying the app.configs are in fact used during compile-time (which I fail to believe). – Nope

@The only thing were I can think of that thay may be required is during unittests. Unit test runner will mostly load the dll under test and the configuration file of the dll (if it exists). I think the runner will also apply the redirects – Impress

I agree, I've always considered unit test projects as executable projects, as they have their own sort-of entry points, and usually, there's also all the DI setup, and they just feel more as executables to me. Class libraries are quite different to unit test projects to me. – Nope

Answer 5

No, only the app.config of the executable will have effect. For example, if you have a console app hosting a WCF service, and in your WCF service you make use of, for example, ConfigurationManager.AppSettings, the AppSettings will come from the console host app.config file. If you spin up another console application (ConsoleClient) to try connecting to the ConsoleHost, then in the parts where the ConsoleClient can be said to be "executing" (for example in its main method), it will use ConsoleClient's app.config, but as soon as it begins using the WCF service, the WCF service will delegate to use ConsoleHost's app.config. (Note that this last point is more relevant to the details behind WCF though.)

Surprisingly, msdn provided this great source: https://social.msdn.microsoft.com/Forums/vstudio/en-US/e13194df-6308-4cbe-973c-f6a462f43eae/how-can-wcf-library-dll-access-application-settings?referrer=http://social.msdn.microsoft.com/Forums/vstudio/en-US/e13194df-6308-4cbe-973c-f6a462f43eae/how-can-wcf-library-dll-access-application-settings?referrer=http://social.msdn.microsoft.com/Forums/vstudio/en-US/e13194df-6308-4cbe-973c-f6a462f43eae/how-can-wcf-library-dll-access-application-settings?forum=wcf

Hughett

Can you provide some source for that claim? Also, please read the part of the question below the line about related questions. There are some contradictory claims there and they cite sources like MSDN and MSBuild source code saying the app.configs are in fact used during compile-time (which I fail to believe). – Nope