Version Mismatch with Custom Controls

It is a known problem that if you utilize a custom controls that references Sitefinity DLL files that are a different version than the DLLs in your Sitefinity site project files, then you will run into Version Mismatch issues.

In the past, the suggestion was to copy the DLLs from your sitefinity site project into the bin folder of the custom control. However - this doesn't work if all you have to work with is a compiled control.

Is there any way to avoid version mismatch issues if using a compiled custom control? This is very important for the marketplace. Not everyone wants to release their control code to the public.

Hello Conrad Ehinger,

This issue is coming from the way the security and assembly signing in .Net framework works. We are having some solutions to this issue, but they are not yet implemented. For the time being, you can provide a readme file, explaining the people how to use the assembly version binding in the web.config - if they are using Sitefinity with version different than x.x.x.x, then they should include a record in the web.config file with the right version. This is similar to the way how we were upgrading the RadControls in the past, in case there's no Sitefinity release with the latest controls:

http://www.sitefinity.com/devnet/kb/sitefinity-3-x/how-to-upgrade-radcontrols.aspx

In the future, our solution would be most probably automatic assembly binding, or independent assembly that contains all the necessary API, and this assembly won't have it's version number changed with the releases.