当我安装加载项（通过复选框）时，有哪些规则/机制可以控制加载项的安装时间？它似乎安装在应用程序级别上，这意味着它适用于excel应用程序中的任何工作簿，直到您自己取消选中它。如果这是正确的，这意味着只要用户自己安装加载项，它们应该没问题;但他们必须第一次安装它（可以通过编程方式完成）。
关于VBA引用，我想这些不需要每次都“检查” - 这意味着它在文档的范围内。但如果这是真的，为什么人们建议在软件准备好分发时使用后期绑定方法？后期绑定真的只是为了使它与不同的版本兼容，但不一定是为了使DLL被“检查”作为参考吗？在这种假设下，只要每个人都使用与我相同版本的Excel，放弃后期绑定是否安全，只需手动添加引用即可？
答案 0 :(得分：3)
使用后期绑定更好，因为您无法保证每个系统都具有相同的可用引用。因此，您应该只选择可以保证将在每台计算机上的引用，并为其余计算机分发DLL文件。
就作用域而言，只要安装并处于活动状态，加载项中的公共subs / functions / variables就可用于应用程序中的任何内容。加载项中的引用只能用于加载项中的例程。
答案 1 :(得分：2)
加载项已安装到应用程序级别。如果需要，您可以使用Ribbon XML微调外接程序如何暴露（或不暴露）到各种工作簿。
只要用户自己安装了添加，就应该没问题;但他们必须第一次安装它
是的，他们必须安装它。
关于VBA参考，我想这些不需要被检查＆＃39;每一次 - 意味着它都在文件的范围内。
是的，版本控制。它还为您省去了必须尝试以编程方式添加引用的麻烦。这可以通过路径（需要知道操作系统，版本等）或GUID（我实际上从未真正成功完成）来完成。然后这两个都需要错误捕获（如果路径不存在或者不可访问的话会怎么样？等等）。所以只需使用后期绑定。
虽然使用早期绑定进行开发是有帮助的，因为智能感知，从用户的角度来看，尽管EB可以说更快，但它们的执行方式通常没有可观察到的差异，对于大多数应用来说，差异通常可以忽略不计。相关的，如果在使用EB时您依赖New关键字来实例化对象，我相信您将与LB一起使用的CreateObject函数实际上更快。但这可能并不明显。
我可以放弃后期绑定，只需手动添加引用即可安全吗？
我只是用EB进行开发，然后在编译外接程序之前将代码修改为后期绑定对象。
答案 2 :(得分：-1)
我在Excel中实现外接程序时遇到了非常困难的时间。
我在工作表上有一些按钮，这些按钮在外接程序中引用代码，在工作表中也有代码在该外接程序中引用功能。真正使我失望的是，我可以停用加载项（选项，加载项，管理，取消选中），并且代码可以继续访问加载项。在外接程序的开发和调试过程中，这尤其令人沮丧，因为我想做的是（在开发过程中）停用外接程序，并让我的应用程序工作表引用打开的外接程序.xlsm开发文件。我花了一段时间才弄清楚的是，由于应用程序工作表中的代码“ References”，它仍在调用.xlam文件中的代码，而不是.xlsm。
一旦我弄清楚了这一点，事情就会变得更顺畅，但是现在，每次我进行更改并想要测试时，我都需要关闭我的应用程序，停用加载项，关闭Excel，将.xlsm保存为.xlam在默认的Excel加载项目录（BTW需要管理员权限）中，打开excel，激活加载项。 [关闭Excel]，打开我的工作簿应用程序。一个彻底的精疲力尽的过程。如果加载项在选中后立即变为活动状态，也许我可以跳过最后一个[Close Excel]步骤。
然后在Win10和Win7上与用户打交道确实使事情变得复杂。默认加载项文件夹的其他路径。用户必须更改引用路径等。非常难看。非常微软。