tag:blogger.com,1999:blog-7125820631218721012.post6096683642359014329..comments2023-06-29T15:29:32.150+01:00Comments on Martin on .Net: EKTRON: Diagnosing 8.0 Extension Strategy Loading FailuresMartinJarvishttp://www.blogger.com/profile/01826075571790729681noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-7125820631218721012.post-15211139228361665202010-11-21T15:27:49.998+00:002010-11-21T15:27:49.998+00:00Very Good ArticleVery Good ArticleUnknownhttps://www.blogger.com/profile/07334368598909982942noreply@blogger.comtag:blogger.com,1999:blog-7125820631218721012.post-6761662317410327332010-11-19T10:38:52.600+00:002010-11-19T10:38:52.600+00:00Well, the specifics are bit complicated. Essentia...Well, the specifics are bit complicated. Essentially, I have a set of libraries that wrap the Ektron API which we build against the different versions of Ektron that we support (7.6.1->8.0.1). The idea is that we code against our library in a consitent manner and the library handles the different API implementations/workaround as required.<br /><br />There was a bug with our Automated Build process which meant this specific library was built against 7.6.1 not 8.0.1. So was dependent on previous versions assemblies (including EktronBase.dll which is used for the equivalent plugin functionality - which isn't deployed within the website).<br /><br />The report that I implemented highlighted the versioning issue (as the assembly versions include the Ektron api version ie 1.801.XXXX.XXXX or 1.761.XXXX.XXXX). <br /><br />However, the mismatched dependency issue would also apply for libraries that were dependent on different versions of 3rd Party library.<br /><br />There are a lot of other causes for this type of failure and the only way to determine the appropriate fix is to inspect the exception detail.MartinJarvishttps://www.blogger.com/profile/01826075571790729681noreply@blogger.com