IronPython 2.0完全基于微软DLR平台实现的。并且提供了良好的和.NET CLR对象之间交互的能力。在本系列文章里，我们将尝试实现一个自定义控件，使得你可以象使用标准Python控制台一样在其中输入Python代码，并且运行。

当然，为了能够让IronPython很好的操作CLR对象，其中还是有很多技巧，让你的CLR对象对IronPython更友好，这一节，我们就要使用ExtensionTypeAttribute为已有的CLR对象添加DLR友好性支持。

在本系列文章中，我们将逐步实现一个自定义控件，实现类似IDE的Immediate窗口的功能。用户可以在其中输入和运行IronPython代码。 【返回目录】

在上一节中， 实现自定义模块的尝试失败了。后来仔细想想，也许有了clr module，以及IronPython在CLR对象的封装上实现了很多对IronPython兼容特性（呵呵，我想这个就可以做一个专题讨论）。我们大多时候已经可以将CLR对象当作IronPython对象一样操作了。也许这就是为什么IronPython不打算将PythonModuleAttribute提供给我们用的原因。谁知道呢，也许微软提供了途径，我没有找到。

IronPython在对CLR对象进行封装时，已经进行了很多兼容方面的考虑。但是，有些东西，IronPython仅仅提供了方案。真正的实现还是要我们自己来了。

比如：让一个CLR对象支持动态类型。即运行时添加删除属性和方法。

大家知道，对于静态类型语言，一个对象的类型在它被创建时就被确定下来，并且不能被改变。而一个类型具有哪些成员也是在编译时被确定下来的。因此，下面的代码在编译时就会报错。

 1public class Foo
 2{
 3    public int Bar { get; set; }
 4
 5    public static void Main()
 6    {
 7        Foo foo = new Foo();
 8        foo.xxx = 10; // 这一行编译失败
 9    }
10}

而对于动态类型语言，类似上面的代码就完全是合法的代码。对于大多数习惯了C#这样的强类型语言的开发人员（包括我自己）可能都觉得这样的规定除了增加出错概率外，没有任何意义。但是，这样的规定配合一些其它功能（比较有名的就是鸭子接口），这样的设计反而可以发挥出来巨大的优势。好的，我们不来讨论哪种语言更好，仅仅给出上面代码的IronPython版本。

1class Foo:
2    Bar = 0
3
4foo = Foo()
5foo.xxx = 10

呵呵，Python确实比C#精炼

如果使用我们的DLConsole,你会发现对于我们植入的对象（比如：Button1和TextBox1),下面的代码就会产生一个MissingMemberException('Button' object has no attribute 'xxx')。

先让我们从头开始实现一个类型，让你可以在其中添加和删除成员。代码如下：

注：因为这个类型和DLConsole没有直接关系，因此，上面的代码在TestDynamicLanguageConsole工程中。

上面的代码中，出现了一个比较特别的Attribute [SpecialName]，它被定义在“System.Runtime.CompilerServices”命名空间下，也就是说，它并不是DLR定义的Attribute。查了一下MSDN，发现“.NET Framework 中目前不使用 SpecialNameAttribute 类，但该类被保留以备将来之用。”。呵呵，看来微软早就留了一手。

这一节中添加的几个Special的方法，都添加了这个Attribute。你会发现，随后的几节中，你随时都会发现这个Attribute的身影。如果你不添加这个Attribute，IronPython都会将它们当作普通成员处理。

除此之外，就是四个固定名称的方法：GetCustomMember, SetMember, DeleteMember和GetMemberNames。实现这些方法，使用一个标准的Dictionary储存这些属性就可以了。现在，你就可以在IronPython中象操作动态类型对象一样的操作这个对象了。

为了简单，我的演示程序中直接将该对象注册到Scope中了。你可以使用第二讲中的方法，通过clr模块从头构建这个对象。

下面是运行效果图

但是，实现这几个方法后，一个最直接的影响就是IronPython默认实现的属性读取和调用方法都失效了。也就是如果你直接访问Friend.Foo属性将会收到一个KeyNotFoundException（The given key was not present in the dictionary.）。因此，你需要对原有的属性和方法进行一些处理。方式可以类似上面代码中关于“_dict”的处理。

下一节，我们将会实现一个Collection对象，让它能够支持IronPython的切片操作和列表解析。敬请关注

大家可以从这里下载可运行的源代码。

免责声明：本系列文章，完全是我个人研读IronPython源代 码后找到的实现方案，并未详细的研究过IronPython的相关官方文档。因此，并不保证符合微软DLR和IronPython的设计思路，亦不能保证 在DLR和IronPython 2.0正式发布后能够继续使用。 

失败

在IronPython的源代码中，提供了一个PythonModuleAttribute，我原以为这个Attribute是为自定义Module建立的。在clr.AddReference时会检查Assembly中的所有PythonModuleAttribute。并将指定的类型作为Module导入到Python的运行环境中。

但是，今天实际测试的结果并不是这样。IronPython仅在自己的IronPython.dll和IronPython.Modules.dll中支持这个Attribute.

目前看来，向Scope中添加Clr对象还是比较正统的实现方式。关于其他的扩展途径，还正在研究中。

跳过这一节，下一节《使CLR对象对动态语言更友好（一）》中，我将实现一个CLR对象，可以支持最基本的动态语言特性——运行时添加删除属性。

在本系列文章中，我们将逐步实现一个自定义控件，实现类似IDE的Immediate窗口的功能。用户可以在其中输入和运行IronPython代码。 【返回目录】

在上一节中，我们成功的将CLR对象添加到了IronPython的运行环境中。相信通过上一节的内容。大多数人都已经可以很容易的将IronPython集成到自己的应用程序中。但是，某些时候，我们为了给我们的用户以更好地体验。需要对IronPython进行一些扩展，比如：添加自定义的方法到IronPython环境。

1. 先看运行效果

我在DLConsole中输入如下的脚本：

运行结果如图：

2. 向DLConsole中注册Delegate

之前，已经可以将一个对象注册到ScriptScope中，并且通过它的名字访问这个对象。大多数现代的语言中，都已经能够将方法作为对象传递。.NET是通过Delegate对方法进行的封装和传递的。DLR中也对Delegate提供了很好的支持。因此，我们不需要对DLConsole进行任何修改，就可以完成这个工作。下面的代码是测试工程的代码。

 1namespace TestDynamicLanguageConsole
 2{
 3    public partial class Form1 : Form
 4    {
 5        public Form1()
 6        {
 7            InitializeComponent();
 8
 9            this._dlConsole.Registor(this.button1, "Button1");
10            this._dlConsole.Registor(this.textBox1, "TextBox1");
11            this._dlConsole.Registor(new SumDelegate(Sum), "Sum");
12        }
13
14        public delegate int SumDelegate(int x, int y);
15        public int Sum(int x, int y)
16        {
17            return x + y;
18        }
19    }
20}

在代码的第11行，我们将一个方法注册到DLConsole中，命名为"Sum"。就实现了上面展示的功能。

至此，我们已经可以通过向ScriptScope中注册Delegate的方式，使Python脚本使用我们自定义的方法。但是，你会发现这样的实现方式虽然简便快捷，却无法实现函数的重载。也就是说，你不能针对不同的数据类型注册多个Sum方法。

在下一节《使用Module扩展IronPython》中，我们将建立一个自定义模块，在其中，我们可以实现函数的重载。(2008-08-16更新：通过实验，发现我所设想的路线是错误的。您可以继续关注下一篇《使CLR对象对动态语言更友好（一）》。我将实现一个CLR对象，可以支持最基本的动态语言特性——运行时添加删除属性。)敬请关注

大家可以从这里下载可运行的源代码。

免责声明：本系列文章，完全是我个人研读IronPython源代码后找到的实现方案，并未详细的研究过IronPython的相关官方文档。因此，并不保证符合微软DLR和IronPython的设计思路，亦不能保证 在DLR和IronPython 2.0正式发布后能够继续使用。

在本系列文章中，我们将逐步实现一个自定义控件，实现类似IDE的Immediate窗口的功能。用户可以在其中输入和运行IronPython代码。 【返回目录】

在上一节中，我们建立了IronPython运行环境，并且在其中成功的运行了“print "hello world"”的命令。正如上一节的讨论中所看到的，大家都很关心如何让IronPython脚本和我们的运行环境交互。在这一节中，我们将会在DLConsole上添加两个方法，实现将运行环境中的Clr对象传递给IronPython脚本使用。

大家可以从这里下载可运行的源代码。

1. 先看运行效果。

我在DLConsole中输入如下脚本：

 1import clr
 2clr.AddReference("System.Drawing")
 3clr.AddReference("System.Windows.Forms")
 4
 5from System.Drawing import Color
 6from System.Windows.Forms import FlatStyle
 7
 8Button1.BackColor = Color.Red;
 9Button1.FlatStyle = FlatStyle.Flat
10Button1.Text = "Hello IronPython"

运行结果，如图：

2. 确保脚本可以访问CLR对象

首先，我们需要脚本能够成功的访问CLR对象。我在DLConsole上暴露了两个方法。分别是：

 1public partial class DLConsole : UserControl
 2{
 3    public void Registor(object obj, string name)
 4    {
 5        this._scope.SetVariable(name, obj);
 6    }
 7    public void UnRegister(string name)
 8    {
 9        this._scope.RemoveVariable(name);
10    }
11}

在上一讲的源代码中，我们保存了一个ScriptScope对象。用户输入的脚本就是在这个Scope对象上运行的。因此，我们在这里向ScriptScope中添加的变量，就能够被用户输入的脚本所访问了。

在测试程序中，我添加了如下的代码来将对象注册到脚本运行环境中。

 1public partial class Form1 : Form
 2{
 3    public Form1()
 4    {
 5        InitializeComponent();
 6
 7        this._dlConsole.Registor(this.button1, "Button1");
 8        this._dlConsole.Registor(this.textBox1, "TextBox1");
 9    }
10}

这时，我们就可以实现类似“Button1.Text = "Hello IronPython"”和“Button1.BackColor = TextBox1.ForeColor”这样的脚本了。但是，你会发现，如果你输入类似“Button1.BackColor = Color.Red”的脚本，会产生一个“name 'Color' is not defined”的异常。是因为在目前的Scope中无法找到Color的定义引起的。

3. 使用CLR类型

如果需要在IronPython中使用CLR类型，需要完成以下几个步骤：

a) 引入clr对象：这个对象实现了对CLR访问的一些必要的操作。例如：添加引用。
b) 添加引用：通过clr.AddReference方法，你可以使用Assembly的名字作为参数来添加对这个Assembly的引用。IronPython会使用.NET加载Assembly的策略去寻找和加载这个Assembly。
c) 引入变量：通过IronPython的“import”或“from ... import ...”语法，将你需要使用的类型引入当前Scope。

之后，你就可以使用类似“x = Form()”语法构建一个对象或通过类似“Color.Red”的语法访问对象的静态成员。

最后，给一个比较复杂的例子，从中可以理解一下IronPython的语法。

 1import clr
 2clr.AddReference("System.Windows.Forms")
 3
 4from System.Windows.Forms import Form
 5from System.Windows.Forms import Button
 6from System.Windows.Forms import DockStyle
 7
 8form = Form()
 9button = Button()
10button.Text = "http://cajon.cnblogs.com"
11button.Dock = DockStyle.Fill
12form.Controls.Add(button)
13form.ShowDialog()

运行效果：

需要说明一下，因为在控制台上输入的脚本都是在同一个Scope对象上运行的，因此，import语句只需要运行一次就可以了。也就是说，上面的代码执行后，你可以继续使用Form、Button等类型。

4. 总结

微软在DLR和CLR之间交互方面的考虑很多，因此，对一些简单的操作，我们甚至感觉不到CLR对象和一个IronPython对象之间的区别。当然，动态语言的优势即在于它的动态类型系统，这一点和CLR的静态类型系统有很大的差别。因此很多IronPython的特性（例如：动态添加属性到对象上）无法在CLR对象上使用。在后面的章节中，我们将通过一些扩展接口实现更高级的嵌入。

另一方面，将方法注册到动态语言运行环境中也是大家比较关心的一个话题。虽然，通过注册对象到运行环境，已经可以在脚本中访问这些对象的方法。但毕竟不如直接使用方法来的简单。下一节将会详细的讨论相关的实现。敬请关注

免责声明：本系列文章，完全是我个人研读IronPython源代码后找到的实现方案，并未详细的研究过IronPython的相关官方文档。因此，并不保证符合微软DLR和IronPython的设计思路，亦不能保证 在DLR和IronPython 2.0正式发布后能够继续使用。

在本系列文章中，我们将逐步实现一个自定义控件，实现类似IDE的Immediate窗口的功能。用户可以在其中输入和运行IronPython代码。 【返回目录】

首先我们需要建立一个运行环境，并确保能够在其上运行Python脚本。大家可以从这里下载可运行的源代码。

我们首先来看一下运行结果：（提示：目前该程序是通过Ctrl+Enter执行你输入的代码。下面的输出窗口是IDE的Output窗口）

点击看大图

这里是运行结果的效果图。

test

其中主要的代码如下：

 1namespace DynamicLanguageConsole
 2{
 3    public partial class DLConsole : UserControl
 4    {
 5        public DLConsole()
 6        {
 7            InitializeComponent();
 8
 9            ScriptRuntimeSetup runtimeSetup = new ScriptRuntimeSetup(true);
10            this._runtime = ScriptRuntime.Create(runtimeSetup);
11            this._engine = this._runtime.GetEngine(typeof(PythonContext));
12            // 你亦可以使用下面的代码获得脚本引擎，但是，下面的方法可能会在未来版本被废弃
13            // this._engine = PythonEngine.CurrentEngine;
14            this._scope = this._engine.CreateScope();
15        } 
16
17        ScriptRuntime _runtime;
18        ScriptEngine _engine;
19        ScriptScope _scope; 
20
21        public void Exec(string script)
22        {
23            _engine.CreateScriptSourceFromString(script, SourceCodeKind.Statements).Execute(_scope);
24        } 
25    }
26}

程序中，我们保存了三个局部变量，ScriptRuntim，ScriptEngine和ScriptScope。

脚本运行时（ScriptRuntime）：Hosting动态语言的入口。通过这个对象，你可以获得脚本引擎。添加全局变量等。
脚本引擎（ScriptEngine）：实现语言特定的脚本功能，例如：编译源代码。
脚本空间（ScriptScope）：提供了脚本运行的空间，脚本将会把其中定义的对象和变量等存储与这个空间里。.NET CLR对象也可以通过这个对象和脚本进行对象的共享。在《第三章：添加CLR对象到运行环境》中我们将会使用这个对象。

下面的图也许可以帮助你了解他们之间的关系。

我们需要做的，就是构造这样三个对象（程序中的10-14行），然后，使用脚本引擎来编译用户输入的源代码，并且让该代码在ScriptScope上运行（程序中的23行）。

好了，仅仅需要这样7行代码，你的应用程序就具有了执行动态语言的能力。接下来，要让控制台控件更象一个标准的Python控制台《第二章：实现IConsole接口》。敬请关注

免责声明：本系列文章，完全是我个人研读IronPython源代码后找到的实现方案，并未详细的研究过IronPython的相关官方文档。因此，并不保证符合微软DLR和IronPython的设计思路，亦不能保证在DLR和IronPython 2.0正式发布后能够继续使用。

最近Google推出了App Engine平台，为广大的开发人员提供了一个低成本，高扩展性的实现平台。关于App Engine的详细信息，后面我有时间的时候，考虑介绍一下。现在大家可以上网搜索一下。有很多详细的介绍。

推动动态语言发展的并不仅限于Google一家，IBM, Sun等公司也有相应的举措。微软，当然也不会落后，推出了他自己的动态语言平台——DLR 并且在其上实现了IronPython, IronRuby和JavaScript（其中，前两个应该算是社区作品，并且是开源的。最后一个是微软自己的实现，并且，目前还没有看到开源的说）。

目前我找不到DLR的源代码的独立下载地址，大家只能通过下载IronPython或IronRuby的源代码来获得DLR的源代码。简单来说，DLR就像.NET的CLR一样为动态语言提供了一套公共的运行时支持（例如：解释器，GC，语法树以及和CLR的交互等）。用微软官方的说法：DLR使动态语言开发者能够将精力放在该语言核心的功能上，而不是这些通用的功能。至少动态语言开发者并不再需要重写一套GC。虽然，很多开发人员总喜欢做这些。

微软的DLR使得动态语言开发者能够加少很多工作量，同样对于我们这些希望能够将动态语言嵌入到我们的应用程序中的开发人员也是一种好事。我们可以面向DLR去设计，提供基本的平台。然后，针对各种不同语言的特性进行一些优化，就可以简单的将他们嵌入到我们的运行环境里来。

随后的一系列文章中，我将制作一个自定义WinForm控件。该控件的功能就像一个控制台，通过将这个自定义控件嵌入你的窗口，使用户可以在其中输入代码并执行。大家可以将它想象为IDE中的Immediate窗口。

1. 建立运行环境并运行脚本
2. 实现IConsole接口，重定向输入输出
3. 添加CLR对象到运行环境
4. 添加方法到运行环境
5. 使用Module扩展IronPython （失败的项目，微软没有提供对PythonModuleAttribute的支持）
6. 使CLR对象对动态语言更友好
   6.1 支持运行时添加删除属性
   6.2 支持切片
   6.3 使用ExtensionTypeAttribute
7. 使DLConsole支持其它动态语言
8. 高级话题，建立安全沙箱运行IronPython脚本
9. 高级话题，CLR类型和Python类型之间的映射

你可以在这里下载本系列每个阶段的源代码
本系列中所有示例将基于IronPython 2.0 Beta 3.大家可以通过这里下载IronPython的源代码

2. 在其中的一个Tab页上放置一个DateTimePicker控件

你会发现，当你在XP系统下，Resize Form时，DateTimePicker会闪烁。研究了很长时间，没有结果。最终放弃C#和Spy++，使用Google研究了一下 :-) 得出结论如下：

需要为DateTimePicker控件添加WS_EX_COMPOSITED Window Style.如下：

    public class MyDateTimePicker : DateTimePicker
    {
        protected override CreateParams CreateParams
        {
            get
            {
                CreateParams ps = base.CreateParams;
                ps.ExStyle |= NativeMethods.WS_EX_COMPOSITED /*0x2000000*/;
                return ps;
            }
        }
    }

这个Style仅仅被Window XP以上系统支持。功能是将Control的所有画法使用DoubleBuffer优化。（ControlStyles.OptimizedDoubleBuffer似乎仅对WM_PAINT优化，而DateTimePicker的闪烁是由WM_ERASEBKGND引起的）

做个记录，以便后人查询。

在.NET 2.0中，微软对.NET 1.0中提出的WinForm的AutoScale能力进行了调整和增强。但是，微软始终没有跳出快速开发的圈子，因此，AutoScale做的并不彻底。其中有些工作还必须我们自己完成。

1. 什么是AutoScale？

我们知道，在不同的操作系统版本或语言版本之间，系统的默认字体是不同的。Window还提供了用户设置DPI的能力。因此，很多时候，我们在特定版本和DPI下设计的窗体，在另外一个操作系统下就会有一些字或图片被裁掉。如下图：

.NET提供了一套关于这个问题的解决方案。就是WinForm上的一组关于AutoScale的方法或属性。包括：

ContianerControl上有：

AutoScaleFactor property

AutoScaleDimensions property

CurrentAutoScaleDimensions property

AutoScaleMode property

PerformAutoScale method

Control上有：

Scale method

ScaleChildren method

GetScaledBounds method

一般情况下，微软会自动帮助你完成所有关于AutoScale的功能。你并不需要写特别的代码使用这些功能。

2.  AutoScale的实现细节

在DesignTime，系统会根据AutoScaleMode的设置不同，将一个参考值赋值给Form的AutoScaleDimensions属性。

例如：如果你选择AutoScaleMode为Font。DesignTime会自动为Form生成一行如下的代码来保存你设计时所使用的默认字体的宽和高：

this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F); 

Note: 当前系统为英文。因此，当前字体高度为13，宽度为6 

在运行时，CurrentAutoScaleDimensions属性会提取当前系统的相关设置。生成另外一个计算值。AutoScaleFactor属性表现了两个值的比值，作为下一步缩放的缩放因子。
比如，在日文系统下运行时，CurrenAutoScaleDimensions为（6f, 12f)。AutoScaleFactor为（1f, 0.9xxxf).

System.Win.Forms.ContainerControl会在OnLayout(还包括一堆其它的事件中)中对调用自己的 PerformAutoScale方法，其中对自己和它子孙调用Scale方法，并将AutoScaleFactor传入。从而实现调整他们的位置和大小，以适应当前操作系统的设置。

3. 使用AutoScale时需要注意的问题？

上面的实现应该说比较巧妙，加上Visual Studio的设计时支持。应该说已经可以完美的解决所有通过DesignTime设计的窗体或自定义控件。

但是，微软没有为这套系统进行完整的支持。如果你通过代码在运行时修改控件的位置或大小时，可以说你没有任何一个理想的方案来确保你的修改能够适应各种不同的操作系统设置。因为......当ContainerControl触发了PerformAutoScale方法后，为了确保下一次触发 PerformAutoScale方法不会累加操作，而将AutoScaleDimensions修改为和 CurrentAutoScaleDimensions一致。也就是说，你再也无法拿到设计时所使用的AutoScaleDimensions值。因此，你也就无法使用这套机制来确保你的修改操作可以兼容各种操作系统的设置。

在我们的产品中就有很多问题是这一点引起的。毕竟，在大多数产品中，并不会仅仅通过DesignTime托托拽拽就可以完成需求。因此，我们需要：

3.1 尽量使用DesignTime设置Control的Size和Location

3.2 如果不能使用DesignTime，自己需要维护AutoScaleDimensions值

看起来，我们只能自己手动生成我们自己的AutoScaleDimensions值。VS会将那一行代码生成在 InitializeComponents方法内部，该函数推出的时候，PerformAutoScale已经被调用，因此标准的 AutoScaleDimensions属性已经不能使用了。这里需要Hard Code。 // TODO: 谁有更好的建议？

并且在下列情况中手动对Control的Location或Size进行计算。

• 修改Control的位置或大小时，手动计算正确的值。
• 添加新Control到Controls之前，手动计算正确的Size和Location. 

我们需要使用前面我们自己维护的AutoScaleDimensions和当前容器的AutoScaleDimensions运算生成 AutoScaleFactor，然后自己计算新的位置和大小。这里，需要注意，不要参考Control的当前Size或Location。因为他们可能已经被Scale过一次了。

Note: 千万不要试图通过调用Control.Scale方法来完成计算。因为，ContainerControl的Scale方法会对所有子Control进行 Scale。但是，往往ContainerControl已经在它的构造函数中对它的子进行了Scale操作。结果相当于它的子进行了两次Scale。结果是错误的。

以前，我们的开发人员和测试人员有时会发现一些类似下图的异常。

这些异常的发生往往都是看起来很随机，很难重现的。调用堆栈往往是空的。并且，当程序脱离IDE运行时，都不会发生这些异常。因此，我们经常认为这些异常是IDE的Bug导致。很少在意。(至少我以前是这样)

今天详细的看了一下MSDN中关于MDA的介绍。发现这些问题往往都是很重要的和潜在的问题。比如：PInvokeStackImbalance这个MDA能够帮助我们发现PInvoke的声明有问题。StreamWriterBufferedDataLost这个MDA可以帮助我们发现我们忘记调用StreamWriter.Close()方法。

因为很多MDA异常的触发都是在GC回收时进行的，因此表现比较随机。较难重现。

如果你希望自己控制监视哪些MDA异常，可以使用IDE中的Debug->Exceptions->Managing Debugging Assistants来选择捕获哪些MDA异常。如下图：