这周一的时候，公司电脑出了问题，由于这台电脑CPU是64位的，以前操作系统是别人装的，装的是32位的。这次我就把它装成了64位的操作系统，这一周用下来，用64为操作系统，最少发现两个郁闷的事情。
1、微软最近发布了一个安全性补丁（KB914784 ），这个补丁让所有之前可用的64位操作系统下的虚拟光驱都没法用了。
要想用虚拟光驱，就得卸掉这个补丁，要不就不能用虚拟光驱。而且据 Daemon Tools 的说，要解决这个问题，比较麻烦。不知道啥时候。
参看：
After Update of XP or Server 2003 x64 Editions Daemon Tools does not work anymore
http://www.daemon-tools.cc/dtcc/showthread.php?goto=newpost&t=12103
2、目前64为操作系统下，打了所有微软补丁的电脑，如果你开发或编译一个链接Access数据库的程序，你会收到如下的异常：
An unhandled exception of type 'System.InvalidOperationException' occurred in System.Data.dll
Additional information: The 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine.
原因，微软JET数据引擎的兼容性问题。
解决方法参看：
64位XP操作系统下访问Access数据库的问题及解决
http://cajon.cnblogs.com/archive/2006/05/30/413408.html
晕，竟然丢了我一篇blog，更晕的是我本地没备份，但是这篇竟然在其他站点找到了。
找到的地方：
http://java.bokeland.com/blog/359/1012/2006/06/21/18257
目前版本WSE3.0的两个小bug
1、无法识别最新的VS 2005 Web Application Projects 。
结果把这类项目识别成非Web项目，一些Web项目的配置在这类项目中无法配置。
2、帮助文件跟IE7冲突
如果你装了IE7Beta2，你访问WSE3.0的帮助文件。
会报错误：
--------------------------- 错误 ---------------------------
A Runtime Error has occurred. Do you wish to Debug?
Line: 98 Error: Could not complete the operation due to error 80041001.
--------------------------- 是(Y) 否(N) ---------------------------
调试进去就会看到在以下userDataCache.load("docSettings"); 这么一行错误：
function Load(key)
{
userDataCache.load("docSettings");
var value = userDataCache.getAttribute(key);
return value;
}
This function is called from script.js
参看以下联接：
WSE3.0帮助文件跟IE7Beta2有矛盾
我们可以在自己的服务程序或者企业服务程序中，编写自定义安装类（从System.Configuration.Install.Installer 类中派生）。
然后我们就可以用InstallUtil.exe 或者 InstallUtil.exe /u 来安装或者卸载这个组件。我们重载System.Configuration.Install.Installer 类的Install和Uninstall方法，
public override void Install(IDictionary stateSaver)
public override void Uninstall(IDictionary savedState)
并且在这些方法中借用RegistrationHelper 、RegistrationConfig 等配置类，就可以让我们组件实现很多丰富的安装功能。
比如如果是企业服务，安装的时候，自动把组件所在目录设置成ApplicationRootDirectory。
又比如把一些相关组件放到GAC中等等。
不过我们在卸载的时候，有可能会碰到类似下面的异常：
试图在 User.EnterpriseServices.dll 程序集中查找安装程序时发生异常。
System.Reflection.ReflectionTypeLoadException: 无法加载一个或多个请求的类型。有
关更多信息，请检索 LoaderExceptions 属性。
正在中止安装 User.EnterpriseServices.dll。
在卸载 System.Configuration.Install.AssemblyInstaller 安装程序的过程中发生异常。
System.InvalidOperationException: 无法获得 User.EnterpriseServices.dll 程序集中的安装程序类型。
引发了内部异常 System.Reflection.ReflectionTypeLoadException，错误信息如下: 无法加载一个或多个请求的类型。有关更多信息，请检索 LoaderExceptions 属性。
在卸载的过程中发生异常。将忽略该异常并继续卸载。但是，在卸载完成之后应用程序可能未完全卸载。
这时候一般产生的原因是你在自己配置的安装或者卸载的时候得顺序有问题。比如一些企业服务组件要加载的一些组件被你先从GAC中卸载了，就可能会导致这个异常，只要改变一下卸载或者安装的顺序，则就可以避免这个错误发生。
1、默认情况下，类型中由 SerializableAttribute 标记的所有公共和私有字段都会进行序列化，除非该类型实现 ISerializable 接口来重写序列化进程。
2、默认的序列化进程会排除用 NonSerializedAttribute 属性标记的字段。如果可序列化类型的字段包含指针、句柄或其他某些针对于特定环境的数据结构，并且不能在不同的环境中以有意义的方式重建，则最好将 NonSerializedAttribute 属性应用于该字段。
我和同事最近在作的项目中，用了微软企业库的来处理缓存，而这个缓存又是封装在企业服务中。
要封在企业服务中的组件必须签名，同时他暴露的输入输出参数必须被序列化。
我们就是没留意到标志序列化默认也会把私有字段进行序列化。而产生下面的异常。
程序集“Microsoft.Practices.EnterpriseLibrary.Caching, Version=2.0.0.0, Culture=neutral, PublicKeyToken=.....”中的类型“Microsoft.Practices.EnterpriseLibrary.Caching.CacheManager”未标记为可序列化。
不过，
如果发生了跨组件类暴露，比如企业服务A组件项目中暴露了B组件项目的一个公共类C。而C类中又有一个私有类实例D，
而D类被定义成internal的。则这个企业服务组件项目不会自动序列化D类。
但是如果D类被定义成public的，则会自动序列化D类。
