将现有 VBA 引用的位置从 C:\Windows\system32\ 更改为共享驱动器

Changing the location of an existing VBA Reference from C:\Windows\system32\ to a shared drive

提问by Potter Rafed

I've been trying for a while now to get a reference file to be loaded externally to no avail.

我已经尝试了一段时间来获取要从外部加载的参考文件，但无济于事。

To be specific I am trying to load a "Microsoft Date and Time Picker Control 6.0(SP4)" which usually resides in C:\Windows\System32\MSCOMCT2.OCX

具体来说，我正在尝试加载通常位于 C:\Windows\System32\MSCOMCT2.OCX 的“Microsoft Date and Time Picker Control 6.0(SP4)”

However some people that run a macro containing this element don't have that "MSCOMCT2.OCX" file on their PCs so I thought I will move the MSCOMCT2.OCX to a shared location and reference the code to use the shared one instead (so everyone will have access to it)

然而，一些运行包含此元素的宏的人在他们的 PC 上没有那个“MSCOMCT2.OCX”文件，所以我想我会将 MSCOMCT2.OCX 移动到共享位置并引用代码以使用共享的（所以每个人都可以访问它）

I tried doing that but when I was trying to load a reference with "Browse" from a different location it didn't load it - because I already had that in C:..

我尝试这样做，但是当我尝试从其他位置加载带有“浏览”的引用时，它没有加载它 - 因为我已经在 C:..

So I thought OK... I will remove the file from C:\ so I can only reference the shared file. - so I deleted it. So I open the workbook again and look at references - I cant find "Microsotft Windows Common Controls-2.6.0(SP4)" - great! And I proceed to add it manually with Browse from the shared drive. When I do that however 2 references of "Microsotft Windows Common Controls-2.6.0(SP4)" are being added - 1 from C:\(which is not there) and 1 from the shared drive.

所以我想好...我将从 C:\ 中删除文件，所以我只能引用共享文件。- 所以我删除了它。所以我再次打开工作簿并查看参考资料——我找不到“Microsotft Windows Common Controls-2.6.0(SP4)”——太棒了！然后我继续使用共享驱动器中的浏览手动添加它。但是，当我这样做时，会添加 2 个“Microsotft Windows Common Controls-2.6.0(SP4)”的引用 - 1 个来自 C:\（不存在），1 个来自共享驱动器。

The one from C:\ is always automatically selected. If I try to disable the one from C:\ and enable the one from the shared drive it automatically changes back to what it was when i press OK. If I try to enable both - it says duplicate References and keeps only the one from C:\

始终自动选择 C:\ 中的那个。如果我尝试从 C:\ 禁用它并从共享驱动器启用它，它会在我按 OK 时自动变回原来的状态。如果我尝试启用两者 - 它会显示重复的引用并且只保留一个来自 C:\

So.. does anybody know how can I get rid of that C:\ reference from the list so it doesn't get loaded? Apparently deleting the files themselves did not work. Ultimately my goal is to enable people without C:\Windows\System32\MSCOMCT2.OCX file to be able to use my Date Picker Tool.

那么.. 有谁知道我怎样才能从列表中删除那个 C:\ 引用，这样它就不会被加载？显然，删除文件本身不起作用。我的最终目标是让没有 C:\Windows\System32\MSCOMCT2.OCX 文件的人能够使用我的日期选择器工具。

Thanks a lot!

非常感谢！

回答by Euro Micelli

ActiveX control rereferences are alwaysGUID-based. The VB IDE shows you the current location of the file as listed in the registry on your computer, as a courtesy, but it really doesn't matter what it says. The control will be loaded from wherever it was registered on the user's computer.

ActiveX 控件重新引用始终基于 GUID。VB IDE 会向您显示您计算机上注册表中列出的文件的当前位置，这是出于礼貌，但实际上它说的是什么并不重要。该控件将从它在用户计算机上注册的任何位置加载。

That's the key: the control must be registered on the user's computer.

这就是关键：控件必须在用户的计算机上注册。

I must strongly discourage you from doing what you're trying to do. You might be able to concoct a method by which you load the DLL from a network location, but it presents no advantage over doing the Right Thing(TM), and plenty of problems. The Right Thing is simply that if you need that control, you must distribute and register it with your application, just like everybody else does. And you really should install it in the recommended location for it (System32); not on the network.

我必须强烈劝阻你不要做你想做的事。您也许可以编造一种方法，通过该方法从网络位置加载 DLL，但它比做正确的事 (TM) 没有任何优势，并且存在很多问题。正确的做法很简单，如果您需要这种控制，您必须像其他人一样在您的应用程序中分发和注册它。你真的应该将它安装在推荐的位置（System32）；不在网络上。

Here's a quick example of what can go wrong: you provide your user with you app, and it works with the control on the network like you want it. Then the user installs another application that happens to need the same control. The app's installer sees that the control is already registered on the user's computer, so it doesn't try to add it again. Except that this particular app is intended to be used when the user is not connected to a network. Now you just broke someone else's program.

这是一个可能出错的简单示例：您向用户提供您的应用程序，并且它可以像您想要的那样与网络上的控件一起使用。然后用户安装另一个恰好需要相同控件的应用程序。应用程序的安装程序看到该控件已在用户的计算机上注册，因此不会尝试再次添加它。除了此特定应用程序旨在在用户未连接到网络时使用。现在你只是破坏了别人的程序。

The VB/VBA architecture was never intended to support XCOPY deployment. I'm know it's a pain and that these extra steps are extremely inconvenient when you're just trying to deploy a "macro". Sadly, it's the nature of the beast. I'm sorry

VB/VBA 体系结构从未打算支持 XCOPY 部署。我知道这很痛苦，而且当您只是尝试部署“宏”时，这些额外的步骤非常不方便。可悲的是，这是野兽的本性。抱歉