使用 REGASM & 时，不在 GAC 中的程序集的多个搜索路径通讯
我正在创建一个 .NET 程序集，该程序集将注册为 COM，以便 Microsoft Excel VBA 可以引用它。
该程序集引用了不在 GAC 中的第三方 .NET 程序集（包含一些有用的类），但是，我在部署程序集时遇到问题，因为第三方程序集的路径并不总是在相同位置（这取决于用户的区域设置以及第三方程序集的安装时间）。
这意味着，在部署我的程序集（使用 REGASM）时，根据安装它的系统，REGASM 有时会崩溃，因为它无法找到我的程序集对第三方程序集的依赖关系。
理想情况下，我希望在程序集中使用早期绑定，但如果我这样做并且第三方程序集的路径与 Visual Studio 中的引用不同，那么 REGASM 将失败。
我意识到“复制本地”（在VS中）可以解决这个问题，但由于第三方程序集有时会被修补，所以我真的不希望将它的过时版本保留在与我的程序集相同的文件夹中。
有没有办法解决这个问题，这样我就不必使用“复制本地”？我想我可以使用第三方程序集的某种动态加载，但仍然可以使用早期绑定吗？ （REGASM 会起作用吗？）
I am in the process of creating a .NET assembly that will be registered for COM so that it can be referenced by Microsoft Excel VBA.
The assembly references a third-party .NET assembly (that contains some useful classes) that is not in the GAC, however, I have a problem with the deployment of my assembly since the path to the third-party assembly is not always in the same location (it depends on the locale of the user as well as how recently the third-party assembly was installed).
This means that when deploying my assembly (using REGASM), depending on the system that it's being installed on, REGASM will sometimes fall over as it could not find my assembly's dependency on the third-party assembly.
Ideally I would like use early binding in my assembly, but if I do this and the path to the third-party assembly is not the same as the reference in Visual Studio then REGASM will fail.
I realise that "Copy Local" (in VS) would solve this, but as the third-party assembly is sometimes patched then I don't really wish to keep an out of date version of it in the same folder as my assembly.
Is there a way around this so that I don't have to use "Copy Local"? I suppose that I could use some kind of dynamic load of the third-party assembly, but then could still use early binding? (and would REGASM work?)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
为什么不首次使用“复制本地”，并在应用程序启动时设置一个例程，遍历较新版本可能所在的可能位置列表并覆盖（或在无法访问时安排覆盖等）本地程序集如果可能的话。
另外，您可能希望为用户提供一个选项来手动设置应打开 dll 的位置，然后您始终（或按需）检查较新的版本。
另一方面是，如果您的应用程序的功能依赖于某个版本，为什么您要更新新程序集，因为如果他们更改了某个功能或他们提出的任何内容，您的程序将因更新而失败，只是一个想法。
Why not use the 'Copy local' for first use, and have a routine on the application startup that goes thru a list of possible locations where the newer version might be and override (or schedule an override when not accessible etc.) the local assembly if possible.
Also, you might want to give the user an option to manually set a location where the dll should be opened from then you always (or on demand) check for newer versions.
Another aspect is, why would you want to update the new assembly if your application's functionality depends on a certain version, since if they changed a feauture or what ever they efed up something you're program will fail because of the update, just a thought.