Recently, we’ve started using PostSharp in our applications (specifically, the OnMethodBoundaryAspect to enhance our logging capabilities) and things have been going smoothly. That is, until today when I wanted to upgrade all of our Newtonsoft.Json references to the latest version (going from 6.0.8 to 7.0.1).
As I worked my way through various projects performing the upgrade, our Web API project wouldn’t build due to PostSharp complaining about not being able to find a previous version of the Newtonsoft.Json assembly. The exact build error was this:
PostSharp.Sdk.CodeModel.AssemblyLoadException: Cannot find assembly ‘newtonsoft.json, version=220.127.116.11, culture=neutral, publickeytoken=30ad4fe6b2a6aeed’. [Version mismatch]
Seemed very strange considering that there was nothing in our codebase that referenced a previous version; I double-checked that all necessary projects did indeed have the latest version. Yet, the build error persisted.
Perplexed, I started pulling every DLL into dotPeek to see if any other third-party library was using an older version. Sure enough, the System.Net.Http.Formatting and System.Web.Http assemblies both referenced a previous version. However, seeing this reminded me that I already had the appropriate binding redirects in our config files and had already modified them to account for the newest version of Newtonsoft.Json, as such:
Some Googling around lead me to this PortSharp forum thread that says to put an MSBuild property named PostSharpHostConfigurationFile in the csproj file and set its value to your config file name, such as web.config or app.config. This requires you to manually edit the csproj file in a text editor and add the following entry:
This property simply tells PostSharp the name of your config file, but in doing so, PostSharp will now read the config file during compilation and use the binding redirects as expected. With PostSharp using the binding redirects, it can now resolve assembly references where it previously couldn’t. Problem solved.