茫茫沧海

故障原因：前段时间，网络不稳定，时断时续，而工作照样进行，程序照样写，结果偶尔签出失败、偶尔签入失败，大家最终都不知道是否将自己的代码更新了。
故障现象：后来发现了一个严重的问题，某些新建的项目或者文件，在本机上存在，服务器和其它机子不存在，并且无需签出便能随意新增、修改、删除，而当签入时，在修改记录中并不存在。

研究结果：郁闷了很久，检查了各种配置和属性，最后终于将问题锁定在TFS的解决方案文件.sln，估计是本地文件之后并没有与服务器同步更新，具体代码我没有做仔细研究

解决办法：最终，通过获取历史版本的解决方案文件.sln，并添加现有项目和文件将故障解决。(部分项目会自动完成添加)

后来发现当VS不正常关闭时，也会出现这种情况，并且，如果没有及早发现，将很难解决。在最坏的情况下只能新建解决方案，将项目全部手动添加，并将所有文件拷贝到对应的目录，再进行一个引用设置，才能恢复故障。

下面就简述统一认证系统的应用子系统Session的共享的实现，我和一位同事根据大伙的讨论结果，分两种方式进行实现，详细情况如下：

第一种方式：通过MD5加密随机字符串，使用了Web服务实现了子系统和统一认证系统之间的交互验证。验证信息包含两部分用户在统一登录系统的Session ID和数据库中的随机ID。当子系统将用户重定向到统一登录系统的时候，验证的交互过程开始，详细步骤如下：
1、统一登录系统获取用户的Session ID和登录名
2、统一登录系统将Session ID和登录名插入到数据库，产生一个随机的数据库ID
3、将Session ID和数据库ID结合起来，进行MD5加密
4、使用MD5密文和数据库ID构建一个登录等待页面，返回给用户
5、用户将登录等待页面中的信息自动提交给子系统
6、子系统通过Web服务将MD5密文和数据库ID提交回统一登录系统
7、统一登录系统查询数据库，并进行验证
8、统一登录系统返回用户登录名，并删除数据库中的登录记录。
9、子系统与用户建立认证关系

图 3. MD5随机加密，Web服务实现验证

第二种方式：通过对认证信息（登录令牌）进行非对称加密，一次交互实现验证。验证信息为一个包含了产生时间的Token类。验证的交互过程同样是在重定向到统一登录系统的时候开始，详细步骤如下：
1、构建一个包含生成时间的Token类，将Token类序列化
2、使用SHA-1，对序列化Token编码进行散列，产生验证码H
3、将序列化Token编码和验证码H结合，使用公钥加密
4、使用密文构建一个登录等待页面，返回给用户
5、用户将登录等待页面中的信息自动提交给子系统
6、子系统使用私钥进行解密
7、子系统分离出散列验证码H和序列化Token编码，并进行SHA-1验证
8、检查Token中的生成时间，判断是否超时
9、子系统与用户建立认证关系

图 4. 非对称加密，一次交互实现验证

两种方式各有优缺点，大家很明显就能看出，我就不做总结。我们最终选择的方案是第一种，并且在验证过程中增加了一个Session识别子系统，防止非法的阻塞和冒充。即在应用子系统将用户重定向到统一认证系统系统时，子系统与用户建立Session，并在用户转交认证信息时，验证是否原本用户。防止有非法者获取了和用户转交的认证信息，并在用户之前提交给子系统，骗取认证。

根据我们的需求，用户的体验一般有两种：
一、对于使用多个子系统的用户，将有可能直接登录统一认证系统，并通过统一系统的子系统连接列表，跳转到多个子系统；二、对于一些使用单个子系统，或者自为单具体事情进入我们平台，或者是登录超时了，这是他应该向直接进入特定子系统，那么我们需要将登录验证在他进入子系统之前插入。两种不同方式的三个系统之间的交互过程如下图所示：

图 1. 一般步骤，同时登录多个子系统


图 2. 直接进入子系统，子系统之间跳转

我将按照第一种交互方式进行解释：
1、用户先与统一登录系统进行交互，使用唯一的帐号密码进行登录，此时不涉及任何子系统；
2、用户登录成功后，统一登录系统将信任的应用子系统列表呈现给用户；
3、用户根据需要，选择子系统连接访问子系统，用户与子系统的交互开始；
4、由于用户与子系统此时还没有建立认证关系，所以子系统将用户重定向到统一登录系统；
5、统一登录系统验证用户的登录信息，发现用户已经登录，便将登录信息插入到数据库，再将验证信息发给用户，即返回一个等待页面；
6、用户将等待页面中的验证信息提交（自动）到子系统，子系统获取认证信息；
7、子系统通过一定的办法和等待页面中的验证信息进行验证，并与用户建立了信任关系；
与ASP.NET封装的实现方案项目，这交互过程看起来十分烦碎，我们还需要自己实现大量的功能。但我们的交互实现过程都是可控的，各个系统之间传递的信息内容，什么时候传递，我能都可以限制和约定，并且能够将每一次系统之间的交互记录都进行登记，这才是我们需要的。至于烦碎，其实对用户来说，增加的步骤就是出现自动提交的等待登录页面，如果两个系统都能正常运行，网络也没有出现堵塞，用户等待的时间将及其短暂，甚至没能看到页面。并且我们能够对等待页面做一定的美化，使用户就算看到等待页面，也不会感到厌烦。

说了这么多，统一认证系统的应用子系统Session的共享还没有开始，这是本方案最大的难点......

ASP.NET 支持三种会话状态模式：
InProc：In-Proc 模式将值存储在 ASP.NET 辅助进程的内存中。因此，该模式提供了对这些值的最快访问。但是，当 ASP.NET 辅助进程被回收时，状态数据便会丢失。
StateServer：与上一模式不同，StateServer 模式使用独立的 Microsoft Windows 服务来存储会话变量。因为该服务独立于 Microsoft Internet Information Server (IIS)，所以它可以在另一独立的服务器上运行。您可以将此模式用于负载平衡解决方案，因为多个 Web 服务器可共享会话变量。尽管在重新启动 IIS 时会话变量不会丢失，但在跨越进程边界时，性能会受到影响。
SqlServer：如果会话信息的持久性对于您很重要，那么您可以使用 SqlServer 模式，以便利用 Microsoft SQL Server 来确保达到最高级别的可靠性。SqlServer 模式类似于进程外模式，只是前者的会话数据维护在 SQL Server 中。SqlServer 模式还让您能够利用位于 IIS 进程外的一个状态存储区，该状态存储区既可位于本地计算机上，也可位于远程服务器上。

网站的默认Session状态模式应该是InProc，限制了本系统网站使用。StateServer和SqlServer都作为扩展，将会话信息存储在IIS进程之外，实现了不同Web服务器之间的共享。当然，这两种模式都需要做相应的配置和消耗一定的性能，我们暂且不说这一点。仔细研究发现，这两种扩展模式主要面向的是网站的分流和负载均衡，共享Session的网站之间的结合是非常非常密切的，并且ASP.NET将所有的实现都进行了封装，我们无法获取和记录每一次共享的细节。这并不适合我们最开始的需求。
假设：A系统通过Session保存了一个User实例，那么如果B系统需要使用这个Session，则必需拥有A系统中User的细节。如果A、B两个系统是完全不同，甚至其中不同细节User类，更甚至A、B系统中都不只一处功能使用到Session，Session的命名又总碰巧一致。呵呵，那一切将变得不可思议。当然，如果我A、B为统一个系统的两个不同的应用层，那StateServer和SqlServer这两种方式将能够很好的满足需求。至于要满足我们上面的需求，只能是另外想办法了。

寻找解决办法，我们比较关系用户体验，那么先从用户的使用流程开始.......

随着数字化的不断普及，大型公式或者单位的各个部门逐渐的上了与本身业务相关的各种各样的系统（在这些系统中，以Web系统居多），几乎每个系统都需要识别操作者的身份，并根据其不同的身份，分配一定的权限，做一些操作上的限制。结果很多公司或者部门都在各个系统便各自设计了一套用户资料和权限管理的机制，并提供了用户登录证认。这样满足了上面的需求，但由此带来和用户账号管理不方便，用户资料不统一等等问题。在数字化网络化发展到一定阶段时，对用户资料的整合起来，进行统一的管理变得十分必要。
本文的目的在探讨一个简单有效的方案，将有一定联系，拥有统一用户群的系统进行关联，统一用户的登录资料，并提供统一的登录认证入口。统一认证系统与不同应用子系统之间建立一定的信任关系，通过一定的渠道交换认证信息，在保证用户信息安全的基础上，实现认证关系的共享机制。使用户一个地方一次登录之后，便可以在相应的应用系统群中遨游，而不用没到一个系统就进行登录，甚至使用不同的账号和密码进行登录。
网站与用户之间的认证关系，我们一般通过Session来建立，而Session（一般）在不同网站中是不能共享的。本方案的难点在于统一认证系统和应用子系统之间认证信息的共享。用户在统一认证系统中登录之后，与统一登录系统建立了认证关系，如果用户转向应用子系统，此时如何与子系统建立认证关系，如何将统一认证系统的认证关系迁移复制到子系统，这将是我们要解决的问题。
ASP.NET的Session保存机制（会话状态模式）有三种......

使用TFS进行项目团队协同开发的人应该都经历过，在一台新机子上面，新建工作区，下载项目程序文件，一编译，一大堆的错误，咋一看都傻眼了，但仔细看看才发现，原来都是项目的引用丢失了。最后便重新装组件，重新引用组件，完事。但此过程即耗时间，又造成文件的不一致，有可能部门引用组件锁定签出。如果团队的人员工作站和工作区都不固定，开发工作很难协调好。

出现上述错误的原因是TFS不允许签入dll的，所以当在本地引用了一个组件之后，编译时，组件dll文件自动被拷贝到项目的bin\Debug文件夹中，本地可以通过该组件，使用了新的命名空间、新的类，但在新的工作区没有下载到组件的dll文件，所以编译便产生了错误。
最终我们团队使用了一个办法，就是定时将解决方案中的每个项目的bin\Debug文件夹进行打包，并公布出来，新建工作区的成员如果需要，便可以下载覆盖，这样就避免了编译错误。
组件的引用的实际步骤是：在我们引用组件时，VS便将组件dll文件相关信息（包括了地址和版本）记录在项目文件中，当我们进行编译的时候，便将文件拷贝到bin\Debug文件夹，并更新版本。所以如果你引用的是同个解决方案的项目，那就不用理会，VS会自动更新dll文件的。

     摘要: 项目需要为用户提供一个登录账号初始化的功能，这就要求一个产生随机密码的类，这看似简单，但需要做一些限制，比如，密码的长度、复杂度，是否包含数字、大写字母、小写字母、符号等等。同事搜索了一下在网上直接dowm下了一个类。他整理出来代码如下：CodeCode highlighting produced by Actipro CodeHighlighter (freeware)http://www.Co... 阅读全文

项目团队正在使用TFS进行协同开发，由于人数较多，一开始为了保证开发工作正常进行，打开了代码分析，强制了签入策略，进行代码分析。当项目进行了一段时间后，每次编译都会产生一个错误“CA0503:无法显示额外的代码分析警告或错误”，虽然最后还是“生成成功”，但有个红色的错误，心里总不舒服，并且编译速度变得非常慢。
查找了很多资料才知道，原来是代码分析暂用了太多的时间，而该错误提示也是由于代码分析时，发现的的警告或者错误数量超过了一定的限额，而产生的。由于最后能顺利生成，所以不是项目本身没有错误，而是警告太多。如何解决这两个问题呢？

一种简单的办法是，在注册表以下路径修改警告的限制值。HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Setup\EDev\CodeAnalysisErrorListViolationLimit，其默认值为200，可以随便修改，只要该值大于你编译项目的警告值，则不会出现以上错误，但请不要无限的加大该值，因为伴随着加大的是代码分析的代价。由于大量的警告一般都无效，故控制该值将有助于提高解决方案编译生成的效率，节省你的时间。
另外，一种解决办法是，将每个项目的代码分析项尽量减少，由于大量的警告我们都不会理睬，反而淹没了我们应该重视的警告，所以我建议认真的对代码分析的每一大项小项都进行仔细挑选。这才真正提高了代码质量。
还有一种最好的办法，就是严严格格按照要求编写代码，将所有的警告全部解掉决，呵呵。

惩罚规定（不按照以下约束，而产生无法编译，或者文件独占签出，耽误别人工作）
在首页上统计错误次数，显示前三名
 
使用准备（在不同机子上，或者不同用户第一次使用）
1、在“文件”－“源代码管理”－“工作区”中建立自己的工作区
2、打开“源代码管理资源管理器”，选择自己的“工作区”，然后“获取最新版本”
3、在“源代码管理资源管理器”打开项目文件（SupplementaryPayAccountingSystem.sln），不可在此处打开个别程序文件，单独进行编辑
4、打开“解决方案资源管理器”
 
签出编辑（日常情况）
1、在“解决方案资源管理器”中，对整个解决方案（SupplementaryPayAccountingSystem），进行更新
2、生成整个方案，如果发现错误，则在群上将错误发布，发布信息包括，错误文件、详细情况和最后签入者
3、责任者（签入错误者）或者我迅速修改错误
4、重复1－3，直到没有错误
5、将自己需要编写的程序文件签出（一般采用独享签出，也可以使用共享签出，视情况定）
 
签入保存（日常情况）
1、生成整个解决方案
2、如果发现错误，则修改后重新生成整个解决方案
3、如果编写程序与其它程序冲突，则告诉系统分析组寻找解决办法
4、当生成整个解决方案，而不出现错误，则将自己修改的文件进行签入
5、如果在自己修改了其它一些程序，则需要将该程序进行“撤销挂起的更改”
 
取消更改（对程序做了一些修改，但感觉不妥，想恢复修改之前版本）
1、在整个解决方案上面右键“取消挂起的更改”
2、选择取消文件
搁置更改（中断使用，当在编辑过程中，程序还没写完，需要离开）
方法一（针对改动的较少）：
1、将改动代码注册
2、按照上面的签入保存进行。
方法二（针对改动较多）
1、在整个解决方案上面右键“搁置挂起的更改”
2、输入搁置集名称格式为：某某某（xxxx-xx-xx）xxxx搁置
3、去掉“在本地保留挂起的更改”
4、按照上面签入保存进行
 
取消搁置（中断使用恢复，将上一次编写一半的程序进行完善补充，前提是上次进行了搁置）
1、在整个解决方案上面右键“取消搁置挂起的更改”
2、选择搁置集，“取消搁置”
 
编写修改规范
1、进行较大编写或者修改后，必须在QQ群上通知，并在主页上发布相关通知
2、同时在修改的方法后面加上注释
格式为
<update>
<para name="xxx" time="xxxx-xx-xx">做了什么什么修改</para>
</update>
 
代码组规范
1、每个人只负责完成自己分配的任务（一个类，几个方法），只能编写个类和方法的实现，可以根据自己的理解和编写的思路修改其注释，但不允许进行重新定义，或者增加新的方法、属性或者类
2、如果需要增加重用方法，必须先告诉系统分析组（同时在代码组主页上面发布），以防造成混乱
3、可以根据自己对业务的理解调用其它类和方法，但不能直接修改其它类或者方法
4、如果被调用类或者方法有错误，或者不能满足要求，则可以通知系统分析组（同时在代码组主页上面发布）
5、进行重要修改，或者完成重要功能，请在代码组主页上面发布
 
表示层组规范
1、表示层需要属性业务层能够提供的服务，只调用Controller里面的方法，在用例中表现为与小人链接的方法
2、表现层需要了解数据库结构，并根据数据库格式在页面和后台进行双重数据合法性判断（如邮箱地址格式、日期格式、是否数字、字符长度等）
3、需要尽快完成新增相关页面，并尽快增加测试数据（也可以通过数据库直接加入）
4、催促代码组进展，提示需要尽快完成的工作（可以在代码组首页上发布）
 
分析层组规范
1、用例对应版本
2、用例更新需要通知

 1、程序编写程序，一般按照之前分析的结果，根据静态类图
1.1、每个人都负责单独的程序文件
1.2、需要修改其他文件时，最好联系该文件负责人
1.3、公用文件不要签出
1.4、公用函数、属性、字段一般不允许重新定义
1.5、可以增加私用函数、属性等
1.6、果对公用函数、属性重新定义，需要在组内进行讨论，并告知系统分析组
1.7、希望能够找出系统分析组不合理的设计，并提出有效修改意见
1.8、新建文件要先在组里商量一下，大家同意了，并清楚新增文件的用途才新建。

2、编码完成的时候，要将文件进行签入
2.1、当负责的功能没有完全搞定时，将文件签出，不允许他人修改
2.2、如果进行尝试编码，最终可以撤销挂起的更改，再签入
2.3、确定文件已经完成编写完成了，可以签入，成为公用文件
2.5、长时间的离开，脱离团队之前，必须将完成和未完成的情况告诉组长，文件必须签入，以便其他接手成员使用
2.6、注意平常时候都要签出文件，保护自己的成果
2.7、一般都使用共享签出，以便其他人查看，必要是才独占签出

3、每次签入文件时，必须签入可编译文件
3.1、对于未完成代码，可以进行注释屏蔽，下次恢复，再接着写
3.2、如果签入代码将影响到别人代码（相互调用），必须与别人商量好。
3.3、签入前，本地编译（查找原因，修改程序）
3.4、签入后，后下载最新文件，本地运行编译（找出失败原因，修改或联系其他人）

4、保证没有在服务器上都要可运行版本
4.1、但表示层完成了基本功能都，将进行每日构建
4.2、评选构建大师