为什么不鼓励将程序集标记为 ComVisible(true)? [英] Why is marking an assembly ComVisible(true) discouraged?
问题描述
我总是用 [assembly: ComVisible(true)] 将我的 .NET 程序集标记为对 COM 可见，我认为我永远不知道何时有人可能需要从 COM 调用它们.我也开始使用 FxCop 并开始从代码分析中看到这个警告:
I have always marked my .NET assemblies as visible to COM with [assembly: ComVisible(true)], thinking that I never know when someone might need to call them from COM. I also started using FxCop and started seeing this warning from code analysis:
CA1017:Microsoft.Design:因为MyLibrary.dll"公开了外部可见的类型，所以在程序集级别用 ComVisible(false) 标记它，然后用 ComVisible(true) 标记程序集中应该向 COM 客户端公开的所有类型)
CA1017 : Microsoft.Design : Because 'MyLibrary.dll' exposes externally visible types, mark it with ComVisible(false) at the assembly level and then mark all types within the assembly that should be exposed to COM clients with ComVisible(true)
您为什么不希望所有将您的公共类型暴露给 COM 有什么原因吗?我猜有，但我无法想象这是什么原因.如果有的话，这似乎很不方便.
Is there some reason why you would not simply want all of your public types exposed to COM? I'm guessing that there is, but I cannot imagine what this reason is. If anything, it seems markedly inconvenient.
推荐答案
关键是导出 COM 接口不是免费的，因为存在不兼容和必须满足的要求.这必须考虑并维护.(警告 CA1017 暗示了这一点.)
The key thing is that exporting a COM interface does not come for free as there are incompatibilities and requirements that must be met. This has to be both thought about and then maintained. (Warning CA1017 is alluding to this.)
因此，我一直使用选择加入"的理念而不是选择退出"，即我没有让所有 COM 可见，而是将程序集标记为 COM 不可见.然后，我专注于有选择地公开类型成员(即通过选择加入)，并确保公开的 API 对于 COM 是合理的(例如，COM 不支持泛型、方法重载或带参数的构造函数)并且它具有已在考虑 COM 的情况下进行了测试.通过这种方式，以一种严格、经过测试、有界和可维护的方式向 COM 公开 API.
Therefore I have always worked with the "opt-in" philosophy rather than "opt-out" i.e. rather than making everything COM visible, I mark the assembly as not COM visible. I then concentrate on exposing typesmembers selectively (i.e. by opting in), and make sure that the API that is exposed is sane for COM (e.g. COM does not support generics, method overloading or constructors which take parameters) and also that it has been tested with COM in mind. In this way exposing an API to COM is done in a rigorous, tested, bounded and maintainable fashion.
这与让所有的 COM 可见，然后再担心任何潜在的问题是相反的，请记住，如果你暴露了所有的东西，那么可能会与你的 COM 接口的用户发生耦合，这是你没有预料到的，现在将会有难以退出.
This is the opposite to making everything COM visible and then worrying about any potential issues later, bearing in mind that if you have exposed everything then there may be couplings with users of your COM interface that you did not expect and will now have difficulty backing out of.
凭记忆举几个意外后果的例子:
From memory a couple of examples of unexpected consequences:
在导出重载方法时，默认情况下它们会被导出并使用序列号命名，例如OverloadedMethod1、OverloadedMethod2 等.如果您重构代码并更改方法的顺序或插入重载等，那么任何从您以前的 COM 接口使用这些方法的人都会遇到麻烦.OverloadedMethod1 和 OverloadedMethod2 可能已交换.
When exporting overloaded methods, they are exported and named by default with a sequence number e.g. OverloadedMethod1, OverloadedMethod2, etc. If you refactor your code and change the order of your methods or insert an overload, etc, you are then in trouble with anyone that has used these methods from your previous COM interface. OverloadedMethod1 and OverloadedMethod2 may have been swapped.
暴露给 COM 的类必须有一个无参数的构造函数.如果没有维护此合同的单元测试，那么以后很容易更改该类，使其没有无参数构造函数，从而破坏您的 COM 接口用户.
Classes which are exposed to COM must have a parameterless constructor. If there is not a unit test in place that maintains this contract, then it is easy to change that class at a later date so that it does not have a parameterless constructor and thus breaks your COM interface users.
这篇关于为什么不鼓励将程序集标记为 ComVisible(true)?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
