我的窝

http://stackoverflow.com/questions/11221511/predefine-xml-namespaces-for-datacontractserializer

这个办法不错，简洁安全。

其他的一些设置其实不是做这个用的：

var writer = XmlWriter.Create(compressedStream, new XmlWriterSettings
? {
????? OmitXmlDeclaration = true,
????? NamespaceHandling = NamespaceHandling.OmitDuplicates,
????? Indent = true
? });

用Resolve KnownType的办法（静态或动态）只能解决自定义类型的重复xmlns问题。

http://blogs.msdn.com/b/youssefm/archive/2009/06/05/introducing-a-new-datacontractserializer-feature-the-datacontractresolver.aspx

1. http://beyondrelational.com/quiz/dotnet/general/2011/questions/serilization-vs-data-contract-in-wcf.aspx

这篇文章提到了DataContract和[Serializable]可以一起使用，因为对应他们的Serializer是父子类关系。如果发现子属性不再是DataContract,会自动去尝试[Serializable]

2.http://www.danrigsby.com/blog/index.php/2008/03/07/xmlserializer-vs-datacontractserializer-serialization-in-wcf/

这篇很久之前就看过。里面提到上面两者的[opt in]和[opt out]的区别，所以，[DataMember]要加了才会序列化

?

关于Fiddler,在调试中，这东西非常重要，当调试本地的WebDev的WCF服务时，这个tips很有用：

http://blogs.microsoft.co.il/blogs/davids/archive/2009/05/27/fiddling-with-fiddler-2-on-localhost.aspx

这篇文章介绍了MessageContract,评论里有引用到另一篇文章的。但是实际上似乎如果只是为了Soap的Header/Member这种不是很重要的功能来用MessageContract不是很值得。而如果说是为了xml的简洁，那么用DataContract加上这篇文章里的方法也比较简洁的。

http://stackoverflow.com/questions/1042881/why-session-end-event-not-raised-when-stateprovider-is-not-inproc

回答里有几个有用的链接，包括msdn官方的定义和一个自定义的StateProvider下包装Session的Timeout并触发事件的做法（代码里是利用Cache的自动失效)，达到和inproc的session_end事件类似的效果。

Session_End event fires only when session reached to idle timeout. It does not fire when some navigates to someother or closed the browser window. We can’t relay on Session_End event to check user is logged out / not.