3

I have a C# library which requires a binding redirect. The library itself references an executable, and I've placed the redirect in the config file this executable will use:

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="MyAssembly" publicKeyToken="null" culture="neutral"/>
        <bindingRedirect oldVersion="0.1" newVersion="0.2"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

The exe runs absolutely fine and reads the redirect. The problem is the compiler throws a warning (conflicting assembly) because at compilation time the library doesn't look at the config file, and so isn't aware of the binding redirect.

Unfortunately I can't have warnings in my domain. Any ideas as to how it might be suppressed? Or how I might 'force' my library to be aware of the redirect?

Warning is of type MSB3277.

FBryant87
  • 4,273
  • 2
  • 44
  • 72
  • 1
    Try adding an app.config with only that redirect to your library project. You could also simply suppress the warning in the project settings. – Daniel Hilgarth Oct 23 '15 at 11:03
  • Thanks, unfortunately the app.config approached failed (the compiler still doesn't read the file it seems). I've had no luck supressing the warning in Proj Properties -> Build -> Supress warnings, does this perhaps only apply to code-level warnings? Tried entering MSB3277 and 3277. – FBryant87 Oct 23 '15 at 11:10
  • i have had a similar problem, though in my case it was one of the other libraries in my solution linking to the same library, for me I just removed it because it wasnt used in that library – Henrik Bøgelund Lavstsen Oct 30 '15 at 11:18
  • 2
    The warning is a good one, in general binding redirects are a bad idea. The main reason is that they get us back into DLL hell only to be seen during runtime. To Debug those types of issues you must use the Fusion log and it can take you a long, long time to figure it out. My vote would be to include the assemblies you need using local copies of NUGET to store "approved Dlls" This is more an issue of "why did we ever decide to do binding redirects as a replacement of best practices"... Your environment may not allow any of this, so good luck to you. – JWP Oct 30 '15 at 16:48

3 Answers3

4

The library itself references an executable

This seems unlikely, surely the EXE project references the library.

The problem is the compiler throws a warning

This seems unlikely, this looks like a warning displayed by MSBuild, not the compiler.

Warning is of type MSB3277

This warning normally has a lot more useful information, you need to get your machine fixed if this is all you see. Otherwise do try to follow the hint displayed in the warning and change the build verbosity. Use Tools > Options > Projects and Solutions > Build and Run > "MSBuild project build output verbosity" > change to Diagnostic.

Use Build > Rebuild and you'll now get a trace in the Output window. You now ought to see a diagnostic message that resembles something like:

There was a conflict between "foobar, Version=1.42.0.0, Culture=neutral, PublicKeyToken="null" and "foobar, Version=1.666.0.0, Culture=neutral, PublicKeyToken="null".

"foobar, Version=1.42.0.0, Culture=neutral, PublicKeyToken="null" was chosen because it was primary and "foobar, Version=1.666.0.0, Culture=neutral, PublicKeyToken="null" was not.

Or some such verbiage, obviously the exact text you see is very important to decide what to do next and should never be omitted when you ask for help from anybody.

In general, this kind of warning is displayed when you have projects that have a dependency on a library but not the same version of the library. That's a problem when they are not installed in the GAC, the DLLs are copied to your build directory and one will overwrite the other. Only one of them can survive.

MSBuild was written to deal with this problem, it will choose one of them based on the "best guess" which one might cause the least trouble. It must tell you about this, not the kind of warning you should ever suppress because one of your projects is going to get a version of the library that it did not expect. Note how the <bindingRedirect> you used suppressed the normally fatal runtime error this causes. It is pretty unhealthy and needs to be thoroughly tested.

The only decent way to get rid of the warning is to change the dependency that the project uses so that the versions agree. Do beware that this is not always under your control, it might not be a library that you created yourself. Particularly an issue with Nuget libraries. In which case you do have to byte the bullet. If company policy forbids checking in projects that build with this warning (and do keep in mind that this is not a compiler warning) then the only reasonable thing you can do is to stop using the 3rd party library.

Community
  • 1
  • 1
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • This is missing the point of the question. The question is how do you do get MSBuild to be aware of redirects you intend to do for dll projects as MSBuild executes the version conflict verification task on them yet you cannot provide an app.config to a dll (as app.config is for executables only). Changing dependencies is not always an option, especially when using 3rd party references, so it is a legitimate case to have the warning and resort to redirect, yet you can't tell MSBuild that for dll projects neither can you suppress the warning. – David Burg May 25 '18 at 19:31
2

Have you tried the answer for that msbuild issue to see if there is another conflict you might have missed?

Other tools are in that thread such as AsmSpy.

Community
  • 1
  • 1
TombMedia
  • 1,962
  • 2
  • 22
  • 27
0

Try CopyLocal = true and check the specific version setting too.

Dexion
  • 1,101
  • 8
  • 14