.NET组件和COM组件之间的相互操作
[ 2005-06-07 13:10:30 | 作者: admin ]
.NET组件和COM组件之间的相互操作
(技术巅峰 2001年10月18日 19:10)
.NET技术是微软大力推广的下一代平台技术,自从.NET技术架构Beta2版本的正式发布,此项技术也逐渐走向成熟和稳定。按照微软的平台系统占有率,我们不难想象得到,在未来的一两年内.NET技术必定会势如破竹一般的登上主流的技术平台,而一个新的技术平台得以快速发展的最重要的前提是:他不会彻底的摒弃以前的技术,这一点对于.NET技术来说指的就是COM/COM+技术了。
一般来说,在IT技术界以及硬件产业,技术的更新换代速度非常得惊人,而惯例是所有的新技术都会遵循向下兼容的原则,但是.NET技术不仅仅做到了这一点,.NET甚至实现了相互之间的各自调用,这一点是非常难能可贵的。也就是说,不但我们可以在.NET组件中调用COM组件,同时也可以在COM组件中正常的调用.NET组件。这点带来的好处是显而易见的,一方面我们可以保持现有的技术资源,另一方面,在现有资源中可以利用.NET所带来的各种新技术。
在开始之前我们先来看一下.NET组件和我们目前常使用的COM组件之间有何不同之处吧。
.NET组件可以分为两大类:共享的.NET组件和私有的.NET组件。
共享的.NET组件需要通过标准公开关键字密码技术来保证自身的唯一性,在这一点上面比较类似于COM的全球唯一ID号码GUID。但是,我们在可能的情况下应当尽量避免使用共享的.NET组件,因为这样将会有可能再一次的陷入目前在视窗系统下长期困扰开发人员的“DLL地狱”。
私有的.NET组件是我们将会经常使用的.NET组件方式,在这种方式之下,我们发布.NET组件需要做的只是简单的进行拷贝操作就可以了,仿佛回到了远古的DOS时代了,在也不必关心纷繁复杂的系统注册表了,也不必担心DLL的版本被覆盖等等的问题了。
而COM组件是微软曾经力推了很多年的一种代码复用的技术框架,在这些年里也得到了极大的发展和应用,但它的弊端却也日益明显,我们不得不面对众多的COM组件之间的版本控制和令人恐怖的DLL地狱,还有注册表、GUID等等。在我们安装一个软件的同时,也带来了大量的我们所未知的版本繁多的COM组件到我们的操作系统中。
但是,COM组件的技术优势也是明显的,在很大的程度上实现了Windows平台下的代码复用,所以我们才会提出这样的一个话题,如何才能在.NET技术日臻成熟的情况下,保护和利用已经存在的大量的采用COM技术的软件和产品呢?
下面我们就探讨一下,如何实现.NET组件和COM组件之间的相会调用和操作。
首先,我们来看看在现有的COM组件中如何调用.NET编写的组件吧:
在这里我们使用C#编写一个最简单的组件,仅仅实现返回一个字符串,详细的代码如下:
在上面的.NET组件当中我们实现了一个类成员:say。他的用途是简单的返回一段字符串。
切换到MS-DOS命令行下面,运行:
C:\>csc /t:library /out ClassLibrary1.DLLClassLibrary1.cs
上面的编译器参数/t:library 告诉C#编译器我们现在是在建立一个库应用程序。这样,我们就得到了一个名称为ClassLibrary1.DLL的.NET组件了。
但是想要在现有的COM组件中使用这个组件,我们还有进行如下步骤:
切换到MS-DOS命令行下面,运行:
C:\>regasm out ClassLibrary1.DLL /regfile:ClassLibrary1.reg
上面的命令行是注册我们的.NET组件,并且产生了一个备用的注册表文件。大家一定会记得在以前我们的win9x/NT/2000下面注册COM组件使用的命令是:
regsvr32 c:\test.dll
在.NET下面,注册.NET组件就需要上面的regasm命令了,值得注意的是,这个方法仅仅是为了可供COM组件来调用,.NET本身之间相互调用组件是不需要任何注册的!
还没有结束呢,接下来我们需要:
切换到MS-DOS命令行下面,运行:
C:\>tlbExp ClassLibrary1.dll /out:ClassLibrary1.tlb
上面的命令行表示将会产生一个.NET组件的类型库,目的是为了我们在COM组件中进行提前绑定操作。
好了,接下来我们就可以在自己的基于目前COM技术的代码中方便的使用上面我们使用C#编写的.NET组件了。在这里,我们使用VB6.0编写一个小小的测试代码,在开始之前我们需要在VB的集成环境中使用菜单中的“引用”选项,选择我们刚才产生的类型库文件ClassLibrary1.tlb。
VB测试的代码如下:
Private Sub Form_Load()
Dim test As New ClassLibrary1.hello
Dim str As String
str = test.say("dddd")
MsgBox str
End Sub
接下来,我们就来看看,如何在.NET组件中使用目前存在的COM组件吧。
对于.NET来讲,使用COM组件要想对简单一些。.NET在设计之初就考虑到了如何方便的利用现有的各种技术资源,这也是微软的一贯作风,.NET的强大之处也可见一斑。.NET提供了大量的类库来方便的实现同COM的相互操作,其中很重要的一个名称空间就是:System.Runtime.InteropServices。通过这个名称空间的名字我们也可以从字面上看出,“互操作服务”。System.Runtime.InteropServices这个名称空间提供了一系列的类来对COM对象进行操作。
下面的例子中,我们来调用一下系统自带的Win32函数MessageBoxA,这个函数位于系统的COM组件user32.dll当中,我们调用的代码如下:
using System;
using System.Runtime.InteropServices;
class Test
{
[DllImport("user32.dll")]
public static extern int MessageBoxA(inthWnd,string strMsg,string strCaption,intnType);
public static void Main()
{
int myMsg;
myMsg=MessageBoxA(0,"Hello!","test",0);
}
}
切换到MS-DOS命令行下面,运行:
C:\>csc Test.cs
编译完毕我们的C#应用程序之后,直接运行就可以看到对话框了!
需要注意的是,在调用COM组件之前,我们需要在.NET程序中引用名称空间:System.Runtime.InteropServices。因为我们需要使用这个名称空间所提供的一个方法:DllImport。
怎么样,在.NET中使用COM组件是非常的方便的吧。上面是我们调用的系统本身自带的DLL组件,同样的,也可以使用这种方法来调用我们自己使用VB/VC编写的COM组件。
好了,我们已经探讨完了如何在.NET和COM之间相互操作了,我们也很显然的看到了.NET技术的强大,现在越早掌握.NET技术就会在未来越容易的占领领先的位置,让我们共同努力掌握强大的.NET平台技术吧。
(以上程序在Windows2000 server+VS.NET Beta2下测试通过)
(技术巅峰 2001年10月18日 19:10)
.NET技术是微软大力推广的下一代平台技术,自从.NET技术架构Beta2版本的正式发布,此项技术也逐渐走向成熟和稳定。按照微软的平台系统占有率,我们不难想象得到,在未来的一两年内.NET技术必定会势如破竹一般的登上主流的技术平台,而一个新的技术平台得以快速发展的最重要的前提是:他不会彻底的摒弃以前的技术,这一点对于.NET技术来说指的就是COM/COM+技术了。
一般来说,在IT技术界以及硬件产业,技术的更新换代速度非常得惊人,而惯例是所有的新技术都会遵循向下兼容的原则,但是.NET技术不仅仅做到了这一点,.NET甚至实现了相互之间的各自调用,这一点是非常难能可贵的。也就是说,不但我们可以在.NET组件中调用COM组件,同时也可以在COM组件中正常的调用.NET组件。这点带来的好处是显而易见的,一方面我们可以保持现有的技术资源,另一方面,在现有资源中可以利用.NET所带来的各种新技术。
在开始之前我们先来看一下.NET组件和我们目前常使用的COM组件之间有何不同之处吧。
.NET组件可以分为两大类:共享的.NET组件和私有的.NET组件。
共享的.NET组件需要通过标准公开关键字密码技术来保证自身的唯一性,在这一点上面比较类似于COM的全球唯一ID号码GUID。但是,我们在可能的情况下应当尽量避免使用共享的.NET组件,因为这样将会有可能再一次的陷入目前在视窗系统下长期困扰开发人员的“DLL地狱”。
私有的.NET组件是我们将会经常使用的.NET组件方式,在这种方式之下,我们发布.NET组件需要做的只是简单的进行拷贝操作就可以了,仿佛回到了远古的DOS时代了,在也不必关心纷繁复杂的系统注册表了,也不必担心DLL的版本被覆盖等等的问题了。
而COM组件是微软曾经力推了很多年的一种代码复用的技术框架,在这些年里也得到了极大的发展和应用,但它的弊端却也日益明显,我们不得不面对众多的COM组件之间的版本控制和令人恐怖的DLL地狱,还有注册表、GUID等等。在我们安装一个软件的同时,也带来了大量的我们所未知的版本繁多的COM组件到我们的操作系统中。
但是,COM组件的技术优势也是明显的,在很大的程度上实现了Windows平台下的代码复用,所以我们才会提出这样的一个话题,如何才能在.NET技术日臻成熟的情况下,保护和利用已经存在的大量的采用COM技术的软件和产品呢?
下面我们就探讨一下,如何实现.NET组件和COM组件之间的相会调用和操作。
首先,我们来看看在现有的COM组件中如何调用.NET编写的组件吧:
在这里我们使用C#编写一个最简单的组件,仅仅实现返回一个字符串,详细的代码如下:
在上面的.NET组件当中我们实现了一个类成员:say。他的用途是简单的返回一段字符串。
切换到MS-DOS命令行下面,运行:
C:\>csc /t:library /out ClassLibrary1.DLLClassLibrary1.cs
上面的编译器参数/t:library 告诉C#编译器我们现在是在建立一个库应用程序。这样,我们就得到了一个名称为ClassLibrary1.DLL的.NET组件了。
但是想要在现有的COM组件中使用这个组件,我们还有进行如下步骤:
切换到MS-DOS命令行下面,运行:
C:\>regasm out ClassLibrary1.DLL /regfile:ClassLibrary1.reg
上面的命令行是注册我们的.NET组件,并且产生了一个备用的注册表文件。大家一定会记得在以前我们的win9x/NT/2000下面注册COM组件使用的命令是:
regsvr32 c:\test.dll
在.NET下面,注册.NET组件就需要上面的regasm命令了,值得注意的是,这个方法仅仅是为了可供COM组件来调用,.NET本身之间相互调用组件是不需要任何注册的!
还没有结束呢,接下来我们需要:
切换到MS-DOS命令行下面,运行:
C:\>tlbExp ClassLibrary1.dll /out:ClassLibrary1.tlb
上面的命令行表示将会产生一个.NET组件的类型库,目的是为了我们在COM组件中进行提前绑定操作。
好了,接下来我们就可以在自己的基于目前COM技术的代码中方便的使用上面我们使用C#编写的.NET组件了。在这里,我们使用VB6.0编写一个小小的测试代码,在开始之前我们需要在VB的集成环境中使用菜单中的“引用”选项,选择我们刚才产生的类型库文件ClassLibrary1.tlb。
VB测试的代码如下:
Private Sub Form_Load()
Dim test As New ClassLibrary1.hello
Dim str As String
str = test.say("dddd")
MsgBox str
End Sub
接下来,我们就来看看,如何在.NET组件中使用目前存在的COM组件吧。
对于.NET来讲,使用COM组件要想对简单一些。.NET在设计之初就考虑到了如何方便的利用现有的各种技术资源,这也是微软的一贯作风,.NET的强大之处也可见一斑。.NET提供了大量的类库来方便的实现同COM的相互操作,其中很重要的一个名称空间就是:System.Runtime.InteropServices。通过这个名称空间的名字我们也可以从字面上看出,“互操作服务”。System.Runtime.InteropServices这个名称空间提供了一系列的类来对COM对象进行操作。
下面的例子中,我们来调用一下系统自带的Win32函数MessageBoxA,这个函数位于系统的COM组件user32.dll当中,我们调用的代码如下:
using System;
using System.Runtime.InteropServices;
class Test
{
[DllImport("user32.dll")]
public static extern int MessageBoxA(inthWnd,string strMsg,string strCaption,intnType);
public static void Main()
{
int myMsg;
myMsg=MessageBoxA(0,"Hello!","test",0);
}
}
切换到MS-DOS命令行下面,运行:
C:\>csc Test.cs
编译完毕我们的C#应用程序之后,直接运行就可以看到对话框了!
需要注意的是,在调用COM组件之前,我们需要在.NET程序中引用名称空间:System.Runtime.InteropServices。因为我们需要使用这个名称空间所提供的一个方法:DllImport。
怎么样,在.NET中使用COM组件是非常的方便的吧。上面是我们调用的系统本身自带的DLL组件,同样的,也可以使用这种方法来调用我们自己使用VB/VC编写的COM组件。
好了,我们已经探讨完了如何在.NET和COM之间相互操作了,我们也很显然的看到了.NET技术的强大,现在越早掌握.NET技术就会在未来越容易的占领领先的位置,让我们共同努力掌握强大的.NET平台技术吧。
(以上程序在Windows2000 server+VS.NET Beta2下测试通过)
评论Feed: http://blog.xg98.com/feed.asp?q=comment&id=111
这篇日志没有评论。
此日志不可发表评论。