智能客户端的特点：
- 无接触部署：安装时只要将一个主程序文件下载到本地，直接运行即可，无须改变注册表或共享的系统组件，其他应用组件将在第一次运行时自动下载。 (客户端需要安装.net framework)
- 自动更新：只需将新版本的程序发布在服务器上，由客户端自动发现最新版本的程序和应用组件，并自动下载和更新。
- 离线运用：允许脱离服务器时，利用本地的客户端程序和应用组件进行工作。
- 动态加载应用组件：应用软件开发商可根据企业应用系统的公共接口进行开发，然后将应用组件发布在企业的服务器上，客户端应用程序将自动发现并加载该应用组件。
- 个性化用户界面：用户可根据喜好自行设置客户端应用程序，配置信息将被保存到服务器上。
就优点而言，它适合于需要将富客户端与瘦客户端的优势共同结合的情况下，但这也带了一些不大不小的问题，比如说，对于十分实时数据的访问，就不应该算是智能客户端范畴内的东西。
运行方式
客户端应用程序有两种运行方式，不同的运行方式将直接影响以后的程序集发布和更新，以下将详细解释：
1、网络运行
.NET Framework 安装提供了一个挂接 Internet Explorer 5.01 和更高版本以侦听所请求的 .NET 程序集的机制。在请求期间，可执行程序被下载到磁盘上称为程序集下载缓存的位置（Windows2000下为：
C:\Documents and Settings\Administrator \Local Settings\Application Data\assembly下的某个子目录中）
同时该程序集本身以及它引用的其他相关程序集也被下载到本地IE缓存中（Windows2000下为：
C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files）
然后，名为 IEExec 的进程在具有有限安全设置的环境中启动该应用程序。例如：您可以在IE的地址栏中输入一个已发布在web服务器上的.net可执行程序（http://SmartClient/MyApplication.Exe），IE并不会像其他文件一样提示您另存为，而是直接执行该程序。
通过这种方式运行的应用程序拥有非常有限的安全设置（Internet权限集），该权限集中的权限包括：安全性、文件对话框、正在打印、独立存储文件、用户界面。独立存储文件允许您的应用程序保存一些数据（Windows2000下为：C:\Documents and Settings\Administrator.TOMATO\Local Settings\Application Data\IsolatedStorage下的某个子目录中，默认存储空间大小为10MB）,您可以通过System.IO.IsolatedStorage命名空间中的类来保存数据而不会抛出安全异常。
可以发现，程序集下载的位置是固定的，.net Framework安装时，为IE添加了一些新的功能，用于专门支持智能客户端，这种意义上的智能客户目前只局限于微软自身的浏览器，不知在“长角牛”中，又会如何？期待中。
10M的空间对于某些应用来说，也许的确是有些捉襟见肘了。这里需要随时都记下默认情况下的权限，避免在开发时，犯下错误。“您可以通过System.IO.IsolatedStorage命名空间中的类来保存数据而不会抛出安全异常。”作为一个技巧性的方案，也应随时注意。
举例：
//按用户、域、程序集获取独立存储区
IsolatedStorageFile isoStore = IsolatedStorageFile.GetStore(IsolatedStorageScope.User | IsolatedStorageScope.Domain | IsolatedStorageScope.Assembly, null, null);
//创建目录
isoStore.CreateDirectory("TestDir");
//创建文件
IsolatedStorageFileStream isoStream1 = new IsolatedStorageFileStream("TestDir//test.txt", FileMode.Create, isoStore);
//写入文件
StreamWriter writer = null;
writer = new StreamWriter(isoStream1);
writer.WriteLine("Hello Isolated Storage");
writer.Close();
isoStream1.Close();
没有什么太多说的，这段代码，每次记得加入就行了。
为了让你的智能应用程序运转，你需要改变一些客户端的安全设置，实质上就是通知客户端运行时间相信你的应用程序。一种方法就是将带有你的程序集的站点添加到IE中可信任站点清单中，然后用安装在你的管理工具目录下的Microsoft .NET Framework Configuration工具来修改.NET Framework安全设置。打开Framework Configuration工具，选择运行库安全策略，然后选择调整安全区域。对于受信任站点中指定的所有站点，将信任级别调整到完全信任。作为选择，你也可以用Framework Configuaration工具来修改安全策略，使它信任你的应用程序的个别程序集。右击运行库安全策略，选择提高程序集的信任级别。
这样做，会带来一些不必要的困扰，难道要客户每台机器都如此手动设置吗？应该有直接调整安全性设置的手段吧，但.net本身编写的程序不知是否有这种权限，如果有，也会带来不必要的问题，这一块不是很清楚，不知道是否有解决方案。
另一个可选择的方法就是用代码组，用Framework Configuration工具来帮助你提高应用系统的程序集的安全设置。你需要让所有运用你的应用程序的桌面用户做这种改变。为了帮助完成该任务，Framework Configuration工具可以创建一个包含安全策略的Microsoft Installer （MSI）部署包。MSI安装了应用程序加载器来分布你的应用程序需要的安全策略和加载器装配。右击运行库安全策略，选择创建部署包。
OH，MyGod，这里提到了，使用Framework Configuration工具来创建一个部署包，就可以解决问题，呵，这样解决不错，看样子，.net在智能客户端上的应用考虑还是比较周全的。
在网络运行中，自动更新是依靠IE的缓存机制来完成的。即当您需要下载并运行一个应用程序时，IE将向Web服务器发送一个HTTP请求，该请求将获取服务器上该程序的最新更新日期，如果该日期大于本地缓存的程序的日期或者本地缓存中不存在该程序，则从服务器上下载，否则直接使用本地缓存的程序。因此对于.net本身所具有的版本机制而言，不能作为版本更新的依据，只有在某个程序集文件引用另外一个程序集时，才会由.net运行时依据自身的版本机制判断版本号。
根据时间来做，服务器与客户端的时间是否需要统一，不一样的话是否会有影响， 该更新日期的机制是什么样的？它是依据程序的创建时间还是什么？考虑到，客户端的软件在运行时，是从服务器上下载的文件，也许这方面不会受到影响，但是，在时间严重不统一时，是否会有不可预知的因素存在？
注意事项：
- 加载应用组件时，需要一个完整的url地址。
- 这种运行方式通常需要在运行前先设置用户的安全策略。
- 如果应用程序集中需要调用Web Service，该Web Service所在的服务器地址只能是最初下载程序集的服务器，可以构造一个重定向来解决该问题。
- 某些文件可能不能通过自动更新机制来完成版本更新，如：.Config应用程序的配置文件。
- 如果某些应用程序集文件的版本之间存在着某些关联性，则在某些情况下（如：网络突然中断）可能会出现不能正确加载并导致客户端应用程序出错的问题。
- 如果用户清空IE的缓存，则客户端应用程序将不能离线工作。
在注意事项中，注意到这些问题都很重要。比如对Web Service调用的限制，.Config应用程序的配置文件不会自动更新，程序集间如果出现版本的关联性的时候，还有，网络的突然中断，造成的影响。都是实际应用中，十分常见的问题，也是十分棘手的问题。这里只提出了注意事项，并没有给出遇到此类问题的解决方案，看样子，可能还需要进一步的探索。
2、本地运行
顾名思义，这种运行方式客户端应用程序和其他应用组件并不在IE缓存和.net下载缓存中运行，需要用户首先下载客户端程序集并保存到一个本地目录下，然后运行。这样客户端应用程序以及其他应用组件就拥有了所有的本地安全权限。
这似乎是一个听起来不错的主意，但这与C/S有何区别？继续看下去..........
虽然不涉及安全性问题，但应用组件以及程序的自动更新如何实现？这就需要一个单独的组件来完成这些任务。通过该链接地址可以下载一个非常完善且支持扩展的自动更新组件（http://www.gotdotnet.com/team/windowsforms/DotNetUpdater.zip），该打包文件中提供了源码、一些例子以及文档。该更新组件使用HTTP-DAV技术来完成文件在服务器和客户端之间的传输，因此对Web服务器有一定的限制，IIS5.0和新版本的Apache支持该功能。具体使用方式请参见内含文档。
此组件可以在IIS及Apache上运行，难道Apache也支持Asp.net？噢，以前还真没注意过，哈哈哈............
DotNetUpdater.zip，看样子是个好东西，居然会用“非常完善且支持扩展的自动更新组件”来描述它，希望不是广告，能够在IIS及Apache上使用，可以满足不少的需要了。
注意事项：
- 由于需要自己来实现更新和下载功能，所以会增加一定的工作量。（就是使用第三方的更新组件，也需要对其进行完善以满足自己的要求）
，果然是广告，晕倒~~~~~~~~~~~。刚才才说“非常完善且支持扩展的自动更新组件”，转眼之间，注意事项中就说，使用第三方组件，也需要对其完善以满足自己的要求，估计此话的份量甚重，超过了“非常完善且支持扩展的自动更新组件”的描述。
- 基本解决了网络运行的缺点，但需要每次更新时重新下载所有的文件（如果采用增量更新的话，某些情况下会出现某个版本的文件被遗漏的问题），会增加网络流量。
“如果采用增量更新，某些情况下，会出现某个版本的文件被遗漏的问题”，更晕，这不是玩幽默吗？如果是这样，增量更新还有什么用？哪些情况下，会出现遗漏，也没有说个清楚明白。
- 应该在后台线程中执行更新和下载，不影响用户的正常操作。
天呐，原来所以用的智能是自己做的？开发上，要顾虑如此之多的问题，这也叫直接支持？也叫提供了完善的支持？
我在思考，比起直接用非.net的开发，.net平台对于智能客户端的开发优势在哪儿？