保持COM暴露的组件同步与.NET的引用程序集的最佳方法 [英] Best way to keep COM-exposed assemblies in sync with .NET-referenced assemblies

查看:176
本文介绍了保持COM暴露的组件同步与.NET的引用程序集的最佳方法的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个C#,COM暴露的.NET程序集,我用大量的VB6的客户端(办公室VBA)库。我感到非常高兴。

I have a C#, COM-exposed .NET assembly, which I use heavily as a library for VB6 clients (Office VBA). I am extremely happy with it.

这同一个COM暴露库在一些较新的,.NET客户端我已经写以及对我来说是非常有用的。从谷歌搜索,达成的共识是,要做到这一点的唯一方法是引用.NET库本身(<一href="http://stackoverflow.com/questions/15014266/why-cant-a-net-com-library-be-used-via-com-in-net">link 1 ,<一个href="http://stackoverflow.com/questions/368001/is-it-possible-to-test-a-com-exposed-assembly-from-net">link 2 ),这是我做的事。

That same COM-exposed library is useful for me in some newer, .NET clients I have written as well. From Googling, the consensus is that the only way to do this is to reference the .NET libraries themselves (link 1, link 2), which I have done.

在这些.NET应用程序的部署,VS自然希望能够把我的COM .NET程序集他们。但我现在有我的COM组件,在除了它被注册为有问题的机器的COM对象我的.NET apps--左右浮动几个独立的副本。

When these .NET apps are deployed, VS naturally wants to bring my COM .NET assemblies with them. But I now have several, independent copies of my COM assembly floating around with my .NET apps-- in addition to it being registered as a COM object on the machines in question.

这意味着,每一次我做一个bug修复或功能添加到我的COM,我需要更新这些浮动的副本,以及;这使得在最好的保养恼人。我要公开我需要的功能的一次的,对于所有使用它的应用程序(不是COM的目的是什么?!)

This means that every time I make a bug fix or add functionality to my COM, I need to update these "floating" copies as well; which makes maintenance annoying at best. I want to expose my needed functionality once, for all apps that use it (isn't that the purpose of COM?!)

我尝试使用后期绑定激活COM,希望我能得到周围的problem--,但我得到了两个不同的机器不同的行为,所以我决定放弃这一想法。

I tried activating the COM using late binding, hoping I could get around the problem-- but I got different behavior on two different machines, so I decided to ditch that idea.

有一种优雅的方式来处理呢?我想也许这将是有意义的注册安装时在GAC中的COM组件,但它只是似乎是错误的做法,因为它已经注册为COM(加,好像登记在GAC中的not好的做法)。

Is there an elegant way to handle this? I thought perhaps it would make sense to register the COM assembly in the GAC upon installation, but it just seems like the wrong thing to do since it's already registered as COM (plus, it seems like registering in the GAC is not considered good practice).

推荐答案

我相信来管理这种情况下最简单的方法就是分发COM组件作为一个单独的部署中安装程序集到GAC。当添加组件参考.NET项目,使在基准确定复制本地属性设置为False。这告诉.NET版本不包含组件的部署副本,这确保了无论是部署.NET应用程序和VB6应用程序都引用相同的版本(安装在GAC和注册COM服务的)

I believe the easiest way to manage this scenario is to distribute the COM assemblies as a separate deployment that installs the assemblies to the GAC. When adding the assembly reference to the .NET projects, make sure the Copy Local property on the reference is set to False. This tells the .NET build to not include a copy of the assembly in the deployment, which ensures that both the deployed .NET app and the VB6 apps are both referencing the same version (the one installed in the GAC and registered with COM services)

这篇关于保持COM暴露的组件同步与.NET的引用程序集的最佳方法的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆