Electronic Joint Business

Solution for E-Business

clr

托管C++ (一) C++/CLI的诞生

Managed C++

和通常的VC++不同,托管(Managed) 是.NET的一个专门概念,它是融于通用语言运行时(CLR)中的一种新的编程理念,通用语言运行时是.NET 框架应用程序的执行引挚。它提供了许多服务,其中包括:代码管理(装入和执行)、类型安全性验证、元数据(高级类型信息)访问、为管理对象管理内存、管理代码,COM对象和预生成的DLLs(非管理代码和数据)的交互操作性、对开发人员服务的支持等等。 也就是说,托管C++意味着,我们的代码可以被CLR所管理,并能开发出具有最新特性如垃圾自动收集、程序间相互访问等的.NET框架应用程序。

  可见,Managed C++(下称MC++)是有别于原来的C++(下称VC++)的一种新的而且十分特殊的.NET语言。

MC++ 的特殊之处在于 Micorsoft 为 MC++ 提供了一种称之为“it just works”的Interop机制,后称“Interop技术”。即对程序中的每一个本地方法,MC++ 编译器同时生成一个托管和非托管进入点,它们中只有一个是真正方法的实现,另一个则是转发器,可进行相应的转换和必要的调度。托管进入点通常是真正方法的实现,除非代码不能解释为MSIL或开发者使用“#pragma unmanaged”强制指定进入点的实现为本地机器码。当一个 IJW 转发器起作用时——例如转发到本地代码中,编译器提供转换的实现,并且通过偏移或 IAT(Import Address Table)调用实际的实现代码;因此用 MC++ 编写的程序同时拥有托管代码和非托管代码。

我们先来看一下这个例子。在这个例子中,我们混合使用了托管代码和非托管代码。在托管代码中,我们不能使用类似嵌入汇编等等许多特性,这就是为什么同时使用托管和非托管代码有时很重要。

>>> 阅读全文

 

, ,

Ironruby与CLR语言的互操作性 (二)

引用 .NET 的 Assembly
除了我们前面提到的 require <PartialName> 和 require <Strongname> 外,Ironruby 1.0发布的时候,还提供了一个新的函数 load_assembly,这个函数的参数为 Assembly 的名称,在内部,load_assembly 会先调用 Assembly.Load,如果找不到这个 Assembly,那就再调用 Assembly.LoadWithPartialName。它也支持 require 的两种调用方法。除此之外,load_assembly 还可以接受第二个参数,指明只引用该 Assembly 下的某个名称空间,比如:

load_assembly ‘IronRuby.Libraries’, ‘IronRuby.StandardLibrary.StringIO’

名称空间
当装配件被加载之后,它的顶层名称空间和类在 ironruby 内是可见的。比如下面这个例子

namespace Models {  
  public class Person {  
    private string name;  
    public Person(string name) {  
      this.name = name;  
    }  
    public string Name {    
      get {  
        return name;  
      }  
    }  
  }

上面C#代码的名称空间“Models”与普通的ruby模块一样可被存取:

>>> require ‘models’  
=> true  
>>> Models  
=> Models  
>>> Models.class  
=> Module

需要注意几点:

  • 1.不可用小写的名称空间:Ruby 常量要求使用大写开头的名字,所以名称空间必须遵循 Ironruby 的要求。
  • 2.不可用“空”的名称空间: 对 IronRuby 来说,名称空间不能为空。而且由于 CLR 的名称空间只在有可访问的子类时才存在,因此假如名称空间的所有子类都是私有的,IronRuby 将无法访问该名称空间。所以名称空间内至少要有一个公共的可访问类。

因为名称空间被视为 Ironruby 的普通模块,所以它和其他 ruby 模块一样,可以被 mixin.

>>> 阅读全文

 

, , , , ,

Ironruby与CLR语言的互操作 (一)

ironruby 是 .Net 平台下的一个 ruby 实现,众所周知,ruby 吸取了 Perl,python 等脚本语言的灵活性,带有实体对象模型,是一门动态/解释语言。从进入 ironruby 0.9.1 之后,ironruby 日趋稳定,之后发布的 Ironruby 1.0,兼容于 ruby 1.8.6,1.1 版本则增加了了对 .NET 扩展方法的支持,可以完美的运行 LINQ,目前开发中的 Ironruby 1.1.1 则是第一个兼容 ruby 1.9.2 的版本。

由于 IronRuby 是基于 .NET DLR,因此你可以在 IronRuby 中调用任何已有的 .NET 代码。这意味着可以在 IrongRuby 中使用任何框架,比如 Windows Forms、WPF 或者 GTK(#),因为.NET 和 Mono(分)拥有对这些框架的 CLI 绑定。Mono 甚至有一个使用GTK 实现的 Windows Forms,这样应用程序无须修改就可以运行在两个实现上。

Ironruby与CLR语言的互操作
IronRuby 带来的改变:
1. 与静态语言的互操作:IronRuby 与 .NET 框架集成的非常紧密,在 IronRuby 中调用 C#/VB 代码不会感觉是在使用“互操作”。C# 也可以通过 DLR Hosting API 调用 IronRuby 代码。而在 .NET 4.0 中,动态方法分配已经成为了 C# 的一部分,因此在 C# 中调用 IronRuby 代码和调用 C# 方法差不多。由于 IronRuby 基于 DLR,因此也可以方便的与其它 DLR 语言进行交互,如今 Python 和 Ruby 可以很好的合作,未来的 DLR 语言也一样可以。

2. 更稳定且丰富的支持,你可以抛弃 rubyforge 上许多质量不高的无人维护的 gems,改用 .Net 自身丰富的资源,你可以放弃ruby 中频繁变更的 win32api,而使用 .net 的 p/invoke,你可以放弃无人维护的 fireruby,而简单用 .net firebird provider 为自己添加 firebird 的 activerecord 支持而不用再担心找不到数据库的 activerecord 支持。

3. 为 .Net 带来 Rails,基于 Ironruby 0.9.2 你只需要对 rails 2.3.4 做一些小小的修改,就可以在 CLR/DLR 上运行最新的Rails,同时使用 Ironruby 也可以为.Net 的 MVC 框架带了许多新的变化,这些在后面会详述。

>>> 阅读全文

 

, , , , , , ,

深入MEF框架 (一) 基本概念

文章评分:

为什么需要 MEF?
近年来,用于实现可扩展性的框架越来越受到人们的重视,为此已经存在许多依赖注入框架来解决应用的扩展性问题,比如 Eclipse 的 OSGI 实现以及 Java 的 Spring 等等。在 Microsoft 的平台上,.NET Framework 自身内部包含组件模型和 System.Addin,此外还有不少开源解决方案,包括 SharpDevelop 的 SODA 体系结构和“控制反转”容器(如 Castle Windsor、Structure Map、Spring.Net 以及 Unity )。为什么我们还需要 MEF 呢?

在 Microsoft 看来,这些方案有些过于庞杂(比如 OSGI ),有些则需要开发人员完成许多额外配置工作(比如 Spring ), MEF 试图秉承这些解决方案的优点,尝试解决刚才所提及的令人头痛的问题。 MEF 有两个优点:

  • 第一,MEF是开源项目,其源代码在Codeplex上可以下载,
  • 第二,MEF 是第一个随 CLR 发布的扩展性管理的框架,而且在 Visual Studio 和 Silverlight 中被广泛应用。

官方给 MEF 下的定义:Managed Extensibility Framework(MEF)是 .NET 平台下的一个扩展性管理框架,它是一系列特性的集合,包括依赖注入( DI )以及 Duck Typing 等。MEF 为开发人员提供了一个工具,让我们可以轻松的对应用程序进行扩展并且对已有的代码产生最小的影响,开发人员在开发过程中根据功能要求定义一些扩展点,之后就可以使用这些扩展点与应用程序交互;同时MEF让应用程序与扩展程序之间不产生直接的依赖,这样也允许在多个具有相同的扩展需求之间共享扩展程序。

概念
简单说一下 MEF 的工作原理,MEF 的核心包括一个 catalog(目录)和一个 CompositionContainer(组合容器)。catalog 用于发现扩展,而 container 用于协调创建和梳理依赖性。MEF 组合模型的核心是组合容器,该容器包含所有可用的部件并执行组合操作(即,将导入和导出配对)。见下图。

>>> 阅读全文

 

, , , ,