为什么我不应该使用 AutoDual? [英] Why should I not use AutoDual?
问题描述
到目前为止，我一直使用 [AutoDual] 属性修饰我想从 VB6 使用的 .NET 类.关键是在 VB6 环境中获得对 .NET 对象的 Intellisense.但是，前几天我在 Google 上搜索了 AutoDual，第一个答案是不要使用 AutoDual".
Up to now, I've always decorated my .NET classes that I want to use from VB6 with the [AutoDual] attribute. The point was to gain Intellisense on .NET objects in the VB6 environment. However, the other day I googled AutoDual and the first answer is 'Do Not Use AutoDual'.
我一直在寻找关于为什么我不应该使用它的连贯解释，但找不到.
I've looked for coherent explanation of why I shouldn't use it, but could not find it.
有人能解释一下吗?
推荐答案
我觉得总结如下:
使用双接口的类型允许客户端绑定到特定的界面布局.任何变化未来版本的布局类型或任何基本类型都会破坏 COM绑定到接口的客户端.经过默认，如果ClassInterfaceAttribute 属性是未指定，仅调度使用接口.
Types that use a dual interface allow clients to bind to a specific interface layout. Any changes in a future version to the layout of the type or any base types will break COM clients that bind to the interface. By default, if the ClassInterfaceAttribute attribute is not specified, a dispatch-only interface is used.
http://msdn.microsoft.com/en-us/library/ms182205.aspx
当类被改变时，它增加了使用自动双重属性改变该类中的某些内容会破坏其他人的代码的可能性.如果让消费者有能力做一些很可能在未来引起他们问题的事情.
It increases the possibility that changing something in that class with the auto dual attribute will break someone else's code when the class is changed. If gives the consumer the ability to do something that will quite possibly cause them issues in the future.
下一个选项是 ClassInterfaceType.AutoDual.这也是获得早期绑定支持的快速而肮脏的方法(并使这些方法显示在 VB6 IntelliSense 中).但是通过更改方法的顺序或添加新的重载也很容易破坏兼容性.避免使用 AutoDual.
The next option is ClassInterfaceType.AutoDual. This is the quick and dirty way to get early binding support as well (and make the methods show up in VB6 IntelliSense). But it's also easy to break compatibility, by changing the order of methods or adding new overloads. Avoid using AutoDual.
http://www.dotnetinterop.com/faq/?q=ClassInterface
我终于找到了关于 AutoDual 发生了什么以及它是如何工作的链接:
I finally found the link that talks about what is going on with AutoDual and how it works:
针对 AutoDual 的警告不是事实上，双接口不好，但它自动生成的事实COM 接口为您服务.那很不好.每次 COM 接口必须重新生成你会得到一个新的 GUID 和潜在的新成员.如果 GUID改变然后你得到一个全新的就 COM 而言的接口/类担心的.对于早期绑定，你会每次都必须重建客户端界面已重新生成.这首选的方法是定义COM 类接口显式地带有图形用户界面.然后所有的早期绑定客户端可以使用定义的接口不用担心它会改变他们在开发过程中.因此推荐的选项是 None to tellCLR 不会自动生成它你.您仍然可以实现对偶如果你需要它的接口.
The warning against AutoDual isn't the fact that dual interfaces is bad but the fact that it auto-generates the COM interface for you. That is bad. Each time the COM interface has to be regenerated you'll get a new GUID and potentially new members. If the GUID changes then you get a brand new interface/class as far as COM is concerned. For early binding you'd have to rebuild the clients each time the interface was regenerated. The preferred approach is to define the COM class interface explicitly with a GUID. Then all the early binding clients can use the defined interface and not worry about it changing on them during development. That is why the recommended option is None to tell the CLR not to auto-generate it for you. You can still implement the dual interface though if you need it.
这篇关于为什么我不应该使用 AutoDual?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
