.NET增强型客户端应用程序中的代码访问安全以及分发特性 (节选)

Code Access Security and Distribution Features in .NET Enhance Client-Side Apps
.NET增强型客户端应用程序中的代码访问安全以及分发特性
Jason Clark
This article assumes you're familiar with C#, Visual Basic .NET, and the CLR
本文需要您熟悉C#，Visual Basic.NET以及CLR。

SUMMARY
摘要
Rich clients employ many of the features and conveniences of the operating system they run on, and the list of these features has been growing since the dawn of the PC. But as apps have migrated to the Web, the trend towards increasing client-side functionality has ground to a virtual halt. There are several reasons for this; chief among them are security and deployment problems. But that's all about to change. With the .NET Framework, you can participate in building the distributable rich client of the future.
富客户端使用许多当前运行的操作系统中的便利与特性，并且这些特性自从PC机诞生以来一直在发展着。但是随着应用程序已经迁移到WEB，发展客户端功能的趋势却似乎渐渐的停止下来。这里有几点原因：主要都围绕在安全以及发布的问题上。但是现在都已经改变了。随着.NET框架的到来，您可以参与建立未来可分发的富客户端。
In this article, the author enumerates the pertinent features of .NET that will allow you to build safe, easily deployable controls. The features discussed include managed code, code access security, versioning control, Windows Forms classes, and isolation..
本文中，作者列举了.NET的相关特性，使您可以建立安全，易发布的控件。这些即将讨论的特性包括托管代码，代码访问安全，版本控制，Windows Forms类以及隔离。
In all of the recent coverage of the Microsoft .NET Framework, I have yet to see discussed the return of the rich client. A rich client is any software running natively on a client machine. This includes traditional applications like word processors and spreadsheets, and also includes Web-deployed executables such as legacy ActiveX controls and the new Windows Forms controls. Examining the rich client requires a look at a number of seemingly unrelated features of the .NET Framework such as Windows Forms and security.
所有最近关于Microsoft .NET 框架的报道中，我还看到了有关富客户端回归的讨论。富客户端的意思是任何的软件全部运行在客户端机器上。这里包含传统的应用程序，如文字处理和空白表格程序，也包括基于网络执行的ActiveX空间以及新型的Windows Forms控件。检查富客户端的需求，似乎看起来和.NET框架的特性并无关系。
So what makes the rich client rich? The rich client has access to the windowing and GUI features of the operating system on which it runs. This means drag and drop editing, toolbars and menus, animation, and all of the other bells and whistles. These are the features that are often difficult or impossible to implement using markup languages such as HTML or even DHTML.
那么，什么是的富客户端丰富的呢？富客户端访问当前运行上的操作系统中的窗体以及用户图形界面的特性运行。这意味着，拖拽编辑、工具栏以及菜单、动画、以及所有的声音效果。这些特性通常很难或者根本不可能使用标记语言如HTML甚至是DHTML来实现。
The rich client also has access to other local resources such as the file system, printers, and sound cards. Yet more and more software is being written with limited or no access to these features. Why is that?
同时，富客户端可以访问其他本地资源，比如文件系统、打印机以及声卡。但越来越多的软件被阻止使用这些特性，为什么会这样？
After I talk about what happened to the rich client, I will discuss trusted code and security as well as deployment of code that runs on the .NET Framework (managed code). These are the two features that play the most important roles in the rich client scenario. I will explore how .NET solves deployment issues and then cover other parts of the .NET Framework that provide a tool chest of features for developing rich client software. I'll also show an example that uses partially trusted code and code access security.
在我谈论完富客户端到底发生了什么，我将会导论可信任代码以及安全性以及运行在在.NET框架中代码的部署（托管代码）。这两个特性在富客户端方案中担任着最重要的角色。我将会探索.NET如何解决部署问题并覆盖到提供开发富客户端软件特性的工具的.NET框架中的其他部分。并且同时举出一个部分使用可信任代码以及代码访问安全这两个特性的实例。
Where Did the Rich Client Go?
富客户端哪儿去了？
Obviously, the rich client is not completely gone. I use Microsoft Outlook and Microsoft Word almost every day, both good examples of rich client software. However, while major software publishers publish software that fits this label, enterprise Web development is moving to Web interfaces handled completely by server-side processing. Of course, there are some good reasons for this trend; difficult deployment, isolation, and security models are a few of the unfortunate reasons for the shift away from the rich client. Fortunately, the .NET Framework goes a long way to alleviate these problems.
很明显，富客户端还没有完全消失。我几乎每天都在使用Microsoft Outlook以及Microsoft Word，两个富客户端软件很好的例子。但是，当主要软件供应商都符合这个条件的时候，企业级WEB开发完全转移到完全由服务器端处理的WEB界面上。当然，对于这个趋势有一些很好的解释：部署困难、孤立以及安全模块因为一些不幸的原因从客户端移除。幸运的是，.NET框架通过长时间的发展缓和了这些问题。
Let's start with deployment and installation. You've heard the term DLL Hell applied to the situation in which the installation of one application causes another to fail due to incompatibilities in updated versions of one or more DLLs. The sheer number of installation scenarios that need to be tested and tweaked before deploying applications and the deployment nightmares that can turn up later cost both the software publisher and the customer considerable time and money.
让我们从部署与安装开始。您也许听说过DLL Hell，由于一个应用程序的安装更新了一个或者多个的DLL文件造成了其他软件因为DLL文件的更新而触发的不兼容错误。所有的安装方案在部署应用程序以及部署造成后期另软件供应商与客户花费相当多的时间与金钱的噩梦之前进行测试。
Meanwhile, deploying a new Web page to a user's desktop is unlikely to affect the user's existing OS and application installations. In fact, from the system's point of view the same software is being run: the Web browser. It's no mystery why software publishers have been migrating their products to server-side Web-based tools, often at the cost of some functionality to the user. I will show you how the .NET Framework eradicates the deployment issues that have plagued you since the inception of the DLL.
期间，部署一个网页到用户的桌面上不太可能对用户当前的操作系统以及应用程序安装有影响。事实上，从系统上来看，都是一个相同的软件在被运行：网页浏览器。这样，为什么软件供应商将他们提供给需要这样一些功能的用户的产品迁移到基于WEB的服务端的工具就显得没有什么神秘之处了。我将会展示.NET框架如何根治部署问题中始于DLL原因的灾害。
In an enterprise environment, deployment of rich clients is the primary issue. The Internet has two major considerations: compatibility and security. The .NET Framework is built to alleviate both of these issues to some degree.
在一个企业环境中，富客户端的部署是首要问题。英特网有两大主要需要考虑的事：兼容性以及安全性。.NET框架将这两个问题缓和到一定级别上。
One reason not to use ActiveX controls in your Web-deployed software is security. The best-case scenario is that the user is presented with a confusing dialog box asking if they trust the software published by a certain publisher. Each time a user clicks the yes button they could possibly undermine their system. If the user says yes, then that ActiveX control can do anything on the system (it has as much access to the system as the user does). This means that a malicious control can undermine a user's system, and even a well-intentioned (but buggy) control can cause serious security problems. The bottom line is that up until now the rich client hasn't fit well into the world of Internet-deployed software.
一个在您WEB部署软件中不使用ActiveX控件的原因是安全性。最佳的方案是给用户显示出一个令人困惑的对话框，询问他们是否相信一个值得信赖的供应商提供的软件。每一次的用户点击Yes按钮他们都可能损伤他们的系统。如果用户说Yes，那么ActiveX控件可以在他们的系统上做任何事情（与用户相同的足够的系统权限）。这意味着恶意控件可以损坏用户的系统，甚至是一个可信的控件（但是充满了漏洞）造成严重的安全问题。至今，富客户端还没有能力进入英特网部署软件世界的底线。
.NET Framework to the Rescue
.NET框架来拯救
Managed code strives to solve these problems. You can deploy a managed application in exactly the same manner that you would deploy a Web site. The Common Language Runtime (CLR) uses a new component-binding functionality for referencing managed assemblies (the managed version of a DLL) that alleviates versioning and DLL concerns.
托管代码努力解决了这些问题。您可以通过与部署网站完全相同的方法来部署一个托管应用程序。通用语言运行时（CLR）使用一种新的控件绑定功能来引用托管组件（一个托管版本的DLL文件），来缓和版本问题以及DLL的关系。
Managed code can run in a partially trusted state meaning that the code can perform functions such as drawing graphics and windows, creating toolbars, implementing drag and drop, and persisting data to the hard drive. Meanwhile, partially trusted code can be barred from general access to the network and file systems, access to the registry, and other protected resources of the system. All of this comes without ever asking the user if they trust the code contained in the control. This is a huge step forward.
托管代码可以运行在一种半可信任状态中，也就是说代码可以完成如画出图形或者窗体、创建工具栏、实现拖拽、以及向硬盘预存数据等等的功能。同时半可信代码可以访问网络以及文件系统，访问注册表，以及其他系统保护的资源。所有的这些不会总是询问用户是否信任控件中的代码。这是富客户端的发展迈向前方的一大步。
Partially Trusted Code
半信任代码
Before getting too deep into this topic, let's take a look at a simple example of partially trusted code. The code shown in Figure 1 is a very simple managed application written in C# that outputs the contents of a text file to the console window. As a matter of fact, the meat and potatoes of the application are in the second and third lines of the Main function, where an instance of the StreamReader object is used to retrieve the contents of a file, which is then written to the console.
在进入这个话题之前，让我们来看一个简单的半信任代码的例子。代码段1是非常简单的使用C#写的托管应用程序，向控制台窗口中输出一段文本文件的内容。事实上，真正有用的部分是应用程序代码主函数中的第二行以及第三行上，StreamReader对象的实例用来得到文件的内容，然后写到控制台上。

Figure 1 Partially Trusted Code
代码段1 半信任代码
// Source for FileToConsole.exe
using System;
using System.IO;
using System.Security;

class App{
public static void Main(String[] args){
try{
StreamReader sr = new StreamReader(args[0]);
Console.WriteLine(sr.ReadToEnd());
}catch(SecurityException){
Console.WriteLine("FileToConsole does not have sufficient"
"security privileges to access the file!");
}catch(Exception){Usage()};
}

static private void Usage(){
Console.WriteLine("Usage: FileToConsole [FileName]");
}
}

Unspectacular though it may be, this application demonstrates one of the most interesting features of managed code: code access security. To try this out, follow these steps: build this application into an executable file, and run it once from the command line, passing the name of any text file as the argument, just to see it work. Now copy the executable to a shared volume on the network or better yet, map the directory on your local system where the file lives as a network share, using the command-line utility net.exe:
看起来这段代码似乎很不引人注目，但这个应用程序演示了托管代码中最有意思的特性之一：代码访问安全。如果想尝试，那么跟着以下步骤来实现：将这个应用程序编译为一个可执行文件，然后通过命令行运行一次，向参数中传递文本文件的名称，然后观察其工作。现在拷贝这个可执行文件到网络上的一个共享卷或者还有更好的，将网络上共享的文件的文件夹镜像到您的本地系统中，然后使用命令行的工具net.exe：
net use * //[machine name]/c$/[directory]
This will map your directory to a drive letter. Now, rerun the executable, and this time do it from the newly mapped drive. You should still reference the same file as the one you used on the previous attempt (using the local rather than the mapped drive letter).
这段命令将您的文件夹镜像到一个驱动器上。现在重新执行这个可执行文件，这次在这个新镜像的驱动器上做。您应该同样可以像之前您所作的一样提取到这个相同的文件（使用本地的驱动器要好于镜像的驱动器）。
You should see a message that states that the application failed to open the file due to lack of security privileges. What really happened is that an exception of type SecurityException was thrown when the application attempted to instantiate the instance of StreamReader. The application then caught the SecurityException and displayed the error message to the console.
您应该看到一段关于应用程序由于缺少安全权限而无法打开文件的状态消息。实际发生的是当应用程序试图创建StreamReader实例的时候一个SecurityException类型的异常被抛出。之后应用程序抓取到这个SecurityException 并且在控制台中显示出错误信息。
Code Access Security
代码访问安全
Code access security is a very powerful feature. It allows systems to be configured to execute partially trusted code without prompting the user. In fact, this is the default setting. Meanwhile, the partially trusted code is only allowed to do things appropriate to its level of trust.
代码访问安全是一个十分强大的特性。他允许在不提示用户的前提下将系统被配置为执行半信任代码。事实上，这是一个默认的设置。同时，半信任代码仅仅被允许做在其信任度下相应的事情。
Before moving forward, I would like to clarify a couple of points. The system decides what privileges the application, or more specifically the managed assembly, is allowed based on the location of the assembly file. This is why the assembly file has different abilities when it is launched from an enterprise share as opposed to the local machine. (It is also important for you to note that managed security policy is very configurable.)
再继续下去之前，我想澄清两个观点。系统决定应用程序是什么权限，或者更多特定的托管组件，是根据这些组件文件的位置而被允许的。这也就是为什么当组件在企业共享环境中运行与本地环境运行时组件文件拥有不同的能力的原因。
Also, the abilities of the FileToConsole.exe file are not entirely based on the logged-on user account. Although restricted by this, code access security further restricts the application depending on where it came from. This ability will remove the user's fear of running code from the Internet. Furthermore, code access security is more flexible and robust than a sandbox, although it can be used to solve similar problems.
同样，FileToConsole.exe文件的能力不是完全基于用户的登录账号。虽然受限于此，但是代码访问安全将根据这个文件的来源重新对其进行约束。这个能力将移除用户从英特网上运行代码的顾虑与恐惧。此外，代码访问安全与沙池相比更加灵活与强健，虽然它也可以用来解决相似的一些问题。
Before setting the FileToConsole.exe aside, I would like to mention one other test you can try. If you launch the file from a share, let's say from the x: drive, then you are not allowed access to files on your local system. If you pass a file name relative to the x: drive, for example x:SomeText.txt, then the application will succeed because the file comes from the same location as the application. This further demonstrates the real flexibility of code access security.
在设置FileToConsole.exe之前，我想提出另外的一个测试，您可以试一试。如果您从一个共享中运行这个文件，比如说从x:驱动器中，那么您无法允许文件访问您的本地系统。如果您传一个相对于x:驱动器的文件名称，比如x:SomeText.txt，然后应用程序将成功运行，因为文件来自于应用程序相同的位置。这个例子演示了代码访问安全的灵活性。
Code access security is used throughout the .NET Framework class library. It is the backbone of partially trusted code and is not restricted to file access, but rather affects everything from network access to windowing and more. When you use it in your own component code, users will be able to execute code regardless of origin (such as from an Internet site), and their systems will remain safe. This allows you to write code that is featureful, executes in native machine language, and is distributed across a LAN or even over the Internet. You can take advantage of this feature with only a minimal exposure to the underlying mechanics of code access security.
代码访问安全通过.NET框架类库来使用。他是半信任代码的基础并且不受限于文件访问，但是对于通过网络访问窗口或者其他的任何情况都有相当的影响。当您在您自己的组件代码中使用它时，用户可以在不用留心来源的情况下执行代码（比如从一个英特网网站），他们的系统仍旧是安全的。这是的您可以写出富有特性的、通过本机执行的并且分布访问局域网甚至是英特网的代码。您可以利用这些特性在代码访问安全的基础下最小限度的暴露您的信息。
All managed code, whether it is a standalone application, a control, or a DLL full of reusable types (or some mix of all of these), is packaged in a unit called an assembly (the unit of distribution, versioning, and security for managed code). For now, think of an assembly as a managed DLL or EXE file. When an application references a type or code from another assembly, the CLR must locate the file or files for the assembly and load them into your process. At assembly load time, the CLR associates security permissions with the newly loaded assembly based on evidence including, but not limited to, the location from which the assembly is loaded.
所有的托管代码，无论是独立的应用程序、一个控件、或者一个充满了可利用类型的DLL（或者一些包含了这些所有的混合体），被打包成一个单元叫做一个组件（托管代码的分发、版本控制以及安全的单元）。现在，将一个组件看作是一个托管的DLL或者EXE文件。当一个应用程序从另一个组件中引用一个类型或者一段代码的时候，CLR必须定位这个或者这些文件使得组件将他们加载到您的进程中。在组件加载时，CLR协同重加载的基于包含但不限于组件加载的位置的组件的安全权限一起工作。
Once the permissions are associated with the assembly, they will affect what the code in the assembly can do for the life of the application. Amazingly, an application can be comprised of multiple assemblies, each of which may be allowed or disallowed the use of different parts of the system based on the differing evidence found for each assembly.
一旦权限与组件协同工作，他们将影响到应用程序中组件的代码的生命周期。令人惊奇的是，一个应用程序可以由很多组件组成，每一个部分都可以被允许或不被允许基于每个组件找到的不同取证的系统不同部分的使用权。
If this is starting to sound a little confusing, perhaps an example will help. Suppose you have written a managed executable named MyApp.exe that is installed locally. MyApp.exe also references another managed assembly named Types.dll that is installed on a network share. The reason to reference another assembly is simply to make use of a type in that assembly, so let's assume that the SomeTypes.dll assembly includes the implementation for the CoolType class.
如果这开始听起来有些令人困扰，可能这个例子会有些帮助。假设您已经写好了一个托管可执行程序叫做MyApp.exe，并且已经在本地安装好了。MyApp.exe同时引用了另外一个安装在网络共享环境的托管组件叫做Types.dll。引用另外一个组件的原因可以简单的另在那个组件中的类型可以在这里使用，所以我们可以认为SomTypes.dll组件包含了CoolType类的实现。
Your main assembly is MyApp.exe and is stored on your local file system. This file is likely to contain the definition for several classes, including one that implements the static Main method that is used as the entry point for your application. Because MyApp.exe is stored on your local file system, all of the methods in all of the types in your assembly have total access to the system.
您的主要组件是MyApp.exe，其存储在你的本地文件系统中。这个文件可能包含了一些类的定义，包含了一个实现了静态Main方法用来作为您的应用程序的入口。因为MyApp.exe存储在您的本地文件系统中，您组件中的所有类型的所有方法都可以直接访问系统。
When a thread crosses the assembly boundary from MyApp.exe to Types.dll, the security will be restricted to the permissions awarded assemblies found on network shares. The thread crosses this boundary simply by calling into a method, constructor, or property in a type (such as CoolType) implemented in Types.dll. When the method eventually returns, the security permissions will be those of the more privileged MyApp.exe.
当一个线程通过MyApp.exe越界访问Types.dll，安全性将会为网络共享中的组件授予并限制权限。线程越界访问可以简单的通过执行一个方法、构造器、或者在Types.dll中实现的一个类型（比如CoolType类型）的属性。当这个方法最后返回值的时候，安全权限将会提供MyApp.exe更多的特权。
Code access security is a stack-based algorithm. The abilities of the code differ depending on the location of the instruction pointer in the managed application. The system is able to detect which method is attempting to perform a protected action and then, depending on the permissions of the assembly in which the method exists, allow the action to be performed or throw an exception of type SecurityException.
代码访问安全是一个基于堆栈的算法。代码的能力因在托管引用程序中构造指针的位置而不同。系统可以检测到哪一个方法试图去执行一个保护行为，然后，依据方法中存在的组件的权限，允许这个行为执行或者抛出一个SecurityException类型的异常。
There are two significant points about code access security. Code that works great when launched from a local drive may begin to throw security exceptions when launched from a network share or when run as a control embedded in an HTML page. This is because your assembly no longer has the unbridled access that it enjoyed when run from the local drive. Furthermore, code access security eliminates the need for messy dialog boxes asking users whether they trust your network or code downloaded from the Internet. Your managed code will just run (albeit with limited system access). This makes your code more useable and is one reason why the rich client is back in use.
对于代码访问安全这里有两点需要注意。在本地磁盘执行的代码当在网络共享或者作为一个控件嵌入在一个HTML页面的时候有可能抛出安全性异常。这是因为您的组件在本地不再拥有它曾享有的无约束的访问权限。此外代码访问安全忽略了弹出询问用户是否信任您的网络或者从英特网上下载的代码的对话框的需要。您的托管代码将会被运行（尽管是有限制的系统访问）。这使得您的代码更可用并且这也是为什么富客户端回归使用的原因。
If your software is going to be distributed over any kind of network, then it is likely that it will be partially trusted. This means that certain features of your application, such as file access, are likely to begin causing security exceptions. Your software should be able to recover from the security exceptions that might arise from its normal behavior as well as alter its functionality seamlessly.
如果您的软件将通过任何网络形式进行分发，那么很可能他将是半信任的。这意味着您的应用程序的某种特性，比如文件访问，将可能造成安全性异常。您的软件应该能够重新获得这些有可能被一些正常行为所抛出的安全性异常同时无缝地改变他的功能。

Isolated Storage
隔离存储
Sometimes your partially trusted code simply needs access to the file system without prompting the user for permission. Perhaps your code needs to cache user settings or a temporary data file but the default security cannot allow network-deployed code to access the general file system. The solution to this is a feature called isolated storage.
有时您的半信任代码仅仅需要在不提示用户需求权限的情况下访问文件系统。可能您的代码需要缓存用户的设置或者一个临时数据文件，但是默认的安全性与允许网络部署代码访问这个文件系统。这个问题的解决方案就是这个叫做隔离存储的特性。
Isolated storage is a great feature of the runtime. In fact, you should use isolated storage for storing your user configurations for managed applications regardless of whether your software is partially trusted. If your software is running in a Windows domain that supports roaming profiles, your user's isolated storage share will roam with the user's profile.
隔离存储是运行时的一个重要特性。事实上无论您的软件是否是半信任的，您都应该使用隔离存储来存储您的用户的托管应用程序的设置。如果您的软件运行在一个支持概要漫游（roaming profiles）的Windows域中，您的用户的隔离存储共享将会随着用户的概要而漫游。

Troubleshooting Browser Control Code
浏览器控件代码的疑难解答
Browser controls are a very cool application model for certain types of software. Before addressing some of the problems that can occur with browser controls, I would like to give you a general word of advice. To the extent that it is possible, write your browser-deployed code so that it can also be executed outside of the browser host. The security permissions will differ, but you can use the Zoner.exe tool to address this. Getting the core functionality of your code up and running is much more doable if you are executing your code from the debugger outside of the browser. That said, you are still likely to run into some snags, so I hope that the following tips will help.
浏览器控件是一个为某些类型的软件提供的非常酷的应用程序模块。在定位一些能够因为浏览器控件而导致的问题之前，我想给您一些一般性的建议。广义上来讲这是可能的：写一个浏览器部署的代码，这个代码仍旧可以在浏览器以外执行。安全性权限将会不同，但是您可以使用Zoner.exe工具来对付这个。唤醒您的代码的核心功能，并且如果您在浏览器外的调试器中执行您的代码的话将其运行。也就是说，仍旧会出现一些问题，所以我希望以下的提示会有所帮助。
Although it is generally unacceptable to write code that catches the base exception (System.Exception), with browser controls you have no choice. Owing to security restrictions, you cannot register an unhandled exception handler, and therefore all of your virtual method overrides and all of your public methods and constructors must catch System.Exception. Otherwise, the exception is caught by the class library (or worse, the host), and the user will be presented with a dialog box in the best case and a missing control in the worst case. I suggest creating a method that logs exception information and calling that method in the catch block of your exception blocks. This way you can find the unexpected exceptions during the testing phase and address them in some manner more appropriate than a catch for all exception types.
虽然写代码接收基本异常（System.Exception）一般来说是不被接受的，但如果是浏览器控件，您别无选择。没有任何安全性约束，您不能注册一个无法处理的异常处理器，因此您所有重载的虚拟方法以及所有的公共方法以及构造器必须接收System.Exception。否则，异常将会被类库接收（或者更糟，被宿主机），最好的情况下用户仅看到一个对话框，最糟糕的情况下则显示缺失控件。我建议创建一个方法记录异常的信息，并且当出现异常时调用这个方法并遮蔽掉您所抛出的异常。这个方法在测试以及定位这些异常的时候，您可以找到这些意外的异常，总比接收所有异常类型要更加合适。
The next tip is about virtual root settings. Surprisingly, if the IIS virtual root is set to allow execute permissions of "Scripts and Executables," your managed browser control will not be hosted by the browser because IIS will treat dll or exe like an ISAPI and try to run it. Setting the execute permissions for the virtual root to either "Scripts" or "None" will allow your control to be hosted.
下一个提示是关于虚拟根目录设置的。出乎意料的是，如果IIS虚拟根目录被设置为“脚本以及可执行程序”的允许执行的权限，您的托管浏览器控件将无法在浏览器中被控制，因为IIS将像对待DLL或者EXE像一个ISAPI一样尝试着运行它。将虚拟根目录的执行权限设置为“脚本”或者“无”，这样允许您的控件被受控执行。
If your Control-derived type is not marked as public, and if it does not have a public default constructor, then it will not be hosted in the browser.
如果您的派生容器类型无法标记为公共，并且如果其没有一个公共默认的构造器，那么他将不会被浏览器控制并运行。
Although Form is derived from Control, your browser control cannot be derived from Form. If it is, the host will refuse to embed your control in the page.
虽然表单派生于控件，但是您的浏览器控件无法派生于表单。如果是这样，宿主机会拒绝将您的控件嵌入到页面中。
Some security restrictions do not show themselves as a SecurityException. For example, if your type overrides WndProc (a restricted feature), your type simply won't load in the browser. No exception is thrown because the code never even gets the opportunity to run.
一些安全性约束不会将自己显示为SecurityException。比如说，如果您的类型重载了WndProc（一个受限特性），您的类型简单的来说不会被浏览器加载。因为代码永远没有机会执行，所以没有任何的异常抛出。
Finally, if the control is not showing up in the browser, it is likely that it is because the object's constructor threw an exception that was not caught. You can use a blend of exception handling blocks and MessageBox.Show calls to find out if, and to what point, your code is being executed. If the constructor for your object is not being called at all, then it is most likely having trouble finding the assembly or finding the control type. In addition, the virtual root settings might also be wrong.
最后，如果控件没有在浏览器中显示出来，可能是因为对象的构造器所抛出的异常没有被接收。您的代码被执行您可以使用一个异常接收模块以及一个MessageBox.Show的混合体如果来找到问题所在。如果您的对象的构造器从来就没有被执行过，那么问题很有可能是出在寻找组件以及寻找控件类型上。另外，虚拟根目录设置也许设置出错。

The Rich Client in the Future
富客户端的未来
The possibilities for managed code as it matures are many. The infrastructure that code access security and CLR deployment bring to the table enables some cool possibilities. For example, clients that execute code such as Outlook and even Internet Explorer itself can be modified to allow administrators to enable the execution of managed code only. In systems where this is the case, users can freely execute attachments in mail messages as well as code across the Internet without worry of viruses or Trojans. Meanwhile, managed code executes in native machine language and enjoys rich access to OS features.
托段代码随着它自己的成长，将有跟多的可能性。在代码访问安全以及CLR部署的基础上带来更多更酷的可能性。比如，客户端可以执行代码，比如Outlook甚至是Internet Explorer本身可以修改，允许只有管理员开启托段代码的执行。在这个实例的系统下，用户可以自由运行邮件信息中的附件以及在没有病毒与木马的担忧下访问英特网。同时，托管代码以本机语言执行，访问并享受丰富的操作系统特性。
As the .NET Framework and managed infrastructure matures so will the rich client application. There are many exciting features yet to come. Meanwhile, the functionality available today allows you to create very compelling applications.
当.NET框架以及托管基础构架令富客户端应用程序成熟起来，更多激动人心的特性还会到来的。同时，现今可用的功能可以让您创建出非常可信的应用程序。
The browser control and partially trusted code open the door to some very interesting possibilities using managed code. Enterprise applications can be installed on a share in the network and no more than a shortcut needs be deployed to the user's system. The code base can be updated on the share as needed without concern for installation and configuration problems.
浏览器控件与半信任代码为一些使用托段代码的非常有趣的可能的功能打开了大门。企业级应用程序可以被安装在一个共享的网络上，仅仅需要的是在终端系统部署一个快捷方式。代码库可以在需要的时候在共享上进行升级，无需担心安装与配置的问题。
Meanwhile, browser deployed software can be as rich as any other application. For enterprise software the .NET Framework rich client is a real benefit since enterprise networks tend to enjoy the advantages of relatively homogeneous client machines and reliable bandwidth.
同时，浏览器部署软件可以像其他应用程序一样丰富。对于企业级软件，.NET框架富客户端从企业网络转向享受相对同次的客户端以及可靠的带宽的优点来说是真正有优势的。