|
|
新功能
根据随新的 .NET Framework SDK 提供的、标题为“API Changes from v1.0 to v1.1”的文档，在 System.Windows.Forms 命名空间中，增加了 48 个 API，删除 14 个，并且没有破坏性改动。这条新闻一开始可能会使您为新增的 48 个功能而高兴，同时为失去 14 个旧功能而伤心，因为删去的东西将不能再使用。同时您可能也想知道，删除 14 个功能如何才能没有破坏性改动。既然没有破坏性改动就意味着所有现有的 Windows 窗体代码都应该继续运行而没有任何改动，所有已删除的功能都有确实做过改动的相应新增内容，例如，在 AxHost 类中对 ProcessDialogKey 方法的声明所做的更改，如下所示：
class AxHost {
// .NET 1.0 declaration
protected virtual bool ProcessDialogKey(Keys keyData);
// .NET 1.1 declaration
protected override bool ProcessDialogKey(Keys keyData);
}
这一更改显示 AxHost 不再提供新的虚方法，但重写现有方法意味着 ProcessDialogKey 被声明为虚方法以便进一步继承。大部分新增内容都属于该类别，使得对 Windows 窗体命名空间本身的更改看起来有些无聊。实际上，对 Windows 窗体命名空间只新增三个有价值的功能（并对 System.Drawing 命名空间新增一个有意思的功能）：
• System.Windows.Forms.FolderBrowserDialog 类
• System.Windows.Forms.Application.EnableVisualStyles 方法
• System.Windows.Forms.CurrencyManager.MetaDataChanged 事件
• System.Drawing.Printing.PrintDocument.OriginAtMargins 属性
如果这就是全部内容，我就不需要用整篇文章来描述新功能了。还有很多内容，包括命名空间增加、支持在非托管客户端中宿主托管控件、支持托管 C++ 和 Visual J# 的 Windows 窗体设计器、集成访问 Compact Framework，以及新的移动代码安全设置。然而，在介绍所有这些新功能之前，我们将首先讨论如何处理多版本的公共语言运行库 (CLR)。
转移到 1.1
对于任何新版本，我都希望 Microsoft 能够增加我需要的新功能，同时又不破坏我仍需要的任何功能。与 Win32 DLLs（这里开发人员认定不会有任何版本控制问题）和 COM（这里他们认为根本不需要版本控制）不同，.NET Framework 为多版本、同时安装的组件版本和运行库本身提供全面、明确的支持。实际上，如果您运行一种 Windows 版本，它正在运行 Windows Update，则您很可能运行了 1.0.3705.288 版的 CLR，它是 .NET Framework 1.0 SP2。安装 .NET Framework 1.1 之后，您的 CLR 版本会增加到 1.1.4322.510 版，它是 .NET Framework 1.1 最终 Beta 版。然而，安装 1.1 版并不替换任何安装在您机器上的现有版本。相反，两个版本会在独立的目录中和平共处。
在运行时加载的 CLR 的版本取决于所构建的 EXE 程序集的版本。所以，如果您构建了一个针对 .NET Framework 1.0 的 Windows 窗体应用程序，即使机器上安装了 .NET Framework 1.1（或更高版本），都会加载 1.0 版的 CLR 来宿主您的应用程序。然而，如果在机器中启动 1.0 版的应用程序，但没有安装 1.0 版，则会自动加载 CLR 1.1 版。这样可以防止每个 Windows 窗体 1.0 应用程序都需要 .config 文件来表明可以在 1.1 下加载 1.0 应用程序。如果您情愿关闭该行为，则可以创建自己的 .config 文件并关闭该自动升级功能：
<!-- support only .NET 1.0 Framework -->
<configuration>
<startup>
<requiredRuntime version="v1.0.3705"/>
<supportedRuntime version="v1.0.3705"/>
</startup>
</configuration>
在这种情况下，如果您的 1.0 版应用程序运行在没有 1.0 版 CLR 的机器上，则不管是否安装了 1.1 版，用户都会接到表明需要特定版本 .NET Framework µÄ错误消息。
最后，如果您想支持 1.0 版，但只要 1.1 版可用就选择 1.1 版（例如，因为它执行得更好），则请看以下代码：
<!-- prefer .NET Framework 1.1, but support .NET Framework 1.0 -->
<configuration>
<startup>
<requiredRuntime version="v1.0.3705"/>
<!-- order of these keys determines preference -->
<supportedRuntime version="v1.1.4322"/>
<supportedRuntime version="v1.0.3705"/>
</startup>
</configuration>
不幸的是，事情并非到此为止。由于每个程序集都伴随着一连串所需程序集（包含它们的版本号），所以在 .NET Framework 1.1 版本下构建一个应用程序就需要所有程序集都有 1.1 版。在只有 1.0 版程序集的机器上运行曾在 1.1 版下构建的 1.0 版应用程序会失败，因为它不能找到合适版本的参考程序集。所以，如果想使在 1.1 版本下构建的应用程序能够真正运行在它引用的早期版本的程序集上，就需要在 .config 文件中有每个程序集项，如图 1 所示。
这些配置设置指明：当在 1.0 版 .NET Framework 下运行并加载任何版本的 System.Windows.Forms 时，都会加载 1.0 版的 System.Windows.Forms，即使代码是针对 1.1 版构建的。虽然这个便捷功能允许您使用最新的 1.1 版工具，但要设置 .config 文件以使功能生效则是件棘手的事情。幸运的是，Visual Studio .NET 2003 提供了一个额外的项目设置，可通过“项目 | 属性 | 公共属性 | 常规 | 支持的运行库”获得。这个设置通过“.NET Framework 版本”对话框公开三个运行库选项，分别为：Microsoft .NET Framework 1.1 版（默认）、1.0 版和二者。
默认情况下，在 Visual Studio .NET 2003 下编译的任何应用程序都会只面向 1.1 版的 CLR。如果您想让自己只构建 1.0 版的应用程序，则可以选中 1.0 版选项。最后一个选项是支持两种版本的 Framework，但首选 1.1。所有这三个选项都会在您的项目中添加一个 app.config 文件，具备适当的设置，包括如何映射框架程序集的详尽列表，从而免除您的麻烦。根据 CLR 的需要，在项目构建时会将生成的 app.config 文件复制到输出目录，并重命名为 projectName.exe.config。
当您停下来阅读“.NET Framework 版本”对话框的文本时，您会注意到它使用一些很显眼的语言来劝阻您在使用 Visual Studio .NET 2003 时，不要选择支持 1.0 版。问题是那个可恶的中间选项说只支持 1.0 版。虽然 Visual Studio .NET 2003 会更新 .config 文件以便恰好只需要 1.0 版的 Framework，但是当您使用在 1.0 版下不可用的类型或成员时，IntelliSense 和编译器都不会告知您它不可用。只有在运行时运行的代码与 1.0 功能列表发生冲突，然后用到所缺类型或方法的方法被实际调用时，您才能知道它不可用。如果您决定使用 Visual Studio .NET 2003 来构建面向 1.0 版的应用程序，您就需要进行一些完整的代码覆盖范围测试以确保它真正能在 1.0 版下运行。
如果您只面向 1.0 版并强烈希望使用 Visual Studio .NET 2003，但又不能放弃编译时检查和准确的 IntelliSense，那么这是个可行的办法，只管使用。不幸的是，问题并非如此简单，因为您需要做的并不仅仅是在“.NET Framework 版本”对话框中敲击几下。首先，您需要将“Project | Properties | Configuration Properties | Advanced | Do not use Mscorlib”设置为“true”（它默认为“false”），这样在编译时才不会引入 1.1 版的 mscorlib.dll。其次，您需要删除 Visual Studio .NET 2003 加入项目的所有程序集引用，因为它会默认从 1.1 版 Framework 目录中获取。最后，您需要从 1.0 版 Framework 目录添加项目引用，方法是使用“添加引用”对话框中的“浏览器”按钮来手动选择程序集（包括 mscorlib.dll 和 system.dll）。由于编译器（和 IntelliSense）会引用 1.0 版的程序集，所以这些手动步骤可以让您继续使用 Visual Studio .NET 2003，尽管只是 1.0 版的程序集。
另一方面，如果您同时面向 1.0 版和 1.1 版，则您很有可能想利用 1.1 版的新功能。当您这样做时，您需要通过 System.Environment.Version 仔细检查运行库的版本号，并且只在任何 1.0 版代码都不会调用的方法中使用 1.1 版的功能。即使在 1.0 版本下不会调用 1.1 的代码，但在第一次调用方法时，实时 (JIT) 编译器也要求所有类型和方法都存在，少了哪一个都会引发异常。图 2 提供的示例说明了隔离需要 1.1 版的代码的一种方法。请注意，只有运行库版本支持、并且包含特定于 1.1 版代码的方法，这段代码才会调用它。
命名空间增加
在讨论利用只在 1.1 版中可用的 Windows 窗体功能的同时，我们还将回顾 CurrencyManager.MetaDataChanged 事件、PrintDocument.OriginAtMargins 属性、FolderBrowserDialog 类和 Application.EnableVisualStyles 方法。如果您正在使用数据绑定，并且除了新增或更新的行和列以外，您还对底层元数据更改有兴趣，则 MetaDataChanged 事件十分有用。如果您实际想让打印的文档页边距与纸张的边缘而不是打印机的可打印区域的边缘对齐，则 OriginAtMargins 属性十分有用（前者是直觉位置，而后者只是 .NET Framework 1.0 底下的一个选项，并且在 1.1 版下仍是默认选项）。FolderBrowserDialog 类是 Win32 ShBrowseForFolder 函数和您期望的工作方式的包装：
void browseButton_Click(object sender, EventArgs e) {
FolderBrowserDialog dlg = new FolderBrowserDialog();
dlg.Description = "Please choose a folder:";
DialogResult res = dlg.ShowDialog();
if( res == DialogResult.OK ) {
MessageBox.Show(dlg.SelectedPath, "Selected Path");
}
}
当然，FolderBrowserDialog 类可以从 Visual Studio .NET 工具箱拖放，所以您可以使用属性浏览器来设置各个选项，例如初始文件夹以及是否显示“Make New Folder”按钮。
另一个有趣的地方是“Browse For Folder”对话框使用的是漂亮、圆形的 Windows XP 主题按钮。默认情况下，Windows 窗体应用程序并不能获得漂亮、圆形的 Windows XP 主题 — 即使是在 Windows XP 和 .NET Framework 1.1 版下运行。相反，会使用经典控件，从而使得应用程序在 Windows XP 底下运行时显得很老式，特别是与始终以一种主题化方式显示的标准对话框相对比更是如此。
在 1.0 版下，启用 Windows XP 主题需要一个 .manifest 文件来选择公共控件和对话框的主题化版本（有关在 1.0 版下启用主题所需要的 manifest，请查阅“参考资料”）。在 1.1 版中启用主题就不再需要 manifest。相反，需要在显示任何用户界面之前调用 System.Windows.Forms.Application 类的 EnableVisualStyles 方法：
static void Main() {
Application.EnableVisualStyles();
Application.Run(new Form1());
}
虽然 EnableVisualStyles 看起来很复杂，但仍需要设置窗体中每个控件的 FlatStyle，将默认值 FlatStyle.Standard 改成 FlatStyle.System。图 3 显示了在 Windows XP 下运行时的区别。在支持 FlatStyle 属性的控件子集（按钮、组合框和标签）中设置该属性有一个快捷方式，请参考图 4 中所示的代码。
非托管主机中的托管控件
虽然我谈的是托管控件，但 1.0 版支持的一点是在完全非托管的主机上宿主 Windows 窗体控件：Microsoft Internet Explorer。该语法有着特定的目的，是为了宿主 Windows 窗体控件而量身定做，如下所示：
<html> <body>
<object
id="iectrl"
classid="iectrl.dll#iectrl.UserControl1"
width="100" height="100" >
</object>
</body> </html>
虽然在 Windows 窗体控件中需要一些特定的 interop 属性来支持事件，但 Internet Explorer 并不需要任何标准 COM 注册表项就可以使该控件作为一个 COM 控件供它使用。相反，对象元素的 classid 属性则以如下方式获取 Windows 窗体控件的名称：
<dllName>#<namespace>.<className>
Internet Explorer 只是简单加载 Windows 窗体控件本身，并将它视为 COM 控件。然而，在 1.0 版中并不支持其他常见的 COM 控件宿主，如 MFC、Visual Basic 6.0 或 ATL。虽然在 1.1 版中也没有正式支持 Visual Basic 6.0 和 ATL，但是 Windows 窗体团队在 MFC 7.1（随 Visual Studio .NET 2003 发布的 MFC 版本）中将宿主 Windows 窗体控件作为 COM 控件进行完整周期测试，现在它已经正式受非托管宿主支持。不过虽说它已被完全支持，却没有被完全集成。您需要增加标准的 COM 控件包容基础结构才能支持 Windows 窗体控件。
MFC 内核支持置于 COleControlSite 中的 COM 控件，该 COleControlSite 根据给定的 CLSID 创建控件。与此不同的是，我要在试图宿主之前创建 Windows 窗体控件，所以我的 COleControlSite 衍生体会忽略 CLSID 并围绕现有的控件创建宿主（请参见图 5）。
当调用 CWnd 基类的 CreateControl 方法创建 COM 控件时，会使用 COleControlSite CreateControl 方法。我的 CreateControl 实现几乎完全复制了基类实现，除了一点不同：它不是调用创建 COM 控件的 CreateOrLoad 方法，而是调用自定义的 WrapWinFormsControl 方法。我的 Windows 窗体控件宿主代码依赖于 COM interop，.NET Framework 为了让 Windows 窗体控件公开恰当的 COM 接口而提供该 COM interop。
另外，请注意 CWinFormsControlWnd 类的使用。该类的实例保留了宿主 COM 控件的 HWND 以及在 Windows 窗体控件之上的 IUnknown 指针。CWinFormsControlSite 在需要时依靠 CWinFormsControlWnd 的实例，通过 GetControl 方法返回 Windows 窗体控件周围 COM fa?ade 上的接口指针（参见图 6）。
GetControl 的实现从 Windows 窗体控件返回一个缓存的 COM 接口指针，并传递给 Create 方法。Create 方法缓存接口指针，并通过调用 CWnd 基类的 CreateControl 方法促使 CWinFormsControlSite 类的 CreateControl 方法被调用。通过重写必须宿主 Windows 窗体控件的任何 CWnd 派生类的 CreateControlSite 方法，可以将自定义的 CWinFormsControlSite 类提供给 CWnd 类，如下所示：
BOOL CMfcWinFormsHostDlg::CreateControlSite(...) {
ASSERT(ppSite);
*ppSite = new CWinFormsControlSite(this->GetControlContainer());
return TRUE;
}
作为该类的一个示例，图 7 显示了一个对话框，它在同一个 MFC 对话框中并排宿主非托管和托管的 MonthCalendar 控件。
图 7 中的对话框是用标准的 MFC 向导创建的，它重写了 CreateControlSite 方法并创建 CWinFormsControlWnd 类的一个实例：
class CMfcWinFormsHostDlg : public CDialog {
virtual BOOL CreateControlSite(...);
private:
CWinFormsControlWnd m_wndWinFormsCalendar;
};
与 MFC 的 COM 控件创建进程挂钩之后，随着对话框的创建，最后就可以创建 Windows 窗体控件的实例了。这可以通过非托管代码来完成，方法是手动宿主公共语言运行库 (CLR)，并使用 COM interop 来创建任何 Windows 窗体控件的实例。不过有个非常简单的解决方案，那就是通过将“Project | Properties | Configuration Properties | General | Use Managed Extensions”选项设置为“yes”（它默认为“no”）来打开托管扩展，使其扩展至 C++。这样就可以从您的 MFC 应用程序使用托管类型，包括 Windows 窗体控件，而不需要您将任何现有的非托管 C++ 类变为托管 C++ 类（请参见图 8）。
虽然这些指令有点繁杂，但是本文示例所提供的 CWinFormsControlWnd 和 CWinFormsControlSite Helper 类已去掉大部分令人费解的内容，不需要 Windows 窗体控件的特殊支持就可以在 MFC 7.1 以上宿主它们，并且您所做的工作就足够支持 Internet Explorer 5.01 和更高版本的宿主。有关 COM 和 .NET 之间的 interop 话题的更多信息，请参阅 Adam Nathan 所著的 NET and COM:The Complete Interoperability Guide (Sams, 2002) 一书。
对 C++ 和 J# 的设计器支持
就像宿主 Windows 窗体控件（如 COM 控件）一样，在 Visual Studio .NET 2002 中支持 C# 和 Visual Basic .NET 以外的语言，但并不完全集成。您可以在托管 C++ 或 J# 中编写 Windows 窗体应用程序，但是没有设计器支持；您需要手动编写所有代码。作为一个 Windows 窗体迷，我并不希望任何人做这样的工作。
幸运的是，对于需要采用 C++ 或 J# 的编程人员来说，Visual Studio .NET 2003 为托管 C++ 和 J# 提供了完整的设计器支持。在创建新项目时，在 Visual C++ 和 Visual J# 项目类型中，您会看到用于构建 Windows Control Library 和 Windows 窗体应用程序的项目，就像您过去使用 C# 和 Visual Basic .NET 时所看到的。当创建 Visual C++ Windows 窗体应用程序时，您会看到一个十分熟悉的环境，以及一个包含各种控件和组件的工具箱，设计器表面可以进行拖放操作，并且还有属性浏览器。实际上，唯一的不同是 Windows 选项卡，它用 Form1.h 来替换 Form1.cs。
当创建一个新的 C++ Windows 窗体应用程序项目时，您可以看到一个 Form1.cpp 文件和一个 AssemblyInfo.cpp 文件，这是您能预料到的，但是对于通过“Project | Add New Item”添加到项目中的每个窗体类，您还会看到一个 a .h 文件。这个 .h 文件正是设计器执行其所有工作以及让您添加自己的代码的地方。而 .cpp 文件则越来越像个摆设，它的作用只是包含预编译的头文件和相应的 .h 文件。只有向导生成的 Form1.cpp 文件非常重要，它包含应用程序的入口点（请参阅图 9）。
对于以前使用 C++ 而现在在使用 C# 来构建 Windows 窗体应用程序的编程人员来说，这+样的语法会让他们感觉如梦初醒或者一头雾水。不管怎样，它都是纯托管 C++，虽然所有的实际操作都发生在头文件中，如图 10 所示。
对于 C# 编程人员来说，这样的代码也应该很熟悉。自定义 Form1 类是从 Form 基类派生的。而 Form 的构造函数调用 InitializeComponent 类（虽然没有详细注释授予向该函数添加其他代码的权限）。然后由 Dispose 函数处理与非可视化组件的集成，它使用 __super 关键字调用基类。接下来再由 InitializeComponent 建立窗体的初始属性以及窗体上的控件。与使用 C# 或 Visual Basic .NET 一样，该函数属于设计器所有，应该保存不变，除非您想玩火（也必自焚）。
向导生成初始的 C++ 代码之后，设计器会在您拖放控件时向窗体添加成员变量，当您在属性浏览器中做出更改时在 InitializeComponent 中设置它们的属性，并为您添加事件处理程序。诚然，这十分烦琐，除非您现在已熟练掌握 Visual Basic .NET 和 C# 编程人员应用自如的 Windows 窗体工具，并能自如地驾驭托管和非托管 C++。例如，托管 C++ 项目所允许的功能中，我最喜欢的一个就是添加非托管资源，C# 和 Visual Basic .NET 都不支持这个功能。这是除模板、多重继承以及混合托管与非托管代码和类型以外新增的功能，其中托管 C++ 已为人所知并受人喜爱。
Compact Framework
在 Visual Studio .NET 2003 中，不仅可以采用 C#、Visual Basic .NET、托管 C++ 和 J# 来构建桌面应用程序，还支持采用 C# 和 Visual Basic .NET 构建智能设备应用程序。在 Visual Studio .NET 2002 中，这个功能以 Beta 形式作为一个外接程序提供，但现在它已经成为该产品的正式组成部分。
智能设备应用程序运行在 Pocket PC 或运行 Windows CE 的机器上。当您选择“智能设备应用程序”项目模板时，实际上已经允许您构建一个应用程序或类库。选择构建为您提供熟悉的环境，但公共语言运行库类比较少也比较小。例如，将现有 Windows 窗体游戏应用程序的 98％ 移植到 .NET Compact Framework 很容易，但其余的就尚待发掘。与 .NET Framework 不同，.NET Compact Framework 几乎是以一种方式完成所有的工作 — 所以您在 Windows 窗体中习惯采用的一些快捷方式此处并不可用。例如，要在控件中设置背景图片时，就不得不在 Paint 事件期间绘制。同样，从资源中读取位图也不像以前那样容易：
// Loading a bitmap from a resource in the .NET
// Framework
Bitmap logo = new Bitmap(this.GetType(),
"sblogo.PNG");
// Loading a bitmap from a resource in the
// Compact Framework
Assembly assem = Assembly.GetExecutingAssembly();
string file = "PocketWahoo.sblogo.PNG";
Bitmap logo = new Bitmap(assem.GetManifestResourceStream(file));
然而，尽管对设备进行模拟，但这与在另一台设备上运行您的 Windows 窗体应用程序还是两回事，如图 11 所示。
移动代码安全设置
有个细节您可能会觉得很有意思，它与代码完全无关，而是与适用于从网上下载的智能客户端和 Windows 窗体控件的安全设置有关。在 1.0 版中，.NET Framework 具有很强的能力，可以在 Internet Explorer 的页面中宿主 Windows 窗体控件，就像 COM 控件一样。更喜人的是，1.0 版引入了智能客户端的概念 — 即，客户端应用程序可以通过 Web 来执行。如果您以前没这样做过，请创建一个虚拟目录，在其中放置一个 Windows 窗体应用程序，然后通过“Start | Run”，使用如下所示的 URL 来运行它：http://localhost/itweb/hr452.exe。这样可以将该应用程序下载到本地机器，然后像运行单机版客户端应用程序那样运行它，但受到与应用程序启动位置相关权限所限制（有关智能客户端的更多信息，请参阅 SDK 中的 References）。
当然，由于代码既可来自友好的 Intranet，也可来自恶意的 Internet，所以通过 Web 下载和宿主代码这两种方式都需要具有安全性考虑事项。为了确保不出现问题，.NET Framework 代码访问安全 (CAS) 模型根据每个程序集的来源分别为它们提供一个部分受信任的安全沙箱。在 1.0 版 SP0 中，来自 Intranet 和 Internet 区域的程序集都允许运行，但是 Internet 权限比 Intranet 权限明显要低。自从 1.0 版 SP1 起，Microsoft 就对设置进行了更改，完全禁用来自 Internet 的代码（虽然您还可以重新启用它）。现在 1.1 版是一个更安全的版本，同时 Microsoft 在不降低 Internet 权限本身的前提下默认允许执行来自 Internet 的代码。还不止这些。.NET Framework 1.1 版还重新引入了来自 COM 的 Authenticode。
在 COM Authenticode 模型下，如果用户 OK 有代码要运行，根据用户的权限（大部分用户都以管理员身份运行代码），这段代码可以做它想要做的任何事情。如果这段代码干了些坏事，则专家组可以跟踪它，找到证书，然后惩罚编写这段代码的坏家伙。另一方面，.NET CAS 模型具有预防性，因为它从不询问用户，但如果代码不是来自本地硬盘，则只授予它有限的一组权限。在实践中，这两种模型都有各自的用处。当然，CAS 主要用于防止恶意事件的发生。而 Authenticode 则主要是让用户知道即将运行来自本机外的代码，并询问他们是否运行正常。是否询问是由确定是否请求 COM 控件的同一个 Internet 安全设置确定的。在 1.1 版的最终 Beta 版中，针对来自 Internet 区域的代码的默认设置如图 12 所示。
可以注意到，当执行来自 Internet 区域的代码时，默认没有用户提示。对于 intranet 区域的代码也一样。这比 ActiveX?/COM 控件的默认设置权限更高，后者默认对已签名的控件加以提示，并禁用未签名的控件。当然，对于 COM 控件来说，只使用 Authenticode 就可以满足所有安全性要求，而在 .NET Framework 中，则需要 CAS 来继续保护用户。
|
|
