http://blog.csdn.net/ares1986/article/details/9495527

这个我试过（至少是方法2，方法1我验证下。），但是似乎如果根目录和指定目录都有这个dll会默认先加载根目录的。

你先要弄清楚a.exe在编译时的CPU位数，是AnyCpu还是指定平台？
你可以把两组dll分别放到x86和x64两个子目录中，然后用b程序获取系统位数，并修改a程序的配置文件中指定的程序集搜索目录

建议安装程序时根据环境进行选择

其实我是想以讨论技术的角度直面这个问题。如果想绕过去的话，单这次我完全可以让a和b不在一个路径，但是我不想逃避，如果不行的话，最起码也的达到“这种实现不了”，而不是“我也不知道行不行，反正我是弄不了”。如果能知道为什么不行就更好了。

上面的我理解错了。
a不一定就是.net写的。我现在的情况是并不知道a是什么。所以不能用b来修改。

本来我想把问题抽象出来，希望得到一个技术上的解或者不可行原因，而不是把精力放到如何绕过去。但是好像这样效果不太好。
所以我把问题带入场景描述一下。
现在我正在制造一个自动更新的小轮子。
可能会更新会和任何形式的程序搭配使用，当前的设计是更新程序和实际使用的程序在一个根目录下（当然改成不同目录就百病不犯了）。但是对于Oracle.DataAccess这个讨厌的dll，它有很多个版本而且还分64和32，而我也不知道使用时目标程序会不会有一个不同版本的Oracle.DataAccess放到根目录，但是无论如何Oracle.DataAccess必须对应到他自己版本的其他dll才行比如OraOps10或者OraOps11w（当然也有重名的）。
这样我就希望我这个更新程序不加载根目录的这些dll（管他有没有是啥），只根据32还是64加载相应文件夹下的dll。
但是即使我能加载到指定文件夹下的Oracle.DataAccess，却仍然回去根目录找OraOps10等这些依赖的dll，这样就出现了版本不一样了。

但是即使我能加载到指定文件夹下的Oracle.DataAccess，却仍然回去根目录找OraOps10等这些依赖的dll，这样就出现了版本不一样了。 

程序build之后，所有对此dll的引用均来自于根目录，你动态调用其他目录的dll是不好使的。
解决办法：判断os的版本后，把相应目录的dll拷贝到软件根目录（覆盖当前的）

我一开始就是这样做的，但是因为目标程序用的Oracle.DataAccess和我用的不一样，所以目标程序报错了。
而目标程序并不确定，就算我更换自动更新所引用的Oracle.DataAccess，那么这次好使了，换一个目标程序就又报错了。

或者这样，你加载Oracle.DataAccess这个dll的时候，使用反射，取代先把这个dll添加引用的做法。

正解.使用动态加载dll,而不是静态加载的办法
否则即使你替换了dll文件,程序依然还是报错

在我印象中如果我反射了.\64bit\x.dll，当x.dll去找y.dll的时候它好像还是会去找.\y.dll而不是.\64bit\y.dll这样还是会报错。
而且因为我没法直接使用，也反射不了y.dll