将现有VBA引用的位置从C：\ Windows \ system32 \更改为共享驱动器
我一直在试图得到一个参考文件被加载外部无济于事。
具体来说，我试图加载一个“Microsoftdate和时间select器控制6.0（SP4）”通常驻留在C：\ Windows \ System32 \ MSCOMCT2.OCX
然而，一些运行包含这个元素的macros的人在他们的PC上没有这个“MSCOMCT2.OCX”文件，所以我想我会把MSCOMCT2.OCX移到一个共享位置，并引用代码来使用共享的代码（所以每个人都可以访问它）
我试图做到这一点，但当我试图从另一个位置加载一个引用“浏览”它没有加载它 – 因为我已经在C中：..
所以我认为确定…我将从C：\删除文件，所以我只能引用共享文件。 – 所以我删除它。 所以我再次打开工作簿，看看引用 – 我找不到“Microsotft Windows公共控制-2.6.0（SP4）” – 太棒了！ 我继续从共享驱动器中手动添加浏览。 但是当我这样做时，正在添加2个“Microsotft Windows Common Controls-2.6.0（SP4）”引用 – 1个来自C：\（不存在），1个来自共享驱动器。
C：\中的一个始终是自动select的。 如果我试图从C：\中禁用一个，并启用共享驱动器中的一个，它会自动变回原来的状态。 如果我尝试启用两个 – 它说重复的引用，并保持只有一个从C：\
所以..有没有人知道我怎么能摆脱列表中的C：\参考，所以它不会被加载？ 显然删除文件本身没有工作。 最终我的目标是使没有C：\ Windows \ System32 \ MSCOMCT2.OCX文件的人能够使用我的date选取器工具。
非常感谢！
ActiveX控件重新引用始终是基于GUID的。 VB IDE会向您显示您的计算机上registry中列出的文件的当前位置，作为礼貌，但是它的含义并不重要。 该控件将从用户计算机上注册的任何地方加载。
这是关键：控制必须在用户的计算机上注册。
我必须强烈地劝阻你做你想做的事情。 你也许可以编制一个方法，通过它从networking位置加载DLL，但是它没有做正确的事情（TM）没有什么优势，还有很多问题。 正确的事情就是，如果你需要这个控制，你必须像应用程序一样分发和注册它。 你真的应该把它安装在它的推荐位置（System32）; 不在networking上。
以下是可能出错的一个简单示例：您为用户提供应用程序，并且可以像networking上的控件一样使用它。 然后用户安装恰好需要相同控制的另一个应用程序。 该应用程序的安装程序发现该控件已经在用户的计算机上注册，因此不会再尝试添加该控件。 除了这个特定的应用程序是打算在用户没有连接到networking时使用。 现在你只是打破了别人的节目。
VB / VBA架构从来不打算支持XCOPY部署。 我知道这是一个痛苦，而当你只是想部署一个“macros”时，这些额外的步骤是非常不方便的。 可悲的是，这是野兽的本质。 对不起