学习

你是否考虑过Jenkins和NUnit的集成 我之前使用TFS时，是用NUnit生成xml报告，再转成trx文件的 你是否也可以考虑这样做呢？

提高隔离级别并不一定能解决死锁. [code=sql] --低隔离级别 SET TRANSACTION ISOLATION LEVEL READ COMMITTED BEGIN TRAN SELECT * FROM customer WHERE id=2; WAITFOR DELAY '00:00:05'; UPDATE customer SET name=name+'a' WHERE id=2; COMMIT [/code] [code=sql] --高隔离级别 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE BEGIN TRAN SELECT * FROM customer WHERE id=2; WAITFOR DELAY '00:00:05'; UPDATE customer SET name=name+'a' WHERE id=2; COMMIT [/code] 同时多次运行上面的SQL,在SERIALIZABLE级别下,报Transaction (Process ID 53) was deadlocked on lock resources..，但READ COMMITTED级别都能成功.

TransactionScope属于乐观并发，在用的时候，外面套一个lock更保险些

同样纠结中

UTC时间在表示上是不用时区的，因为是一个标准嘛，但实际上当然也是有时区的，它与格林尼治平均时间相同，时区也就是伦敦的时区。

[code=csharp] public class DateTimeSurrogate : IDataContractSurrogate { #region IDataContractSurrogate 成员 public object GetCustomDataToExport(Type clrType, Type dataContractType) { return null; } public object GetCustomDataToExport(System.Reflection.MemberInfo memberInfo, Type dataContractType) { return null; } public Type GetDataContractType(Type type) { return type; } public object GetDeserializedObject(object obj, Type targetType) { //if (obj.GetType() == typeof(DateTime)) //{ // DateTime dt = (DateTime)obj; // if (dt == DateTime.MinValue) // { // dt = DateTime.MinValue.ToUniversalTime(); // return dt; // } // return dt; //} //return obj; return obj; } public void GetKnownCustomDataTypes(System.Collections.ObjectModel.Collection<Type> customDataTypes) { } public object GetObjectToSerialize(object obj, Type targetType) { if (obj.GetType() == typeof(DateTime)) { DateTime dt = (DateTime)obj; if (dt == DateTime.MinValue) { dt = DateTime.MinValue.ToUniversalTime(); return dt; } return dt; } if (obj == null) { return null; } var q = from p in obj.GetType().GetProperties() where (p.PropertyType == typeof(DateTime)) && (DateTime)p.GetValue(obj, null) == DateTime.MinValue select p; q.ToList().ForEach(p => { p.SetValue(obj, DateTime.MinValue.ToUniversalTime(), null); }); return obj; } public Type GetReferencedTypeOnImport(string typeName, string typeNamespace, object customData) { return null; } public System.CodeDom.CodeTypeDeclaration ProcessImportedType(System.CodeDom.CodeTypeDeclaration typeDeclaration, System.CodeDom.CodeCompileUnit compileUnit) { return typeDeclaration; } #endregion } 然后这样序列化 DataContractJsonSerializer serializer = new DataContractJsonSerializer(o.GetType(), null, int.MaxValue, false, new DateTimeSurrogate(), false); [/code]

UTC时间是标准时间没有时区而言的吧。LocalTime是+8区转换为UTC时需要减8。。。。。MinValue本身已经是0了。

楼主的两个drive方法是不是都写错了?

@Artech 多谢Artech对拙文的指点~

感觉LZ的逻辑有点混乱： 1."如果这样(客户端认证)还不能安全要求，那只好再启用传输层加密，即SSL了". SSL是一种安全模式，和认证的关系并不是一种“安全加强”的关系； 2."实际上在WCF中，验证方式也被分为两个层次：Transport和Message"。我们一般称Transport和Message为两种“安全模式”，而不会称它们为安全层次。此外Transport和Message是“安全传输”的模式，而不是验证的模式。安全传输包括认证、消息一致性和机密性。 3. "在传输层加密数据，在消息层提供凭据验证及授权" 正如上面所说，Transport和Message是“安全传输”的模式，基本上不涉及授权。认证是在信道层实现的，而授权则是在服务模型层实现的。 4."这个方案的好处是什么呢？TransportWithMessageCredential确保了传输上的安全，并提供了客户端凭据" 这其实不是TransportWithMessageCredential（Mixed）的好处，Mixed模式的真正好处是吸取了Message模式能够提供认证多样性，又能通过Transport提供更高的性能。

@Artech 没错，可能我的表达让你产生了误解，我认为这至少是形式上的依赖，算是比较轻微的依赖，因为在使用服务端授权时，就需要明确使用Thumbprint而不是role/group name了~ 授权对验证存在着依赖，这种依赖就是要求验证通过的信息能够满足授权的需要，例如ClientCredentialType=UserName,而服务端验证采用MembershipProvider的时候，那么服务端授权的选择就会受到影响，比如就不能选择UseWindowsGroup。当然这只是一个小例子。

[quote]Bright Zhang： @Artech 多谢Artech指正，这个地方我确实弄错了。授权和验证分离，不会依赖于验证，除非验证的类型是证书，需要在授权时针对证书来授权，只要principalPermissionMode="UseAspNetRoles"，在服务端就会把RoleProvidePrincipal写入Thread.CurrentPrincipal。[/quote] 即使是证书，也可以用ROleProvider来进行授权，不过此时的User Name为"CN=<Subject Name>; Thumbprint".

@Artech 多谢Artech指正，这个地方我确实弄错了。授权和验证分离，不会依赖于验证，除非验证的类型是证书，需要在授权时针对证书来授权，只要principalPermissionMode="UseAspNetRoles"，在服务端就会把RoleProvidePrincipal写入Thread.CurrentPrincipal。

[quote]WCF使用RoleProvider做服务端授权，要求客户端认证信息的类型是UserName(ClientCredentialType=UserName)[/quote] ClientCredentialType决定Authentication，而Authorization和Authentication是分离的。也就是说，如果你采用RoleProvider才进行授权，并要求你一定要采用UserName类型的客户端凭证类型，你采用Windows和Certificate的时候，一样可以采用RoleProvider。

哈哈！

如果客户能有这种觉悟多好啊。

@Virus-BeautyCode AD不是什么高深的，难以维护的东西。

即直接使用windows的用户组（AD)已经可以做到基本的权限控制要求了 ------------ 这个说得对，很多人自己搞一套，结果很复杂而且不是真正安全，使用一点也不方便。

AD,是普通人能管理的吗？？ 是普通人能维护的吗？ 说的容易，很少客户愿意使用AD的。