Question

If I add a NuGet package reference to DLL project MyLib (i.e. output type Class Library), the package manager sometimes creates an app.config in the project (for example with a bindingRedirect) that gets built as MyLib.dll.config. Microsoft.Owin 2.1.0 does this, for example.

When my Windows desktop application loads MyLib.dll, it ignores the bindingRedirect in MyLib.dll.config, and I get a FileLoadException. I can fix the problem if I manually copy the bindingRedirect to the app.config for the EXE project.

Is this manual copy-paste between app.config files really the only way to get a NuGet bindingRedirect to work?

It seems terribly tedious and error-prone given that NuGet is supposed to handle dependencies automatically.

Was it helpful?

Solution 3

There is a better way. I just needed to add some local project references before adding the NuGet package reference.

When I originally added the Microsoft.Owin NuGet reference to MyLib, I had not yet added a MyLib reference to MyApp (aka the EXE project). With the MyLib reference in MyApp, I uninstalled the Microsoft.Owin NuGet package, then added Microsoft.Owin back to MyLib. Bada-bing-bada-boom. The bindingRedirect was automagically added to MyApp's app.config file.

So, when creating a new Class Library, one should apparently add new-library references to existing projects before adding NuGet package references to the new library.

OTHER TIPS

It is the only way: app.config files in Class Library projects are essentially just sample code that you can copy into the main application's config file if needeed.

In the case of bindingRedirect - I would expect it only to be necessary in two cases:

  1. if you have multiple dlls accessing different versions of the MyLib assembly. In which case, you need to make an explicit decision as to which version you're going to use.

  2. If your main application's assembly contains configuration elements that reference an older version of the MyLib assembly. In which case you can do one of:

    • Update the versions in your main configuration file
    • Add a bindingRedirect to the main configuration file
    • Add the Nuget package to the main application project, in which case it will presumably add the bindingRedirect for you.

All that package specific config file does is show you the configuration that is specific to that package. You may or may not want to put it into your actual config file, you may need to tweek it for your purposes (EntityFramework or log4net are good examples of that). In the case of installing the package into a class library a config file makes no sense at all, that config needs to be moved into the appropriate executable app.config - how could that be automated.

Before nuget you would download the dll from somewhere and then follow the instructions on how to set up the necessary configuration. This is definitely an improvement on that.

So in summary, yes you do need to copy it if you need it and it does make sense.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top