Popular open source libraries and reference conflicts

Question

We use log4net in all of our (many) internal applications. Usually we do xcopy deployment. For the convenience of the developers, we compiled the log4net source into one of our main libraries.

Now we come back to bite us. Other open source libraries (such as Topshelf ) link to log4net. Still others ( NServiceBus , for example) combine log4net into their assemblies. Usually the versions are different.

This is a general question; specific libraries are just examples.

There are several similar questions:

• The manifest definition of the located assembly does not match the assembly reference
• .Net choosing the wrong reference version of the assembly
• How to eliminate the ambiguity between a project DLL and a DLL in the GAC?
• .NET compiled third-party DLL link conflict

Of the various solutions (GAC, assemblyBinding, bindingRedirect, etc.), what can cause us the least pain in the future? We can change our core library; we simply can’t do anything to break the existing deployed version in the field. Updating all of our project links will be painful, so we want to do this only once.

Update: The current version of Topshelf abstracts logging, so this is no longer a problem with this infrastructure.

Answer 1

In your case, I would decompose my DLL into the GAC using the publisher build policy

A publisher policy assembly is an assembly that configures the policy that will be used when the .NET runtime is bound to the assembly. Thus, you can easily update your entire project by specifying in the publisher policy which version of your DLL should be used.

Example publisher build policy:

<configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1″> <dependentAssembly> <assemblyIdentity name="website" publicKeyToken="18517ea673f8584b" culture="neutral" /> <bindingRedirect oldVersion="1.0.0.0″ newVersion="2.0.0.0″/> </dependentAssembly> </assemblyBinding> </runtime> </configuration> 

Answer 2

One small known / used function that I deal with several links sequentially and easily update them, Reference Paths combined with redirect forwarding. Using the reference paths, I can maintain the shared library in a separate library class / package in the source control, which contains the dependent library that we use.

Having my own copy of files that are separately controlled (it is often necessary to include the .license file in the shared libraries folder if it is a paid library) allows new developers to quickly ensure they have the correct version installed on their machine, without contradicting the existing libraries already on your computer.

There is a caveat to this approach, and any additional reference paths you add are not stored in the .csproj file, but instead a .csproj.user file.

Many source version control solutions, such as Team Foundation Server or Vault; these files are not included in the registration process by default. Most source code providers, including the two mentioned, have the ability to change controlled file extensions for each project, as well as worldwide.

The only other caveat is that some source code providers, such as Vault, treat .csproj and .csproj.user files as binary files by default; again, this can be changed, and they can be seen as XML in the case of Vault, allowing you to create merges.

They are processed as XML out of the box in Team Foundation Server.

Answer 3

There is an NServiceBus that does not integrate third-party assemblies.

From the download page :

Problems with federated assemblies?

To reduce the number of assemblies that developers should reference in their Visual Studio projects, NServiceBus combines several third-party assemblies into their own assemblies. This can lead to conflicts if developers use these third-party assemblies in their own code - especially when using a different version than using NServiceBus.

To solve this problem, developers should use kernel assemblies for NServiceBus only. For companies that have purchased a commercial license and NServiceBus support package, these assemblies can be found in the kernel-only directory.

If you are using the express version, you will need to pull out the source code (above) and compile it yourself using the UnsupportedBuildCoreOnly.bat file.