I grabbed code out of SVN for an existing Custom Resolver, made some updates thenÂ compiled and deployed to the GAC on the client’s development environment.
Publishing now gave an error:
Could not load file or assembly 'Tridion.ContentManager.Publishing, Version=188.8.131.523, Culture=neutral, PublicKeyToken=360aac4d3354074b' or one of its dependencies. The system cannot find the file specified.
Upon decompilation of both the original and my new custom resolver DLLs I found that the original had been built against Tridion DLLs of version 184.108.40.2066 (Tridion 2011) and my new one against Tridion DLLs of version 220.127.116.113 (Tridion 2013).Â Of course I was going to get an error because my client is running 2011 and my compiled DLL had been built against 2013.
But how had I built the custom resolver against 2013 DLLs without realising?
Turns out that the original developer had stored the Tridion 2011 DLLs in a centralised folderÂ within SVN to which they were referencing within the custom resolver Visual Studio project, however the referenced files had been moved and no longer existed at that location. Visual Studio had taken the DLLs from the GAC of the machine on which I had built the project. This machine had Tridion 2013 installedÂ and soÂ the custom resolver wasÂ compiled against 2013 DLLs without me even realising!
To fix it I simply updated the references to the correct location in SVN and all was good.
It’s a good idea to copyÂ the suitable version of Tridion DLLs to a centralised folder to which you always make reference. PerhapsÂ something like //dependencies/Tridion/2011/[DLLs go here]. This can be committed into your source control so all developers have them when needed. However, always check that Visual Studio has resolved the DLLs correctly in case of strange build version errors, especially for a project that hasn’t been touched for a while!