今天在处理客户的一个问题的时候，我们已经把我们SharePoint EventHandler依赖的第三方的TIBCO.EMS.dll注册到GAC里面了，但是日志里面还是抛出了不能加载被引用的第三方的程序集的异常。

在描述解决方案之前，我在这里把相关背景交代一下，我们知道SharePoint提供了Event handler（用户操作事件钩子）让SharePoint用户开发自己的业务逻辑。SharePoint的Event Handler说白了就是，当SharePoint用户操作SharePoint的数据的时候，比如在SharePoint List(列表)中添加一行数据（ListItem）时，这个操作行为会被Event Handler 监听到，我们就可以把我们的业务逻辑写到SharePoint提供的Event Handler的接口中；这样一旦增删改查事件发生后，就会调用在Event Handler里面我们自己写的业务逻辑；在我们自己写的业务逻辑里面可以引用第三方库去实现自己的业务需求；比如在我们自己开发测试的这个环境里面，我们调用了TIBCO.EMS.dll 库去把消息发送到TIBCO的JMS服务器上。这个就是为什么我们需要用GACUtil工具命令把TIBCO.EMS.dll注册到GAC里面去的原因。

OK，基本背景交代完毕，那么现在我们来看具体的问题，当我们把我们自己定制的SharePoint Event Handler依赖的TIBCO.EMS.dll注册到GAC里面了，然后再SharePoint的

网站上面修改一条测试数据。 这个时候，SharePoint Event Handler的事件的的确确触发了，但是却抛出了下面的异常，

 it catchs the excpetion:Could not load file or assembly ‘TIBCO.EMS, Version=1.0.700.12, Culture=neutral, PublicKeyToken=5b83db8ff05c64ba‘ or one of its dependencies. The system cannot find the file specified.

奇怪，我们明明把TIBCO.EMS.dll注册到GAC里面去了，为什么执行Event Handler的IIS的w3wp.exe的后台进程加载不到TIBCO.EMS.dll库呢？这个问题纠结了我不少的时间。

后面在网上找到一篇文章，http://blogs.technet.com/b/speschka/archive/2013/10/26/another-quot-could-not-load-file-or-assembly-quot-error-resolved.aspx 里面描述了和我这边类似的问题，我抱着试一试的态度，把SharePoint的IIS重新启动了一下。

感谢上帝，这个问题解决了。今天花一个小时的时间，把我遇到的这个问题整理出来，希望大家遇到类似的问题后，不要太过于纠结，可以试试重新启动SharePoint的IIS，试试看有没有效果。