博客园_乱世经典

Windows phone应用开发[16]-数据加密

2012-05-15T06:49:00Z

关于Windows Phone 中加密算法使用.最近一段时间很多做Windows Phone应用同学在微博上提了不少问题.其实在客户端实际需求中大多都会涉及到数据基于加密算法的解析和加密.本篇幅针对Windows Phone数据加密算法的问题.给出一些解决方案.

首先有必要来说说为何会存在Windows Phone数据加密的问题.做过Silverlight的同学应该知道.在Silverlight 4版本 .NET类库中基于System.Security.Cryptography命名空间下.保留了Aes加密算法.关于数据DES和TripleDES[3DES]加密算法已经不存在了.同样在Windows Phone SDK 7.1.1最新版本中.也能够看出除了SHA1和HMAC_SHA1对称算法外.如果我们尝试做MD5或对称的HMAC_MD5加密操作发现官方的SDK并没有提供类似支持的类. 如是问题就这么出现了.

如果需要在服务器端和和客户端传递类似MD5、HMAC_MD5或是解析服务器端传递的DES、TripleDES[3DES]数据是发现现在Windows Phone针对数据加密和解析并没有对应的支持.其实这些问题.原来都在我们团队实际Coding过程都碰到过.也算是找到一些比较成熟的解决方案.如下.

本篇幅针对MD5,HMAC_MD5,DES,TripleDES[3DES]算法给出Windows Phone移植版本.

首先来说说MD5.

MD5[Message Digest Algorithm MD5]用于确保信息传输完整一致，在计算机广泛使用的杂凑算法之一[又译摘要算法、哈希算法].比较常见使用于保证数据完整性.MD5或者说HASH值是一种不可逆的算法.在.NET 4中也提供类似在System.Security.Cryptography.MD5命名空间下MD5CryptoServiceProvider 类的对应实现.针对Silverlight和WP对应版本不支持MD5的情况,微软官方在archive.msdn上给出对应的MD5 Silverlight移植版本.[同样使用于Windows Phone]：

Silverlight MD5 Implementation:

[http://archive.msdn.microsoft.com/SilverlightMD5]

具体实现Code也可以参考GitHub上地址.这里不再赘述.

HMAC_MD5.

使用 MD5 哈希函数计算基于哈希值的消息验证代码 [HMAC].

HMACMD5 是从 MD5 哈希函数构造的一种键控哈希算法，被用作基于哈希的消息验证代码 [HMAC].此 HMAC 进程将密钥与消息数据混合，使用哈希函数对混合结果进行哈希计算，将所得哈希值与该密钥混合，然后再次应用哈希函数。输出的哈希值长度为 128 位.

关于HMAC_MD5算法除了在Codeplex 上[http://hmacmd5.codeplex.com/] 找到HMACmd5 Codeplex已经在Windows Phone验证通过外:

HMACMD5 For Silverlight/Windows Phone:

http://hmacmd5.codeplex.com/

其他第三方方式均没有验证过.考虑该算法核心并不复杂.于是自己动手重写一个基于Windows Phone 版本HMACMD5的实现[验证通过]. 核心类如下:

具体代码也可以从HMACMD5 For Windows Phone GitHub上可以查看.如上代码验证通过.

TripleDES[3DES]

Triple DES又称3DES，是DES加密算法的一种模式.[TDEA，Triple Data Encryption Algorithm]块密码的通称。它相当于是对每个数据块应用三次DES加密算法.现在计算机运算能力的增强，原版DES密码的密钥长度变得容易被暴力破解；3DES即是设计用来提供一种相对简单的方法，即通过增加DES的密钥长度来避免类似的攻击，而不是设计一种全新的块密码算法.

一开始我大概看了DES 算法在C下面的实现很简单.费了点时间很快就移植Windows Phone DES算法版本. DES算法的核心采用位运算的. 每次8个字节也就是64位内容.密钥key也为64位.然后经过16轮置换. 可惜 TripleDES[3DES]始终没有移植成功.重复造轮子无果后.果断寻求第三方解决方案.

在Silverlight和Windows Phone 在CodePlex值得推荐开源第三方库是SSH.NET Library

SSH.NET Library:

http://sshnet.codeplex.com/

SSH.NET Library库移植灵感是来源于Java版本.不过SSH。NET是完全基于.NET 没有采用任何第三方组件和引用. 其中实现也包含同步和异步的封装. Socket通信库. HTTP代等.其中最为重要的是基于.NET 实现DES和TripleDES[3DES] 两种核心算法. 并且支持.NET 3.5 、Silverlight、Windows Phone.

当然除了Codeplex上这个比较成熟SSH.NET Library开源组件外.关于DES和TripleDES[3DES] 还可以找到其他类似可选的开源组件.针对Windows Phone 缺乏3DES支持.国外一个WP 开发者Nicolas Humann[Link in] 基于broccoliproducts 的DES, TripleDES and BlowFish in Silverlight 版本库做了进一步的集成和封装. 并成功移植DES和TripleDES[3DES]Windows phone版本:

Nicolas Humann[Link in] DES And TripleDES[3DES] Component:

TripleDES Cryptography On Silverlight And Windows Phone

针对Nicolas Humann[Link in] 这个3DES版本移植ku.在其基础做了进一步的封装.为了是实现对TripleDESCryptoServiceProvider 类[3DES核心实现类]对数据加密和解密的操作. 大概分为两种情况.一种是需要IV密钥Key 另外一种不需要密钥Key 数据基于3DES和DES 加密和解密的封装. 核心Code如下:

1: using System; 2: using System.Net; 3: using System.Windows; 4: using System.Windows.Controls; 5: using System.Windows.Documents; 6: using System.Windows.Ink; 7: using System.Windows.Input; 8: using System.Windows.Media; 9: using System.Windows.Media.Animation; 10: using System.Windows.Shapes; 11: 12: using System.Text; 13: using System.Security.Cryptography; 14: using DataEncryptBuildDemo.DataEncryptCommon.DESDataEncrypt; 15: 16: namespace DataEncryptBuildDemo.DataEncryptCommon 17: { 18: /// <summary> 19: /// Des And TripleDES DataEncrypt Operator 20: /// Author:chenkai Date:14/5 2012 21: /// </summary> 22: public class Des_DataEncrypt 23: { 24: /// <summary> 25: /// TripleDes Data Encrypt With Ot Encrypt Key Operator 26: /// </summary> 27: /// <param name="sourceContent">Source Need to TripleDes Encrpt Data</param> 28: /// <returns>Encrypt Data Byte[] String</returns> 29: public static byte[] TripleDesEncryptWithOutKey(string sourceContent) 30: { 31: if (string.IsNullOrEmpty(sourceContent)) 32: return null; 33: 34: var toEncryptSourceStr = Encoding.UTF8.GetBytes(sourceContent); 35: TripleDESCryptoServiceProvider tripleDesEncryptProvider = new TripleDESCryptoServiceProvider(); 36: ICryptoTransform encryptTransform=tripleDesEncryptProvider.CreateEncryptor(); 37: byte[] encryptToBytes = encryptTransform.TransformFinalBlock(toEncryptSourceStr, 0, toEncryptSourceStr.Length); 38: 39: return encryptToBytes; 40: } 41: 42: /// <summary> 43: /// TripleDes Data DeEncrypt With Out Encrypt Key Operator 44: /// </summary> 45: /// <param name="encryptBytes">Encrypt Byte Array</param> 46: /// <returns>DeEncrypt SourceContent String</returns> 47: public static string TripleDesDeEncryptWithOutKey(byte[] encryptBytes) 48: { 49: if (encryptBytes == null || encryptBytes.Length <= 0) 50: return string.Empty; 51: 52: TripleDESCryptoServiceProvider tripleDesProvider = new TripleDESCryptoServiceProvider(); 53: ICryptoTransform deEncryptTransform = tripleDesProvider.CreateDecryptor(); 54: var deEncryptBytes = deEncryptTransform.TransformFinalBlock(encryptBytes, 0, encryptBytes.Length); 55: var deEncryptFormatStr = Encoding.UTF8.GetString(deEncryptBytes, 0, deEncryptBytes.Length); 56: 57: return deEncryptFormatStr; 58: } 59: 60: /// <summary> 61: /// TripleDes Data Encrypt Use IVKey Operator 62: /// </summary> 63: /// <param name="sourceContent">Source Content</param> 64: /// <param name="encryptKey">Encrypt Key</param> 65: /// <returns>Encrypt Bytes Array</returns> 66: public static byte[] TripleDesEncryptUseIvKey(string sourceContent, byte[] encryptIVKey) 67: { 68: if (string.IsNullOrEmpty(sourceContent) || encryptIVKey == null || encryptIVKey.Length <= 0) 69: return null; 70: 71: var toEncryptSourceStr = Encoding.UTF8.GetBytes(sourceContent); 72: TripleDESCryptoServiceProvider tripleDesProvider = new TripleDESCryptoServiceProvider(); 73: 74: //No Seting Pading 76: var key = tripleDesProvider.Key; //Save Key 77: IsolatedStorageCommon.IsolatedStorageSettingHelper.AddIsolateStorageObj("EncryptKey", key); 78: ICryptoTransform encryptTransform = tripleDesProvider.CreateEncryptor(key, encryptIVKey); 79: var encryptBytes = encryptTransform.TransformFinalBlock(toEncryptSourceStr, 0, toEncryptSourceStr.Length); 80: 81: return encryptBytes; 82: } 83: 84: 85: 86: /// <summary> 87: /// Triple Des DeEncrypt Operator Use IvKey 88: /// </summary> 89: /// <param name="encryptKey">Encrypt key can be null</param> 90: /// <param name="ivKey">Iv</param> 91: /// <param name="encryptBytes">EncryptBytes</param> 92: /// <returns>Return String </returns> 93: public static string TripleDesDeEncryptUseIvKey(byte[] encryptKey, byte[] ivKey, byte[] encryptBytes) 94: { 95: if (encryptBytes == null || encryptBytes.Length <= 0) 96: return string.Empty; 97: 98: TripleDESCryptoServiceProvider tripleDesProvider = new TripleDESCryptoServiceProvider(); 99: 100: if (encryptKey == null) 101: encryptKey = IsolatedStorageCommon.IsolatedStorageSettingHelper.GetIsolateStorageByObj("EncryptKey") as byte[]; 102: ICryptoTransform deEncryptTransform = tripleDesProvider.CreateDecryptor(encryptKey, ivKey); 103: var DecryptBytes = deEncryptTransform.TransformFinalBlock(encryptBytes, 0, encryptBytes.Length); 104: string unDecryptFomatStr = Encoding.UTF8.GetString(DecryptBytes, 0, DecryptBytes.Length); 105: 106: return unDecryptFomatStr; 107: } 108: } 109: }

当然这个只是Nicolas Humann[Link in] 对3DEs Windows Phone版本进一步封装. 目的方便能够形成一套API.无需关心TripleDESCryptoServiceProvider 类具体如何实现.至于这段代码可以GitHub上找到.验证通过.

至此关于应用开发常见的MD5、MAC_MD5、DES、3DES Windows Phone移植版本算法可用库如上.如上代码均实际项目中验证通过.对于还在苦苦重复造轮子同学.如果觉得为了使用效率.还是值得参考的.

关于本片全部源码可以GitHub下载到[ https://github.com/chenkai/DataEncryptWindowsPhoneDemo ].如有Bug请即时反馈 Email:chenkaiHome@live.cn

或通过Sina 微博：[http://weibo.com/chenkaihome] 即时沟通.

参考链接:

TripleDES Cryptography On Silverlight And Windows Phone

DES, TripleDES and BlowFish in Silverlight

本文链接

Windows phone应用开发[15]-辅助工具

2012-04-17T11:14:00Z

在Windows phone应用开发中很多场景中可以使用对外开源的小工具高效完成,而使我们在应用开发,提交审核,处理数据,UI设计资源上做到事半功倍的效果.本篇幅将主要来介绍Windows phone Development 中涉及使用开发小工具.

[1]Metro Studio

Windows Phone 基于Metro设计的UI风格.微软设计资源的考虑分配上.在Windows phone SDK 分别内置了32个ApplicationBar可以使用Icon图标.如果你安装了Windows phone SDK可以在如下目录下找到: C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.1\Icons\light

因Windows phone 有两Black、Light明暗背景.出现两种不同前景色的Icon图标.

这32个图标并不能完全满足所有APP实际需求.而由 syncfusion公司开发的一款Metro图标制作工具Metro Studio一款Metro图标制作工具，内置600多个Metro风格图标足以解决这个问题.MetroStudio按照不同的分类区别图标类型

通过设置修改图标大小[允许自定义],设置填充的像素.背景图形以及背景色.在短短几秒钟之内就可以完成一个标准ApplicationBar Icon图标制作.无需设计人员参与.Metro Studio 1除了图标编辑，还有XAML输出功能，假如你创建Windows Phone或者Windows 8应用程序的话，这种以XAML显示的模式将会非常方便。你还可以点击Save按钮来将获取一张png图片，所以当你打算以HTML/JS的形式来创建Windows 8应用的话，想想这将会有多省事:

Metro Studio安装需要注册码方式，注册Email有一个Product unlock key. 工具下载:

Development Tool Download:

Metro Studio Download Link:[http://www.syncfusion.com/downloads/metrostudio]

[2]IsoStroe Spy

原来做过Silverlight的同学应该都熟悉.如果我们临时数据交互常常存储沙箱中.也就是常说独立存储空间Isolated Storage.查看数据也才Spy工具.Windows phone 在早期Mango 7.0版本并没有内置SQLCE之前.独立存储也肩负存储应用数据重任.而官方只给出一个Windows phone Development Tool 部署工具.无法直接查看XAP中内容和具体数据文件.远远不能满足需求.模拟器Xap包资源文件查看和XAP管理

开源的IsoStroe Spy 就应运而生:

虽然能够通过手动修改Xap文件修改.zip解压.获取文件具体内容. SPy工具则可以直接查看XAP 包中各种图片、文本、语音文件:

最难得可贵的是.直接当前存储环境支持SQlCe数据库执行sQL语句执行查询获取结果:

类似这种XAP部署管理工具有很多.这也是随着Windows phone 开发者群体逐渐开始壮大.衍生很多实际需求.相信最早进入开发者一定不会忘记当初查看XAP第一款工具.WP7 Isolated Storage Explorer.简陋UI和极少查看文件别扭的功能相对今天的强大SPy版本真的无法比拟的:类似IsoStoreSpy还有XAP 管理部署查看工具还有很多、类似后来不断加入的Windows Phone Power Tools和Windows phone Xap Manager 但功能远没有Spy强大.

Windows phone Xap Manager:

IsoStore Spy Download Link：[http://isostorespy.codeplex.com/]

[3]Windows Phone Icons Maker

提交过应用的同学应该都知道.在对应的Windows phone APP中需要针对应用自身提供不同规格的图片.而且像素必须完全按照官方给出规格来制作.这在早期常常因为一些图片像素问题容易被官方打回.类似Windows phone APP图标在提交官方MarketPlace时就需要如下6中规格的图片:

96DPI,规格图片分别需要62*62、99*99,173*173,200*200.如果能够有一个图片自动生成工具批量生成WP提交应用所需要的图片.Windows phone Icons Maker则做了这个工作.:

点击saveIcon图标则自动在左面创建一个文件目录保存文件如见:

如此在无需设计师参与项目下.就能够通过工具快速自动生成对应所需图片.工具虽小但非常的实用.

Windows phone Image Tool:

Windows phone Icons Maker: [http://wpiconmaker.codeplex.com/]

[4]Windows Phone 7 Emulator Skin Switcher

在开发环境中.如果你已经厌倦微软默认给出模拟器外形皮肤.可以尝试切换成你想要的模拟器效果.Windows phone Emulator Skin Switcher 则是整合当前市面所有Windows phone真机设备的皮肤。用来随时切换:

换一份皮肤.Coding时也能换一份心情:

下载地址:

Windows phone SKin Switcher :

Skin Swithcer Download Link: [http://wp7emuskinswitcher.codeplex.com/]

本文链接

团队协作资源工具

2012-04-16T02:05:00Z

本篇幅主要用来记录收集到关于TeamWork 协作需要的资源和工具.去年在Windows phone Team中一直开始试用Scrum敏捷方法.但Scrum只是提供简单管理框架.在日常团队协作上还需要其他的资源和工具来填充一些空白.如下整理一些日常开发流程试用过一些协作工具.

类似在小团队中我们常常需要在Team中传递一些Task即需要即时ToDoList.常见的是很多人在口头传递.容易照成出错或是没有可见的Task优先级.在任务管理工具上试用过易度,Remine,ZenTao 感觉都不是达到我的需求:

协作需求:

数据存储在云端,或者可以自己架设，基于类似B/S架构

Task任务管理Tolist,可以设置优先级,并可以分配制定资源

任务可以排序,并对任务数据可以加以分析形成不同数据图.

知识库管理.类似简单Wiki功能即可了.

简单的协作工具，尤其强调 todo list 功能，那么选择有如下几个：

Asana - 地球上最复杂（笑）、也是最先进的基于 todo 条目的团队协作软件，是免费 web app，目前正在 beta 测试阶段 [http://beta.asana.com/]

Flow - 由著名设计团队 MetaLab 出品的 UI 华丽、功能实用的协作软件，收费，具有全功能的 iOS 客户端[http://www.getflow.com/]

Basecamp - 37signals 的明星产品，是以“项目”为导向的 web app，收费，除 todo list 外还有很多精致的功能[知乎团队在用]
[http://basecamphq.com/]
Producteev - 最近推出的一款拥有完善的 web 端和 Mac 桌面客户端的协作软件，个人使用免费，企业使用收费
[http://www.producteev.com/]
Kickoff - 为迷你型团队打造的全功能协作软件，被誉为“Basecamp 的 Mac 简化版”，很贵[知乎团队在试用]
[http://kickoffapp.com/]
Wunderlist - 一款轻巧的、拥有全平台客户端的 todo 软件，免费，支持协作
6wunderkinder.com/wunderli...
Team Box - 一款比较标准化管理流程的工具.应该算是最长使用工具之一,目前集成终端的有IPhone和IPAd的客户端.这款工具优势在于其流程非常标准没有其他工具的差异hua。容易建立比较清晰管理流程.不复杂却高速有效. 但相对其他管理它没有操作系统级别上同步客户端这是一个不好的地方.只能给予在线方式操作.
[https://teambox.com/]

同类的软件还有很多很多，我只列举了很小一部分，而且都是我使用过的。
抱歉的是，以上软件几乎都没有中文版，不过软件使用起来足够直觉化的话，是不需要完全中文也可以理解的。

本文链接

敏捷之道Scrum篇

2012-04-14T16:14:00Z

从去年我一直设想能够在公司的整个开发部门有机会在成型开发团队尝试中小范围的敏捷开发.这个想法其实也是由来已久.或者是说源自于自己在工作中深受传统瀑布开发模型一些弊端的切身感受.

作为一个软件工程师不断重复努力开发出高质量的软件.希望我们的用户能够使用到无Bug最佳的应用程序和良好的用户体验.而构建一个稳定可靠的软件是在软件开发流程中其实一件很困难的工作.而仅仅吧软件质量的责任归咎于程序员是不公平的. 软件开发流程是需要来自不同领域人或Team参与一个过程. 而软件质量在这个整个开发流程也是息息相关的.

那本篇我要说什么呢?

针对开发流程.业界早已衍生出一些相对成熟. 可控. 能够预估软件开发模型. 本篇你能够了解如下两个方面内容: A:如果你是一个开发人员.还停留传统瀑布开发模型中.想了解软件开发的敏捷方法? B:软件质量控制在传统瀑布开发模型与敏捷方法不同之处,有何优劣?

软件开发流程是一个很大的命题.所以本篇我不会对此进行泛泛而谈.我要说的所有内容都会围绕着，如何在传统瀑布开发和敏捷开发方法之间进行软件质量控制? 二者有何差异和不同? 两个问题展开.

传统方法瀑布开发模型

瀑布[Waterfall Model]开发方法.相信对于大多数开发人员来说都是很熟悉的.可能很多人和Team现在依然还停留在这个开发方法中进行日常开发工作. 瀑布方法是由Winston W.Royce 博士在1970年代发表的一篇论文中“管理大型软件系统开发[Managing the Development of Large Software System]”提出的.很多人都认为瀑布开发方法都是源之于这篇论文. 其实如果你仔细的阅读这篇论文.你会发现在最初的文章中，Royce提倡重复地使用瀑布模型，以一种迭代的方式. Royce实际在论文中试图拿这种Waterfall Model开发方法来论证说明这种开发模式是存在缺陷的.而且可能导致项目失败. 而Royce没有料到的是Waterfall Model却意外的成为业界大多数软件开发的最早标准.

瀑布模型[Waterfall Model]最早强调系统开发应有完整生命周期，且必须完整的经历周期中每一开发阶段，并系统化的考量分析与设计的技术、时间与资源之投入等，因此瀑布模型又可以称为‘系统发展生命周期’[System Development Life Cycle, SDLC]。由于该模式强调系统开发过程需有完整的规划、分析、设计、测试及文件等管理与控制，因此能有效的确保系统品质

Waterfall Model瀑布开发模型强调的是软件开发周期中每一个阶段都是线性的向下进行的:

至于这个流程相信很多开发人员已经是非常熟悉了.但在实际开发流程瀑布模型存在哪些问题、>?

首先第一点不得不说的就是在瀑布模型每个步骤都必须要按照顺序执行.直到整个软件开发周期完成. 最关键的是每个阶段在完成之前不能开始下一个阶段. 每一步的执行则是完全依赖于上一个阶段. 另外相信很多人会说在瀑布模型里说明问题是需要文档来记录的. 而且文档在这个过程每个阶段都需要详细文档来维系.

很多人会问如何在瀑布模型中保证软件质量?>

相信很多在实际项目中完整执行过该流程开发人员。应该清楚我们确定需求需要做持续做在文档做出软件概要设计和详细设计. 其实瀑布模型这样做要求在设计分析阶段尽可能多发现纰漏. 才能在开发阶段避免错误. 这有什么问题呢?

相信很多人发现.这种要求在设计分析阶段就能发现整个软件开发周期要发现所有可能出现的问题. 基本是不可能的. 而很多关键的细节如果不到具体的实现阶段是不可能发现的.

而由于这个模型.强制要求在编码开始之前要冻结规范文档. 也就是说很难在发布阶段将早起用户以及测试反馈的问题包含进来. 这样一来就降低开发团队响应客户需求的能力. 特别在发布周期要求比较高时.开发团队不能持续想客户交付有效功能点.

至于测试则是整个编码结束后拖到整个开发周期的最后. 这就是集成化测试的开始阶段.为交付有效功能点和软件质量照成一定风险.

敏捷方法之Scrum

其实对用瀑布模型这种臃肿不堪.要求严格.而无法适应软件开发周期变化开发模型.业界渐渐可是兴起向更轻型的软件开发方法演化。在90年代时提出好几种轻型方法.强调专注于软件自我管理的团队. 提倡面对面的交流. 轻型文档和迭代发布等概念.

最终这些方法论的缔造者. 其中包括Kent Beck、Martin Fowler,以及Ward Cunningham.组成敏捷联盟[Agile Alliance]。统一了敏捷软件开发的原则.从而就有了所谓后来的敏捷宣言[Agile Manifesto]

那什么是敏捷?

敏捷方法是试图通过小型的. 自我管理的团队用短小的合作发布周期来鼓励迭代式软件开发方法.软件的质量贯穿敏捷软件开发每一个阶段.且非常重要.,并提出很多关键的规则[例如: 结对编程. Test Driver Development测试驱动开发.,重构和持续集成]来保证能在每一个迭代周期内及早是的发现并及时相应消灭开发过程中出现错误.

有哪些敏捷方法?

在敏捷方法提出理念下.衍生出了很多不同敏捷软件开发方法.类似这里马上会提到的Scrum、极限编程[EXtreme Programning XP]，测试驱动开发[Test Driver Development]，重构和持续集成.

Scrum大概是目前敏捷方法里面最出名. 至少也是各位实行听说敏捷方法最熟悉一个.

那什么是Scrum?

其实冲本质上来说Scrum本身并不是所谓方法论.而是一组实践和为其过程参与者制定角色框架.其实它和其他敏捷方法是殊途同归.Scrum鼓励小型的,自我管理的团队在短的开发周期完成一系列定义良好的开发任务.

Scrum虽然提供了一个很有价值的框架. 但实际上和XP TDD不同的是它并没有定义明确可行的方法来管理开发出来的软件的质量.但其实这没有问题.Scrum的做法只是这个工作下放到Scrum团队每一个人.让开发团队自己决定选择实现什么样的质量控制实践.

在这一点上和XP TDD提出关注项目的框架.Scrum则淡化这一部分.而是更多对管理代码质量做出很多实践规定.

Scrum周期如何执行的?

每一个Scrum项目周期都被看做一个Sprint.它用来标识完成一组功能开发所需要的时间.Sprint即从Scrum团队打算把精力放在一组功能上开始.而这组功能是由Scrum团队在源自于Product Backlog的计划阶段期间选择的. Produc Backlog其实是指一张关于软件开发所有可能功能点优先级列表.

其中在计划阶段的末尾.所有从Product Backlog里选出来的功能都会被加入Sprint Backlog里执行跟踪.Sprint Backlog表示团队要开发的具体功能的细节.或者就是需求表现出来的功能点.一旦Sprint Backlog定义完成整个Sprint周期就开始.

通畅在一个Sprint周期会持续30天.在Sprint期间团队成员会聚在一起检查工作进展并帮助每一个队员保持工作效率.而在这个Sprint末尾。在Sprint Backlog里定义的功能点将全部完成并可用.

而这个过程就如上图.Scrum优缺点在那?

Scrum相对传统瀑布模型.在构建真个开发活动前.思考并记录下来真个流程.,按照具体的计划实施，保持各项事务尽可能的有组织性.另外可以从整个Sprint周期来看到.Scrum模型的一个显著特点就是响应变化，它能够尽快地响应变化.使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就迅速降低:

Scrum模型和传统模型的对比:

在这个过程中.,与XP（eXtreme Programming，极限编程）不同，Scrum并没有提供核心的价值观与指导原则，也缺乏具体的实践方法，例如结队编程、测试驱动开发。Scrum仅仅规定了实施的基本流程与检查表，它是一个开放的管理框架，重心在于项目管理，而不是指导团队成员如何进行开发。它很灵活，能够适应大多数场景，也可以兼容并包地引入其他方法学所提倡的实践.这既是Scrum的优点.

但在实际执行中也存在缺陷缺陷，使得它难以被实践。如果没有一位优秀的Scrum Master，而团队成员又缺乏自我组织和管理的能力，就会让开发过程变得混乱无法达到预期效果.

Scrum小结

Scrum的核心在于迭代。团队首先浏览开发需求，考虑可用技术，并对自身技术及能力做出评估。然后共同确定构建功能的方案，并每日调整方法，以应对新的复杂问题、困难和出乎意料的情况。团队找出并选择最佳方案去完成任务。此创造性过程便是Scrum生产力的核心[1]。Scrum的所有实践就是围绕着一个迭代和增量的过程开展的

关于Scrum 可以参考:

Succeeding with Agile:Software Development Using Scrum 中文名：《Scrum敏捷软件开发》作者：Mike Cohn
《Scrum敏捷软件开发》是敏捷联盟及Scrum联盟创始人之一、敏捷估算及计划的鼻祖Mike Cohn三大经典著作中影响最为深厚的扛鼎之作，也是全球敏捷社区中获得广泛肯定的企业敏捷转型权威参考

User Stories Applied:For Agile Software Development 中文名：《用户故事与敏捷方法》作者:Mike Cohn
《用户故事与敏捷方法》：敏捷大师Mike Cohn的软件需求方法圣经，小型团队(项目)不可或缺的敏捷开发宝典，亚马逊五星级长销图书，敏捷社区重点推荐，结合精髓和实例，充分演绎用户故事的智慧。

Ken Schwaber. Agile Project Management with Scrum[M]. 上海：世界图书出版公司，2007：

agile敏捷实践书中.<<Agile Estimating and Planning>> 的作者mike cohn3本著作最为经典. 其中04年这本<<User Stories Applied: For Agile Software Development>>算敏捷宣言最早一个版本. 09年<<Succeeding with Agile: Software Development Using Scrum>>则是深入敏捷实践推荐.
本文链接

Silverlight 可能迎来新版本

2012-04-07T04:55:00Z

一大早起来.在Windows phone Developer Blog就看到Silverlight 可能会迎来新版本的官方背景消息.我们知道.在2011年12月9日 Silverlight 官方团队不同如往常般低调的发布Silverlight 第5个正式版本[PS 详见:Silverlight 5 正式版发布了].发布这个版本时一直有很多行业资深人士预测在即将袭来的HTML 5大潮下. 原来与silverlight 竞争对手Flex被Adobe捐献给开源组织的命运逆转背景. Silverlight 5 也即将失去MS总体布局中于Flex对抗的战略地位.Silverlight 5 可能作为官方发布最后一个Silverlight 版本.

而当时Silverlight 5发布后. 官方并没有向以往发布Silverlight版本一样借此机会提供该平台未来几年可能进一步版本发展计划做出说明. 对于Silverlight 5之后下一个版本Silverlight 6一直存在一些传闻. 官方对此没有做出任何回应[否认或确认消息的可靠性].而与此官方提供各方面支持直到2021年. 支持的时间相对以前任何一版本都要长. 这些”异常举动“加上官方不表态做法无不让很多人相信Silverlight 5 即将是一个终结点.

Well. 直到今天早上在Windows phone Developer Blog 上Larry Lieberma的话似乎这种情形偶然发生一些变化 “Silverlight 将会引来新版本”.

消息出处:

Windows phone Developer Larry Lieberma Blog：

Windows 8 and the Windows Phone SDK, pt. 2

在这篇文章中Larry Lieberma Blog 首先提到一些Windows phone 平台存在一些问题[直译]:

“Windows phone现在应用程序和游戏即将会运行下一个Windows phone主要版本上.微软应该做出这样承诺，否则将会失去很多开发人员对该平台的支持.目前情形让.NEt 和Windows phone 感到很困惑一个地方. 在HTML 5 即将到来,尤其最近官方也会推出Windows 8 OS 到来的大背景下. 他们是否还会使用WPF和Silverlight技术?”

同时Larry Lieberma 也针对Windows 8平台中针对Windows phone SDK存在三个主要问题作了如下说明:

[1] Xna Game Studio: 在尝试Windows 8 平台上安装Windows phone SDK 时用户将会因为XNA组件无法兼容而收到报错信息. 将导致XNA开发组件无法安装Windows 8开发环境中.

[2]:Windows phone模拟器: 现在在Windows 8开发环境无法运行Windows phone模拟器.这使开发人员在该平台调试工作将难以进行

[3]NET 3.5 ：capability.exe和slsvcutil.exe将无法运行在Win 8平台，除非你单独安装NET 3.5 .

针对这些Windows phone 在Windows 8 平台存在问题.Larry Lieberma 在其blog中给出一些答案.其中就涉及到官方会发布下一个Silverlight消息,具体内容如下:

[1]针对Windows phone SDK 7.1.1. 应该能够使开发员能够做如下两件事: 第一能够在让开发人员能够在低端Windows phone 256MB 设备上开发应用适配的应用. 第二.能够在当前Windows 8 平台能够正常使用使用Windows Phone SDK 开发应用.

[2]Windows phone现在应用程序和游戏能够运行下一个Windows phone主要版本上.

[3]关于Silverlight For Windows phone 长远计划:请不要惊慌，在Windows 8上已经支持XAML， C#和VB.NET可以看做是Silverlight的一种进化。开发者所有的程序开发都将被转移到Windows 8上，换句话说，你所有的代码都能在Windows 8平台上很好的运行,微软承诺为开发者提供最好的应用程序兼容性，不管我们发布新的开发功能，我们都将最大限度的保证你目前的程序开发.

在第三条中说道Silverlight 长远计划上. 从Larry Lieberma 可以解读出两个结论. 第一Silverlight 在HTML 5发展的背景下.自身战略空间已经在不断被压缩. 第二在Windows phone 和Windows 8长远战略来讲.还是需要对Silverlight做出长远规划.这是否预示着Silverlight 会有下一个版本的可能? 而ZDNet上已经有人明确说官方将会迎来Silverlight 版本. 我觉得不够严谨.所以我在这篇文章标题上加了一个”可能“. 至于Silverlight 在第五个版本会如何. 只能让我们拭目以待吧…

最后给出Windows 8 Platform and Tool 一张图：

欢迎各位到Sina微博参与讨论[@chenkaiHome]

原文应用:

Windows 8 and the Windows Phone SDK, pt. 2

本文链接

Windows phone 应用开发[14]-调用WebBrowser

2012-04-04T09:42:00Z

很久没有更新博客了.最近一直陷身在项目中难以有时间抽身梳理总结.关于博客确实很多想写的主题.节前大概草草的梳理一下大概就有十几个主题.只能趁着放假的时间来逐渐把这批文章力所能及系统的更新出来. 主要涉及到我们团队现在Windows phone 项目开发中实际碰到一些问题和对应解决方案.如果想关注即时了解每天动态信息可以直接在Sina微博@chenkaiHome 沟通交流.

在开始更新这批博文前.一直在顾虑先更新那个主题为好.回头一想索性就说说这半个月有些苦恼的Windows phone中处理 WebBrowser在我们项目中表现出来问题.

话说去年.技术团队提出要优化产品在各个平台[IOS/Android/WP7/QT]客户端开发业务流程.提出这个问题主要是为了把原来通用业务逻辑流程封装到能力更大的服务器端来做.各个客户端在通过WebView统一的形式调用.这样做目的.主要是解决原来各个客户端在业务升级后更新客户端版本时减少重新开发量.这样一来把核心的业务逻辑变动全部集中服务器端.需求变化自上而下传递过程中.在各个平台之间可以复用. 在每次更迭客户端版本时提升开发团队效率.

最开始我们采用的方案焦点主要是考虑到WebView封装通用的业务逻辑流程涉及到与对应平台原生应用程序的交互问题上.所以也就理所当然有人提出跨平台移动框架PhoneGap[平台交互]+HTML 5[UI呈现]的处理方案. 原来我们设想真的很简单.也天真的认为PhoneGap+HTML 5搭配会把通用业务流程问题迎刃而解.

首先.PhoneGap[PS参考:Windows phone 应用开发[8]-体验PhoneGap]作为移动跨平台框架.着重解决的问题是通过JavaScript实现跨平台API交互.并没有UI.页面还需要借助HTML 5效果.即使如此.也是难以和原生应用程序界面相媲美的.这就需要在使用过程中.要牺牲掉大量原生应用程序交互细节.用户体验上打了一个折扣.当然这和我们解决的核心问题做出牺牲还是值得.但问题各个平台兼容性需要调整各个平台适配问题大大出乎我们预估.而在性能差异上更是难以兼顾保证的.而对于初次使用PhoneGap团队解决这些问题所耗费的开发周期时间.却远大于开发Native Application原生应用时间还要长.这完全和使用初衷相背离. 其实问题只是换了一种形式存在. 我们只是从一个熟悉能够预估量的泥潭跳到另外完全未知泥潭中.不断尝试挣扎…

谈到这.说一个细节.类似在WebBrowser浏览器控件中.打开一个新窗口的问题.Android平台可以采用LoadUrl方法直接打开一个新窗体实现Js控制的页面跳转. 而目前Windows phone WebBrowser情况不支持在当前页打开新窗体.虽然可以通过InvokeJavaScript()放在LoadComplated方法中注入Js控制方法替换打开方式来实现. 但在实际调试中会发现.开发人员在C# 后台代码中调试JavaScript来说是一个挑战. 一来WebBrowser在注入和执行Js过程返回的错误或异常都是简单的代码80开头Code.而没有具体的堆栈信息. 这对找错和确认问题照成很大障碍.另外在C#后台代码处理JS缺乏有效的调试工具支持.这对PhoneGap封装出来页面复杂的Js调用或数据交互操作.照成一定难题.

说白了.在PhoenGap中通过JS实现Windows phone应用平台交互主要体现在两个点上.第一就是通过在Js中调用：

【JAvaScript:】
window.external.Notify(“”);

方法把页面交互数据通过WebBrowser控件SCriptNotify事件接收传递给原生应用程序. 另外一个点.就是可以在在Windows phone应用程序直接调用WEbBrowser控件InvokeScript()方法来调用JavaScript函数. 这两个方法.实现了PhoneGap数据传递和交互整个过程.

那在Windows phone应用程序使用WebBrowser有哪些常见需要解决的问题?

[1]异常处理.

well.这里不得不首先说在WebBrowser调用JavaSCript时需要处理的异常问题.Windows Phone 提供一个基于桌面版本的 Silverlight 的 WebBrowser 控件，也就是说WindowsPhone 目前的WEbBrowser控件是基于Silverlight桌面版本的WebBrowser控件而来,但仍然有几处不同[WEbBrowser与Silverlight版本不同地方].其中两个版本在开发最大不同主要有如下几点:

Windows phone WebBrowser控件与Silverlight 桌面版本的不同:
[1]Windows phone 版本相对Silverlight版本具有直接使用 IsolateStroage独立存储的权限
[2]相对Silverlight在执行InvokeScript()方法时限制了执行范围必须是XAP 程序包相同的站点中加载的脚本.而Windows phone 解除该限制.
[3]在Windows phone版本时从独立存储加载的内容或使用 NavigateToString(String) 方法加载的内容没有跨站点访问限制。

那么在Windows phone WebBrowser中调用JavaScript常见的可能出现的异常主要有两个,如下重现这两个异常情况.首先创建一个Windows Phone Application 应用程序. Mainpage.CS：

1:  2: <Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0"> 3: <StackPanel> 4: <phone:WebBrowser x:Name="ComponentContent_WB" Height="450"/> 5: <Button x:Name="ExcuteScript_BT" Content="Excute JavaScript" Margin="0,50,0,0" Click="ExcuteScript_BT_Click"></Button> 6: </StackPanel> 7: </Grid>

定义一个WebBrowser和Button按钮用来在页面加载完成后执行JavaSCripti函数事件.当然在执行JavaSCript需要设置WEbbrowser可以调用JS的. 设置IsScriptEnabled="True" BehindCode 如下:

1: // Constructor 2: public MainPage() 3: { 4: InitializeComponent(); 5: this.Loaded += new RoutedEventHandler(MainPage_Loaded); 6: } 7: 8: void MainPage_Loaded(object sender, RoutedEventArgs e) 9: { 10: string navigateUrl = @"http://www.163.com"; 11: this.ComponentContent_WB.Navigate(new Uri(navigateUrl, UriKind.RelativeOrAbsolute)); 12: } 13: 14: private void ExcuteScript_BT_Click(object sender, RoutedEventArgs e) 15: { 16: //Button Client Event Excute InvokeJavaScript Method 17: try 18: { 19: this.ComponentContent_WB.InvokeScript("DefineNoExistJSMethod"); 20: } 21: catch (Exception se) 22: { 23: MessageBox.Show("Excute JavaScript Have Exception:" + se.Message); 24: } 25: }

调用通用网易站点.在加载页面完成后通过Button按钮执行一个不来就不存在JavaScript函数.执行效果如下"：

因这个JavaScript函数不存在所以执行肯定报错.注意这里报错信息是以80020006为开头的UnKnowError如下:

可见在堆栈的异常信息一栏中对JavaScripit提供的信息非常有限.这个Message代码为80020006.其实就是在当前应用程序执行范围找不到该JavaScript方法.另外一种情况恰恰相反.在执行已经定义JavaScript Function 函数出现的异常. 类似找到163.com站点中一个任意JAvaScript函数在后台方法调用:

1: function NTESAutoComplete ( inputElem, nextElem ) { 2: var t = this; 3: t._inputElem = inputElem; 4: t._nextElem = nextElem; 5: t._idName = "login_auto_list"; 6: t._className = "login-auto-list"; 7: }

注意InvokeScript方法在执行带有JAvaScript参数时. 参数传递是以String[]数组方式传递给JAvaScript函数.调用:

1: private void ExcuteScript_BT_Click(object sender, RoutedEventArgs e) 2: { 3: //Button Client Event Excute InvokeJavaScript Method 4: try 5: { 6: this.ComponentContent_WB.InvokeScript("NTESAutoComplete",new string[]{"NoExistElement", "NoExistStringArgument"}); 7: } 8: catch (Exception se) 9: { 10: MessageBox.Show("Excute JavaScript Have Exception:" + se.Message); 11: } 12: }

执行效果如下:

执行过程中InvokeScript得到异常 "An unknown error has occurred. Error: 80020101".而这个异常是在往往执行过程JavaScript内部错误引起.因在后台代码没有有效的工具.支持.所以对于JavaScript的错误是很难查找确认问题具体在那. 这个问题出现一般会有两种大概原因.

第一点.在调用InvokeScript()是WebBrowser控件事件执行顺序.其实针对WEbBrowser控件.除了从FrameworkElement类和Control类继承了通用了UIElement属性和方法外.WEbBrowser重点扩展自身导航操作.类似其中三个比较中重要的方法.Navigating、Navigated 和 LoadCompleted事件.

那么说到这这个三个事件在实际操作执行顺序是?

WebBrowser导航事件的执行顺序:
Navigating > Navigated > LoadCompleted

Navigating是执行Navigate方法表示当前WEbBrowser正在执行加载URL操作、Navigated事件WebBrowser 控件成功导航后发生和 LoadCompleted事件在 WebBrowser 控件成功加载内容后发生.

如果在这种情况下.即使我们发现我们Codebehind中InvokeScript()调用JS没有问题.同时HTML JavaScript函数测试也没有问题.这就导致我们始终无法通过程序测试找到JS 报错80020101异常在那. 这是在后台代码调试JAvaScript最让人痛苦的地方.比如我们在如下方法掉用如上JavaScript函数:

void Wb_Navigated(object sender, System.Windows.Navigation.NavigationEventArgs e) { Wb.InvokeScript("eval", "document.forms[0].submit();"); // Throws 80020101 } private void MainPage_MouseLeftButtonDown(object sender, MouseButtonEventArgs e) { Wb.InvokeScript("eval", "document.forms[0].submit();"); // Works }

可以发现.如果在Navigated事件触发时.即使我们后台代码调用和JavaScript函数都没有错误.依然还是爆出80020101的异常.这主要是因为DOM对象操作在页面触发Navigated事件还没有完全初始化.导致调用页面执行时出现异常.

第二点.则是比较常见的即使需要对JavaSCript做一定修改.确保JS函数在执行时不会出错. 则这个80020101异常一般都会在如上两种情况下出现.

[2]现实静态页面.

在WEbBrowser中.可能需要在没有网络情况下.需要在某一些情况下通过后台应用程序操作HTML页面. 而在Windows phone提供两种方式来加载本地静态的HTML页面.

在Windows phone 中WEbBrowser中提供NavigateToString方法将 HTML 字符串置于 Web 浏览器控件中以便进行呈现.操作也是简单的:

1: string defineHtmlStr = @"<html> 2: <head> 3: <script> 4: function DefineExistFun(elementStr) 5: { 6: var getElems=document.getElementByTag(elementStr); 7: alert(elementStr); 8: } 9: </script> 10: <body> 11: <a href=" + "http://chenkai.cnblogs.com" + ">Test</a>" 12: + "</body>" 13: + "</head></html>"; 14: this.ComponentContent_WB.NavigateToString(defineHtmlStr);

加载页面效果:

另外一种方式.则是加载一定定制好静态HTML页面.使用 WebBrowser 控件在应用程序中显示已设置格式的静态内容。例如，开发人员可能希望在应用程序包中包含帮助文本，以便用户可以随时访问.创建一个静态HTML界面:

1: <html> 2: <head> 3: <script> 4: function DefineExistFun(elementStr) 5: { 6: var getElems=document.getElementByTag(elementStr); 7: alert(elementStr); 8: } 9: </script> 10: <body> 11: <a href="http://chenkai.cnblogs.com">Test</a> 12: </body> 13: </head> 14: </html>

在执行第一步需要把该CreateProduct.html页面添加解决方案.设置引用资源为Content.需要向独立存储中添加存储静态文件.:

1: private void SaveFilesToIsoStore() 2: { 3: //These files must match what is included in the application package, 4: //or BinaryStream.Dispose below will throw an exception. 5: string[] files = { 6: "CreateProduct.html" 7: }; 8: 9: IsolatedStorageFile isoStore = IsolatedStorageFile.GetUserStoreForApplication(); 10: 11: if (false == isoStore.FileExists(files[0])) 12: { 13: foreach (string f in files) 14: { 15: StreamResourceInfo sr = Application.GetResourceStream(new Uri(f, UriKind.Relative)); 16: using (BinaryReader br = new BinaryReader(sr.Stream)) 17: { 18: byte[] data = br.ReadBytes((int)sr.Stream.Length); 19: SaveToIsoStore(f, data); 20: } 21: } 22: } 23: } 24: 25: private void SaveToIsoStore(string fileName, byte[] data) 26: { 27: string strBaseDir = string.Empty; 28: string delimStr = "/"; 29: char[] delimiter = delimStr.ToCharArray(); 30: string[] dirsPath = fileName.Split(delimiter); 31: 32: //Get the IsoStore. 33: IsolatedStorageFile isoStore = IsolatedStorageFile.GetUserStoreForApplication(); 34: 35: //Re-create the directory structure. 36: for (int i = 0; i < dirsPath.Length - 1; i++) 37: { 38: strBaseDir = System.IO.Path.Combine(strBaseDir, dirsPath[i]); 39: isoStore.CreateDirectory(strBaseDir); 40: } 41: 42: //Remove the existing file. 43: if (isoStore.FileExists(fileName)) 44: { 45: isoStore.DeleteFile(fileName); 46: } 47: 48: //Write the file. 49: using (BinaryWriter bw = new BinaryWriter(isoStore.CreateFile(fileName))) 50: { 51: bw.Write(data); 52: bw.Close(); 53: } 54: }

把需要展示的静态HTML页面在调用前需要存储到独立存储中.调用如下:

1: void MainPage_Loaded(object sender, RoutedEventArgs e) 2: { 3: SaveFilesToIsoStore(); 4: ComponentContent_WB.Navigate(new Uri("CreateProduct.html", UriKind.Relative)); 5: }

成功加载的页面:

针对在Windows phone WEbBrowser中于JavaScript交付问题的问题出现的异常.在后台代码上处理是非常弱的.首先在CodeBehind中没有成行JS调试工具支持.这对不熟悉前段JavaSCript代码的开发人员来说是一个挑战. 另外一个问题就是一旦调用JavaScript出现异常情况.很难确认问题源头.这也大大影响开发效率.

当然在WEbBroser还涉及到页面加载控制. 新窗口打开. 控制WEbBrowser页面缩放等问题.这里就不再一一赘述.

关于本片源码详见:https://github.com/chenkai/WebBrowser-Case-Windows-phone-Sample

源码下载:/Files/chenkai/WebBrowserWP7Demo.rar

如有问题可以Weibo上沟通交流:http://weibo.com/chenkaihome

本文链接

Windows phone 应用开发[13]-源码保护

2012-01-30T08:20:00Z

关于源代码的保护.Windows phone在2010年10月份发布第一个RTM版本时. 相信国内最早进入Windows phone开发者都应该知道.在2010年11月Windows phone刚刚发布一个多月时.国外的一个网址为winmobile7.apphab.com的网站不知用什么方法获得了微软官方MarketPlace应用的直接下载地址，当时直接导致很多WP7的游戏和应用的.XAP安装包被泄露出去.当然那个时候应用量才3000多个.这对于刚刚推出Windows phone平台不久即遭到开发者知识产权保护漏洞.那时开发者还不多.但也在一定程度照成开发者对于微软平台安全性遭到质疑和不信任.

Windows phone同样也是采用XAP安装包.而XAP其实可以通过强制修改文件格式转换成.rar.即可以通过解压工具获取XAP打包的DLL文件.通过逆向工程反编译工具.NET REflector是可以查看到源代码的.

当然官方团队意识到这个问题.很快完善修补该漏洞.并对于.XAP安装包中的文件可被直接破解反编译的问题.对开发者提出可以使用Dotfuscator这类的代码混淆工具来保护自己的源代码.即使XAP在第三方情况被恶意破解泄露.但也不会至源码会被直接暴漏出来.

针对这个问题微软官方很快就在2010年11月6日就宣布PreEmptive Solutions 合作推出 Runtime Intelligence for Windows Phone，这是一款面向 Windows Phone 7 的应用统计与分析工具.在2011年PreEmptive Solutions也相继推出专门针对Windows phone 应用程序源码混淆的免费工具PreEmptive Protection For Windows phone 7.

本篇将从Dotfuscator工具的角度来切入Windows phone应用的源码保护.

<1>源码保护现状

源码保护这个已经不是什么新鲜主题..NET CLR的出现.衍生出Native Code和Managed Code[一说托管代码].执行在 .Net CLR 环境下的应用程序都是属于 Managed Code 的范围，而 Managed Code 在编译时会先编译成 MSIL (Microsoft Intermediate Language)，实际执行时交由 JIT (Just-In-Time) 编译成机器码之后执行，而由于架构上的变更，MSIL (也就是我们的 .Net exe、dll 档案等) 是比较容易被反编译.[该段落引用自Wikipedia].NET代码被编译成IL代码，而不是ARM汇编.对于没有没进行源码混淆的应用程序Souce Code泄露的风险明显增大.

其实对于SouceCode保护.并不仅是Windows phone平台所面临的问题.

Android平台采用的是Java语言开发.Jave和.NET平台一样.在各自环境执行时.并不会将代码直接便异常机器码.而是编译成一种叫java字节码的中间语言.一般的java程序编译完成后是一个完整的Jar包.Android则使用DEX。你可以通过诸如dex2jar这样的工具将DEX文件转换成jar文件，然后使用诸如JD-GUI这样的工具反编译成Java代码。其风险和Windows Phone平台是类似的.

iPhone/iPad使用Objective-C语言，并且将代码直接编译成机器码。因此反编译会有较大的困难。然而，市场上依然存在一些专业反向工程工具，例如IDA.

目前主流平台对比可见.各个平台情况也是参差不齐.

<2>Dotfuscator构建源码混

PreEmptive Solutions在没有和MS合作之前,Dotfuscator代码混淆工具还需要额外的申请.官方需要一到两天的审核时间.现在只需要到PreEmptive Solutions官网上找到Windows phone对应的主页:

PreEmptive Solutions For Windows phone：

http://www.preemptive.com/windowsphone7.html

直接可以在当前页申请.:

现在申请流程已经大大简化了.基本在申请成功后可以收到官方发过来的一封说明邮件如下:

邮件中提供对应的软件下载地址.对应S/N注册码,该S/N码会在软件安装提示输入:

安装完成后可以看到切换并选择对应assemblies集合:

采用默认设置运行可见操作主页面:

这时创建一个用于测试Windows Phone Application 命名为:SouceCodeProtect_Demo.在MainPage页面添加一个简单的TextBox和Button按钮.在按钮事件处理TextBox用户输入处理方法如下:

1: private void Confirm_BT_Click(object sender, RoutedEventArgs e) 2: { 3: string userInputText = this.UserInput_TB.Text.Trim(); 4: if (string.IsNullOrEmpty(userInputText)) 5: { 6: MessageBox.Show("Please Input Basic Message Text!"); 7: this.UserInput_TB.Focus(); 8: } 9: else 10: MessageBox.Show("You have been Input " + userInputText); 11: }
运行效果如下:
这时有了一个简单功能的Windows phone 应用程序.当然此处的目的为了测试演示的目的.这时如果我们要把这个应用程序上线官方MarketPlace.一般情况需要发布一个Release版本的XAP安装包.找到对应SouceCodeProtect_Demo.xap 强制修改xap为rar格式并解压可以见到XAP打包的文件列表如下:
此时当前DLL并没有任何代码保护措施. 如果当前发布的应用程序的XAP安装意外流出.或是遭到第三方强制破解.如果通过逆向工程反编译工具.NET REflector查看对应SourceCodeProtect_Demo.DLL可以看到:
我们的核心代码就会向密码中明文一样在没有任何保护措施的情况下被暴露出来.这时该如何保护自主知识产权的源代码呢.?
积极采用云平台.把重要逻辑放到云端:
如果Windows phone在做客户端工作.你也可以考虑将部分重要的逻辑放到云端，例如Windows Azure之上，尤其是那些需要很多计算资源的逻辑，例如电影编码。手机是一个客户端，性能和存储空间都有限，有部分功能不适用于在手机上进行。事实上，Windows Phone自带的一部分功能，例如朗读文本，就需要通过微软的云服务才能完成。将逻辑放在云端还有一个好处就是，各种各样的客户端都能够通过访问服务的方式使用该功能，而不需要针对每个客户端写专门的代码。像部署在Windows Azure这样的云平台上的服务，客户端无法直接取得程序，只能通过服务暴露出的接口间接地访问云端的程序逻辑，因此也不存在反编译问题。当然，这样做也有坏处，例如可能需要用户支付网络流量相关费用，而且有时候网络传输可能有点慢.
使用高级编程语言特性:
C#这样的语言有一些高级语言功能，例如lambda expression和yield return。使用这样的功能不仅使得写代码变得方便，同时也会增加逆向工程反编译的难度。因为很多使用高级语言功能撰写的代码会在编译时由编译器自动转化成一些比较繁琐，读起来比较累的代码。大多数逆向工程反编译工具只能产生这些由编译器生成的代码，而看不到你的原始代码。
使用源代码混淆工具:
当然从成本和开发者可控的角度而言.通常的做法就是版本发布后考虑将源代码进行混淆。这会使得反向工程后的源代码很难被读懂。在.NET平台上，可以使用诸如Dotfuscator这样的工具.
如何使用Dotfuscator工具执行源代码混淆操作?
...
本文链接

Windows phone 应用开发[12]-Pex 构建自动化白盒测试[下]

2012-01-29T08:42:00Z

本篇承接于上篇Windows phone 应用开发[11]-Pex 构建自动化白盒测试[上] .大概了解Pex作为自动化白盒测试工具工作方式.以及提出参数化单元测试的概念.为开发人员减少手动编写大量独立路径下单元测试时间.Pex允许开发人员编写单独的参数化测试方法，并根据测试方法的逻辑分支自动生成测试数据及Assert语句。虽然开发人员还是需要手动编写单元测试，但是Pex可以确保对代码进行了充分的测试.并能通过Pex自动修复Bug.添加测试项目.其中的Moles组件可用于模拟框架中包括静态成员在内的几乎所有成员，大幅提高了对测试的支持程度.

本篇来探索一些Pex 在Windows phone Application应用程序中使用.

首先在Visual Studio 2010中构建一个Windows phone 应用程序BasicWinPhoneComponent_Demo.并实现一个简单分类列表显示.Well.定义一个标准的ViewModel执行数据绑定. Viewmodel代码如下:

1: public class MainPage_ViewModel:BasicViewModel 2: { 3: ObservableCollection<CatalogInfo> catalogInfoCol = new ObservableCollection<CatalogInfo>(); 4: public ObservableCollection<CatalogInfo> CatalogInfoCol 5: { 6: get { return this.catalogInfoCol; } 7: set 8: { 9: this.catalogInfoCol = value; 10: base.NotifyPropertyChangedEventHandler("CatalogInfoCol"); 11: } 12: } 13: 14: public void LoadCatalogInfoDemoData() 15: { 16: this.catalogInfoCol.Clear(); 17: this.catalogInfoCol.Add(new CatalogInfo() { CatalogTitle="Music & Video",CatalogContent="Base Catalog Title" }); 18: this.catalogInfoCol.Add(new CatalogInfo() { CatalogTitle = "Book & Libray",CatalogContent="Basic Book" }); 19: } 20: }

在MainPage Code-Behind执行数据绑定代码如下:

1: private MainPage_ViewModel mainPage_ViewModel = null; 2: void MainPage_Loaded(object sender, RoutedEventArgs e) 3: { 4: if (this.mainPage_ViewModel == null) 5: this.mainPage_ViewModel = new MainPage_ViewModel(); 6: this.mainPage_ViewModel.LoadCatalogInfoDemoData(); 7: this.DataContext = mainPage_ViewModel; 8: }

运行效果:

一个基础功能实现完成后.现在要对ViewModel中代码做基本的UT.安装完PEX之后直接右键点击可以看到如下操作选项Run Pex 和PEX:

首先Run Pex即时生成测试用例如果是安装后.首次运行Run Pex 在Windows phone Application中.会提示:

该窗体提示选择当前构建UT所基于的测试框架.PEX的扩展允许下载并支持Nunit MBUnit、或Xunit.Net测试框架.当前根据官方说明PEX会自动检测当前应用程序类型.根据不同应用会在测试框架选择项中给出指定测试框架.当然针对Silverlight、Windows phone应用标准的还是Silverlight Unit Test FrameWork[SUTF]框架. 如果没有安装Silverlight Toolkit或是修改了默认的安装目录.这里还需要手动指定当前框架安装路径.在前几篇中提到SUTF windows phone版本测试框架需要两个核心的DLL:

1: //Silverlight Unit Test FrameWork For Windows phone Version DLL 2: Microsoft.Silverlight.Testing.dll 3: Microsoft.VisualStudio.QualityTools.UnitTesting.Silverlight.dll

可以把该DLL文件拷贝到一个独立的目录下并初始化路径:.

点击Ok 出现问题提示无法Assembly Microsoft.VisualStudio.QualityTools.UnitTesting.Silverlight.dll 这个DLL. 在目录中删除掉该DLL.点击OK.

PEX 目前需要单独解析DLL.需要重新指定Microsoft.VisualStudio.QualityTools.UnitTesting.Silverlight.dll文件映射.PEX自动解析成功后 Run PEX在创建测试用例过程中出现异常:.

谈到这个问题.这里有必要解释一下Run Pex和Pex->Create Parameterized Unit Test 两种运行Pex方式之间的区别.如果独立运行Run Pex 选项操作时我们能发现它没有像Pex->Create Parameterized Unit Test 选项一样，需要独立创建一个单元测试项目.实现测试代码与宿主源代码之间的分离. 但当你执行Run Pex时你可以在Visual Studio 左下角状态栏下.可以看到Run Pex时其实把创建这个单元测试项目交给Pex内部来做.这一方面能够为测试用例构建驱动环境. 同时能够实现在无需开发人员维护测试用例代码情况下即时run Pex方式运行代码块的UT. 查找Bug并通过Pex自动修复.

那二者区别在哪呢?

其实这个问题上篇Windows phone 应用开发[11]-Pex 构建自动化白盒测试[上] 中Pex构建参数化单元测试中提到.只是没有联系到run Pex. Pex->Create Parameterized Unit Test 目的其实通过创建一个手写的参数化单元测试，Pex完全自动地分析代码，来决定相关的测试输入。其结果就是生成一个有着高度代码覆盖的传统单元测试.而Run Pex运行的Ut效果是即时.开发人员在无需维护测试代码前提下就能看到当前代码块Ut测试结果. 其实二者内部的原理并无差异. Run Pex其实在内部创建一个代码不可见的参数化单元测试项目在此基础之上构建测试用例.多次执行而获得即时测试结果.而Pex->Create Parameterized Unit Test 则可见的把当前测试代码放到当前解决方案中.

那现在遇到什么问题?

Event：

"could not create an instance of BasicWinPhoneComponent_Demo.ViewModels.MainPage_ViewModel"

Message：

Click on 'Edit Factory', or, as a workaround, create a parameterized test that constructs the value from simpler values.

可以看到在构建单元测试用例时.无法创建MainPage_ViewModel实例.导致整个Run Pex在构建测试用例驱动环境时中断执行. 是否觉得上面步骤还不够具体详细. 因为我们始终在执行Run Pex时.不知道Pex内部是如何工作的? well.这时选中”Cound not Create an Instance …”测试Event事件:

可以看到在右栏Detail 下有一个Ignore操作.目的忽视当前错误继续在Pex创建ViewModels实例.:

点开折叠的节点.可以清晰看到内部Pex在执行Run Pex时内部执行整个流程步骤.可以看到Run PEx 时PEx 内部执行流程如下:

Pex 执行流程:

Create Pex Project –> Create Test Project –> Create Visual Studio Unit TEst Silverlight Project …

首先创建一个Pex Project. 在Pex Project基础上创建一个普通的测试项目Test Project.其中这14操作中1-6步是用来创建测试项目.7-10是为当前测试项目添加构建测试用例驱动环境所需的引用.11-13步为当前测试项目添加指定的测试文件,. 带黄色长方块即是要忽视的操作"，执行:

需要基于一个独立的测试项目来承载测试用例.创建:

当执行Ignore操作第四步Create ViualStudio Unit Test Silverlight Project时.出错. 具体信息如下:

Update result:
failed to generate project CSharp\Silverlight\Silverlight Unit Test Project.zip, Could not find template for new project

可以看到在创建普通单元测试项目时找不到对应Silverlight unit Test Framework Windows phone模板.well.这是查看Pex And Moles官方Realse Note记录,针对这个模板支持的问题可以找到如下说明:

v0.92.50603.1, 06/07/2010

Highlights

Rex integrates Pex. Rex is a tool that explores regular expression. It's algorithms have been integrated into the whitebox exploration engine of Pex. As a result, Pex is much smarter about generating strings that match a Regex.IsMatch call.

Preparable Types. It is possible to register a lazy setup method for a type. This method has to be static and will be invoked by Pex before any method of the given type is executed. This is a great way to mole parts of your system on demand.

Silverlight and Silverlight for Windows Phone support (Alpha). Right-click on any Silverlight project and hit 'Run Pex'. Pex will run your Silverlight code on the desktop CLR and start generating tests for it. The unit tests can be executed using the Silverlight unit test framework fromhttp://silverlight.codeplex.com.

可以看到在2010/7/6日版本更新的Realse Note中.提到这个版本已经支持Silverlight中运行Pex实现白盒自动化测试.Pex针对silverlight中.cs文件，默认使用VisualStudioUnitTestSilverlight框架。[assembly: PexAssemblySettings(TestFramework = "VisualStudioUnitTestSilverlight")].很多在Silverlight 中做过Ut的同学应该知道.PEX会针对Silverlight应用程序会也会创建一个对应桌面版的Silverlight Project.而针对Silverlight Unit TEst FrameWork测试结果也会自动显示Windows PC端的IE浏览器中:

那针对 Windows Phone Application应用程序呢? 针对这个问题质询官方Pex And Moles团队对Windows phone支持的建议.得到回复如下:

"hi Peli:

I am working on testing WP7 application.

I found a very excellent tool "Silverlight Unit Test Framework" to do unit test.

But, I want to do some automated tests for each function by inputting random data (like stress test).

There is a tool called "Pex" (http://research.microsoft.com/en-us/projects/pex/ ) that can do that things for me, but it seems not support WP7 right now.

So, is there exist a tool like "Pex" can do stress test on WP7?

Peli Reply:

Hi kaichen,

I am a developer from the Pex project. Unfortunately, Pex does not support Silverlight or Silverlight for Phone currently. We have no immediate plans to support this runtime in the short term.

You can post other questions on Pex at: http://social.msdn.microsoft.com/Forums/en-US/pex/threads/.

Cheers, Peli

"

well. you see! Pex目前并不支持Windows phone 应用程序自动化白盒测试.

So.通过以上出现的问题.知道.Pex出现问题的地方在于.在Windows phone Application 中Run Pex时 Pex中并没有一个支持Windows Phone的framework作为extension 内置模板.导致创建测试应用程序失败.如果能够Run Pex能够在Silverlight和Windows phone 应用程序之间随意选择切换.就更好了.

在Windows phone 应用开发[9]-单元测试中我提到采用默认的Visual Studio Test框架可以在建立测试用例完成后指定测试用例输出的应用程序. 这是否能够提供一种解决Pex在Windows phone 中实现的思路呢,这点正如园友sinodragon21在Windows phone应用开发[9]-单元测试评论中提出想法一致:

如果我们采用Pex自动化白盒测试工具.可以看到其实Pex的工作相对通过Windows phone Test Project模板创建单元测试项目. Pex的目的主要在于通过参数化单元测试构建测试用例.而目前的问题在于.在构建这些测试用例驱动环境时无法创建对应Windows phone 测试项目. so. 如果二者能够完美的结合.可以通过PEx自动探索分析代码逻辑流，自动产生测试数据和单元测试用例。这时我们需要需要为Pex写一个支持Windows Phone的framework作为extension（假定它叫做VisualStudioUnitTestWindowsPhoneSilverlight），在"Run Pex"时可以选择该framework，最后生成XXX.Tests是Windows Phone工程，而不是PC版的silverlight工程.使其Pex通过SUTF测试结果能够在Windows phone模拟器中输出.

这时首先在Solution中添加一个Windows phone Test project 测试项目命名为BuildCompontentDemo.Tests.该模板可以通过在Online Template中搜索Windows phone Test找到:

创建完成手动添加Silverlight unit Test Framework框架两个核心DLL的引用:

well.这时找到源程序BasicWinPhoneCompontent_Demo.中ViewModel 通过Pex->Create Parameterized Unit Test 选项对应参数化测试用例.输出把该用例代码指定输出到对应的刚刚创建的Windows phone TEst Project 上BuildCompontentDemo.Tests中来:

在Add New Test Project中可以看到Pex只能创建自己内置模板内对应Windows phone Test Project .而无法想普通测试的方式在建立测试用例后可以指定测试用例代码输出项目类似:

Pex并没有暴露类似Visual Studio默认带有测试框架可以指定测试用例输出项目的的操作. so. 针对这个思路目前基于现有的Windows phone测试模板还是一条Dead Way.问题还是在于Pex自身.

well.至此问题已经非常明朗.如果要在Windows phone 采用PEX自动化白盒工具构建单元测试.问题还是集中Pex自身.从开发者角度来说基本是无法行通的.至少从目前尝试的角度没有行通.当然也欢迎其他的园友有好的思路和想法均可以评论中提出.共同探讨实践.但是作为开发者单一从使用工具的角度来说.这些工作并不适合寻求所谓的”突破”。因为官方在构建PEx版本时就没有打算支持Windows Phone的运行时.而目前的问题多集中于Pex自身.所以这些工作应该官方官方团队来做. 如果执意使用该工具.在我看来Pex所有带来的自动化的简便.远大于解决当前问题付出代价要高,这样的性价比远比另寻其他工具要来的简便实在.

即使解决该问题.也难免在团队协作推广和使用过程遇到问题.光有流程和意识,而在实践中缺乏必要可控方法是很难推广和落地一项新技术的.当然这里更没有探讨所谓的成本,所以关于PEX在Windows phone自动化白盒测试推荐各位以尝试探索的精神去解决.并不推荐在实际项目推广应用.前提是解决该问题,但PEX在自动化白盒测试中设计理念还是值得深入理解的。

如上真实记录Pex在Windows phone探索过程.

当然官方也给出一些关于PEX很有意思一个应用Pex4Fun:

Pex4Fun在线地址:

Pex4Fun Online Demo :http://pex4fun.com/

Pex4Fun这个应用是微软研究院.推出一款Web通过C# /VB/F#语言在线编程.其实你也应该能看出来这里用到Pex那一部分.Pex为何能够自动化建立白盒的UT.最终一点就是PEX能够完全自动地分析代码行为，来决定相关的测试输入.有了PEX作支撑这就不难理解这个在线编译工具强大了吧.当然针对Pex4Fun也推出对应Windows phone 应用:

Pex4Fun For Windows phone：

Pex4Fun :http://www.windowsphone.com/en-US/apps/db980958-7c4a-e011-854c-00237de2db9e

同类型的应用目前在Windows phone平台很少见.原来我在查看应用MSDN Library Reader就考虑到.如果能够在手机应用C#多种语言实现随时随意写Code.同时随时随顶在手机编译运行.该多么Cool.果不其然.Pex4Fun就做了这样的工作.它类似2012年初微软推出Visual Studio开发人员成就系统.可以在线写代码赚取积分进入排行榜.另外不得不说的是.里面还有各种各样的考题和考题对应的需求说明文档.这对开发人员来说真的很不错的一个应用.

Pex4Fun是目前唯一Pex在Windows phone以功能形式出现的应用.但我一直很疑惑该应用在使用Pex功能是如何实现的.? 如果是纯客户端意义.倒觉得意义不大.但该项目非开源.so并不知内部其实现过程.

关于Pex在Windows phone构建白盒自动化测试整个过程如上.如有疑问请在评论提出.

本篇演示的源代码下载地址:/Files/chenkai/BasicWinPhoneComponent_Demo.rar

本文链接

Windows phone 应用开发[11]-Pex 构建自动化白盒测试[上]

2012-01-19T10:59:00Z

昨天一位园友sinodragon21在Windows phone应用开发[9]-单元测试评论中.提出关于Windows phone 单元测试中能否使用微软的Pex自动化生成工具生成单元测试用例.和单元测试质量即代码覆盖率统计问题.很有价值.

针对这两个问题.首先需要解释.关于Windows phone 中单元测试现状.针对Windows phone应用程序Unit Test 官方并没有在IDE提供对应的测试框架,目前开发者社区使用比较广泛框架是MS Windows phone 产品组Jeff.wilcox维护的Silverlight Unit Test Framework[SUTF] Windows phone版本.详见Blog:Updated Silverlight Unit Test Framework bits for Windows Phone and Silverlight 3 . 但这个版本始终作为个人形式对开发者发布.并没有以正式的官方渠道向Windows phone开发者推送，所以官方对此并没有提供指定的维护和开发者社区支持.

至此官方也就没有提供自动化测试工具道理. 类似Android 平台自动化Monkeyrunner之外还有更多选择.而Windows phone自动化测试只能靠开发者自己想办法.

那么关于SUTF 中Code Converage代码覆盖率呢? 针对这个问题特别咨询SUTF WP版本维护作者Jeff.Wilcox.得到回复信息如下:

HI Jeff,
how to take code coverage from SilverLight Unit test framework for WP7?

jeffwilcox Reply:

Code coverage is not available, it was a feature that was cut before
shipping for 2010 from the toolkit.

在2010年发布SUTF版本时已经去掉对Code Converage支持. so.既然如此是否真的就此定论了.? Now 现在提到Pex and Moles.还是不甘心.打算动手在应用程序中亲自验证.本篇并不打算立即采用Pex在SUTF进行验证.有必要系统了解Pex and Moles.

<1>构建Pex测试环境

Well.关于Pex And Moles其实可以分为两个部分.其一Pex-全称是[Program EXploration]是微软研究院的一个关于白盒测试自动生成工具.原来开发人员只能通过指定路径编写独立的测试用例.PEX通过分析代码来自动生成测试用例。对于程序里面的每一行代码，PEX都会尽可能地生成合适的输入值来达到提高覆盖率的目标。同时PEX还会分析代码中的分支，生成覆盖更多分支的测试代码（输入数据）；PEX在执行代码的同时会监控和分析代码的控制流和数据流，了解程序的行为。每运行完单一个测试以后，PEX会选择一条在前面的测试中没有覆盖到的路径，并且尝试执行它.本篇主要来讲到的是PEX.

PEX自动化生成用例并执行UT返回测试结果的过程.大大减少开发人员手动编写大量测试用例情况发生.

关于PEX and Moles可通过如下链接了解更多:

PEX And Moles：

Pex and Moles - Isolation and White box Unit Testing for .NET

Download Page:
Pex and Moles – Download Page Link

Get Start Online PDF Document:

http://research.microsoft.com/en-us/projects/pex/digger.pdf

找到下载页面.PEX现在有3个Flavor，支持2个版本的Visual Studio，分别是VSTS2010和VSTS2008，这3个版本的PEX在功能上存在区别，这主要因为下载受众群体不同,一般用户只能使用到PEX功能.本篇所有演示都是基于Visual Studio 2010. 基于MSDN订阅权限下载PEX And Moles完整版本.

安装完成后.可以打开Visua Studio 立即创建一个Console Application命名为BasicConsolePexComponent_Demo,在此先不要把焦点放在PEX原理实现上.来快速体验一下PEX.首先需要在Program类中顶一个转换字符串的方式.作为测试用例的宿主程序.创建如下:

1: /// <summary> 2: /// Test Case Convert String To Upper 3: /// </summary> 4: /// <param name="inputString">Input String</param> 5: /// <returns>Converted String</returns> 6: public string ConvertStringToUpper(string inputString) 7: { 8: string convertString = string.Empty; 9: if (!string.IsNullOrEmpty(inputString)) 10: { 11: char[] convertCharArray = inputString.ToCharArray(); 12: if (convertCharArray.Length > 0) 13: { 14: int count = 0; 15: foreach (char currentChar in convertCharArray) 16: { 17: if (count % 2 == 0) 18: convertString += currentChar; 19: } 20: } 21: } 22: return convertString; 23: }
well一般情况下.关于如何建立单元测试应用程序,一般如果没有PEX之前.可能作为开发人员更多的是根据该方法实现.创建一个新的Test测试项目.构建对应测试用例.实现对该方法的UT.其实这个过程已经Visual Studio内置了这些工作已经自动创建.只需右键点击就能看到Create Unit Test选项:
点击后能发现.其实Create Unit TEst为了避免测试框架和测试用例污染源代码本身.一般情况要对单元测试用例和源代码执行分离.也就是创建一个新的单独测试项目.
此时在执行测试之前需要做一些设置点击Settings按钮:
需要设置创建默认文件以及对应测试类和测试方法名称.点击ok.如果没有设置对应测试项目名称会如下提示:
修改完成后开始创建.创建过程可能会有如下提示:
创建前提示主要提到两点.需要为测试项目BasiceConsolePexComponent_Demo设置InternalsVisible属性可用.这是设置其实内在的原因是.对一个组件或模块进行单元测试时.单元测试用例需要调用定义在测试组件或模块中的Internal成员对象时. 需要跨程序集访问.而Modifier的Internal类型成员默认设置仅限于当前程序集访问.而对宿主程序而言需要暴露给测试程序集调用.
另外一点在很多情况下，我们需要将最终的程序集以强命名的形式发布。为此，我们修改Lib项目设置，开启"Sign the assembly”开关，并创建一个密钥文件.不能通过编译，具体的错误信息为：“Friend assembly reference 'Test' is invalid. Strong-name signed assemblies must specify a public key in their InternalsVisibleTo declarations.”,针对需要指定的不是程序名的强命名，而是指定对程序集进行签名时采用的公钥.把公钥指定到InternalsVisibleToAttribute特性中即可.
点击ok.看一下项目结构:
多了一个测试项目和该项对应Program方法测试类.now构建好了测试项目.在回到宿主程序Program类中对字符串转换操作的方法见一个UT.找到该方法名右键依然可见Create Unit Test选项点击看到:
可以看到针对方法做UT时会把该UT的应用程序的输出默认为刚才创建的测试项目:AutomationConsole.Test.点击ok.找到测试项目下ProgramProgramTestHelper类可以看到增加一个测试方法如下：
1: /// <summary> 2: ///A test for ConvertStringToUpper 3: ///</summary> 4: [TestMethod()] 5: public void ConvertStringToUpperTestConvertString_Test1() 6: { 7: Program target = new Program(); // TODO: Initialize to an appropriate value 8: string inputString = string.Empty; // TODO: Initialize to an appropriate value 9: string expected = string.Empty; // TODO: Initialize to an appropriate value 10: string actual; 11: actual = target.ConvertStringToUpper(inputString); 12: Assert.AreEqual(expected, actual); 13: Assert.Inconclusive("Verify the correctness of this test method."); 14: }
可以看到该测试方法命名依然采用默认命名方式.方法内代码实现关于调用Program类中字符串转换大写操作的方法ConvertStringToUpper. 分别定义三个变量的字.其实从变量名称完全可以看出这是一个默认的测试用例.要想改UT达到想做.只需修改对应变量参数的值来匹配.InputString作为方法参数输入.经过测试用例会会生成对应期望值和方法执行实际值.最后通过对期望值和实际比对获得对应测试结果.直接运行可以看到测试结果如下:
well因为两个测试用例都没做了修改没有实际值传入所以都是Inconcluetive测试结果不确定.现在看看这种传统方式下一Visual Studio Unit TEst框架为主UT编写开发人员要重复做哪些工作.?首先要重复手动编写大量的UT测试用例.目的是在给定的方法中为每个执行路径手写独立测试. 而且针对这种无法避免的要创建一个独立的测试项目.其实在实际编码中.并不是所有模块都需要即时建立UT.可能需求发生变更.从开发人员角度来说创建一个笨重测试项目这意味更多精力发在测试代码维护上.可能我们更需要一种既能够创建对应测试项目同时也能即时看到当前版本Code UT效果.
Now.UT属于白盒测试的范畴.如果能够有一个很好白盒测试工具能够封装这些重复的行为.并能够重复执行UT测试用例.让开发人员从Ut的过多细节和维护中解放出来关注更核心的业务逻辑.Pex and moles就是这样的一个工具.

<2>Pex 构建白盒测试
虽然本篇幅没有核心焦点放到Pex实现原理上.但关于Pex and Moles其实分为两块整理官方原文翻译如下[直译]:

Pex Pex 是一个 Visual Studio 外接程序，用于补充 .NET Framework 应用程序上的单元测试。 Pex 在 Visual Studio 代码编辑器中查找对应程序方法的输入和输出值。 PEx将这些值另存为将具有高代码覆盖率的小型测试套件。

Moles Moles 允许开发人员将任何 .NET 方法替换为委托。 Moles 通过使用 Detour 和 Stub 提供隔离来支持单元测试。因为 Moles 在方法级别工作，所以当目标 API 不支持它时，它提供替代项进行模拟。 SharePoint 是一个受益于隔离的常见 API 示例，但不直接支持模拟。Moles 还可用于错误植入，因为它使得开发人员在测试下向代码中注入任意行为变得轻松.

Pex核心是给开发人员一个手写的参数化单元测试，Pex完全自动地分析代码，来决定相关的测试输入。其结果就是生成一个有着高度代码覆盖的传统单元测试，另外，Pex还会建议开发人员如何去修复所发现的Bug.
安装完Pex and Moles工具后.打开Visual Studio 可以看到右键选项中多了:
Run Pex 和Pex 下Create Parameterized Unit Tests两个可操作选项.针对Pex测试效果.首先在Programe类添加一个字符串合并操作方法代码如下:
1: /// <summary> 2: /// Test Case Spilt String And Merge Operator 3: /// </summary> 4: /// <param name="firstname">First Name</param> 5: /// <param name="lastname">Last Name</param> 6: /// <returns>Merge String</returns> 7: public string SpiltStringToMerge(string firstname, string lastname) 8: { 9: string mergeString = string.Empty; 10: char[] firstNameArray = firstname.ToCharArray(); 11: char[] lastNameArray = lastname.ToCharArray(); 12: int count = 0; 13: foreach (char currentChar in firstNameArray) 14: { 15: if (count % 2 == 0) 16: mergeString += currentChar + lastNameArray[count]; 17: } 18: return mergeString; 19: }
注意该方法的输入参数firstname和lastname在方法内都没有判断是否空字符串或是Null而且里面涉及字符数组的操作.针对该方法采用Pex方式执行UT操作.右键调集选中Run Pex 提示如下:
注意我们当前类是在Program类下.该类的签名如下:
1: class Program 2: { 3: }
提示的意思当前类型不可见.无法通过Pex方式创建UT,需要把当前类的签名改成公开虚类型即可:
1: public partial class Program 2: { 3: }
在来运行Run Pex 弹出执行结果窗体如下:
可以看到Pex在没有创建一个独立单元测试项目和对应测试类情况.自动对当前方法进行白盒测试封装.运行测试109 Runs次.创建了7个测试用例. PEx会监视当前类，并且运行这个方法.执行多次测试.其中有三次测试失败的.并Sunmmary/Exception 提出具体测试参数和出现的异常信息.
点击对应失败的测试用例.可以在右侧弹出对应异常堆栈详细信息.:
点击DEtails可以看到执行该测试用例的代码和对应异常信息:
在查看异常详情右侧窗口中.可以执行如下操作:
Save Test保存当前PEX的测试用例为普通单元测试用例.点击保存:
如果在此之前没有创建对应Pex测试项目会提示当前测试用例输出.或是提示创建一个新的测试项目:
上面Project Under Test是待测试的宿主项目.而下面是需要创建新的测试项目设置.点击OK创建一个新的测试项目.这里在RunPex时并没有强制开发人员强制建立一个新的测试项目.但是这里SAve 目的是在于如果觉得当前测试代码可以留存做以后回归测试.PEX也是支持测试代码保存的.
add Precondition是用来通过Pex自动添加代码来避免错误的发生.而All Exception则允许次异常在当前应用程序中出现.send to如果你的项目采用TFS版本控制.sendto操作会吧所有信息发到文本或剪切板中.这里所有的信息包括Detail和STack Trace 如果TFS里配置WorkItem,PEX会自动发送对应的WorkItem中.
well现在既然存在异常.通过Add PreCondition来通过Pex来修正.会看到如下菜单:
这个窗体中上半部分告诉开发人员PEX在当前会做哪些操作.操作会修改哪些方法等.下半部分则是PEX具体的添加的修复代码.可以看到对firstname输入参数因当前NullException异常所以添加了是否非Null的判断。点击Apply可以看到原来代码中添加一段判断代码完整如下:
1: public string SpiltStringToMerge(string firstname, string lastname) 2: { 3: // <pex> 4: if (firstname == (string)null) 5: throw new ArgumentNullException("firstname"); 6: // </pex> 7: string mergeString = string.Empty; 8: char[] firstNameArray = firstname.ToCharArray(); 9: char[] lastNameArray = lastname.ToCharArray(); 10: int count = 0; 11: foreach (char currentChar in firstNameArray) 12: { 13: if (count % 2 == 0) 14: mergeString += currentChar + lastNameArray[count]; 15: } 16: return mergeString; 17: }
<pex>标签之间注释就是PEX修复是添加的代码.如果觉得PEX代码不够美化.开发人员也完全可以手工修改.自此你会看到PEX帮开发人员找到一个Bug并尝试不在维护UT代码的情况下并修复该异常.well.当然如上演示只是PEX作为白盒测试工具的丰富功能一个特性.其实刚开始看官方给出解释最吸引我莫过于它支持写参数化单元测试[Parameterized Unit Test].方式.

<3>Pex参数化单元测试
在Pex中针对白盒测试提出参数化单元测试的概念-Parameterized Unit Test。Dang我们通过PEX实现更多模块的UT操作.确保所有单个模块能够按照程序设计预期执行. 其实实际效果并非如此.PEX通过一个指令一个指令地分析.NET代码，解释代码执行时的动作，然后“以一种完全自动的方式，计算出那些能触发边角代码的相关测试输入。”
PEX在执行和分析代码行为时.只是得到代码最基本代码模块行为简单异常类似NullException.但是实际上开发人员并没有写过一个关于所有模块集成起来之后完整测试用例. 无法预期当前软件的行为.PEX提供参数化的单元测试提供一种强大的方式来评估当前代码在集成后是否如预期一样行为.
找到上次增加SpiltStringToMerge字符串合并操作方法做实例.创建参数化单元测试:
找到该方法选中右键点击可以看到Pex->Create Parameterized Unit Tests选项:
如果原来没有创建对应的PEX测试项目会提示创建一个新的Test Project.与宿主程序分离.可以看到增对测试文件目标PEX增加多重过滤项. 在Test Project项目输出上如果没有创建Test Project则创建.当然针对创建的测试项目可以指定不同的测试框架.PEX中集成了NUnit/Visual Studio Unit TEst/MbUnit V系列等.让开发人员以自己最熟悉的测试框架来维护测试代码.Pex还基于扩展反射可管理子协议API （Extended Reflection managed profiling API）对监测应用程序的集成提供了支持.在创建看一下设置项Settings:
可以设置默认创建的命名空间和测试类下默认PexMethod测试方法.这里采用默认方式创建:
创建成功后Solution目录:
打开ProgramTest.cs文件可以看到这个PEX自动生成的参数化单元测试方法:
1: [PexClass(typeof(Program))] 2: [PexAllowedExceptionFromTypeUnderTest(typeof(InvalidOperationException))] 3: [PexAllowedExceptionFromTypeUnderTest(typeof(ArgumentException), AcceptExceptionSubtypes = true)] 4: [TestClass] 5: public partial class ProgramTest 6: { 7: /// <summary>Test stub for SpiltStringToMerge(String, String)</summary> 8: [PexMethod] 9: public string SpiltStringToMerge( 10: [PexAssumeUnderTest]Program target, 11: string firstname, 12: string lastname 13: ) 14: { 15: string result = target.SpiltStringToMerge(firstname, lastname); 16: return result; 17: // TODO: add assertions to method ProgramTest.SpiltStringToMerge(Program, String, String) 18: } 19: }
其实关于PEX参数化单元测试的概念.其实它就是一个带有参数并通过调用宿主测试程序简单测试方法.其实这里很多人都很疑惑怎么和传统创建单元测试方法和PEX参数化方法区别在哪呢?其实昨天我在看到这时也很困惑很久.后来在官方找了很多资料.总算是找到一点权威的论述:

A unit test is a method without parameters represents a test case which typically executes. a method of a class-under-test with fixed arguments and verifies that it returns the.

expected result. A parameterized unit test (PUT) is the straightforward generalization。of a unit test by allowing parameters. PUTs make statements about the code’s behavior.

for an entire set of possible input values, instead of just a single exemplary input value.

相对传统创建的单元测试一般情况参数都是指定固定的参数值.并在执行后会预期函数中返回对应的结果.PEX参数化单元测试概念则不同.在PEX中单元测试的参数可以输入任何可能的参数用来验证程序代码执行中所有可能的行为.你大概明白PEX提出这个概念的目的了吧.也就是说PEX在执行的时候会分析PEX参数化单元测试代码方式来查看宿主程序代码的行为.当然这个过程需要集成宿主程序的代码.而相对于传统固定参数值.PEX单元测试参数可以是任意的.这样更便于测试过程中测试宿主程序代码可能出现崩溃的几率和行为.

当前已经创建PEX对应的测试项目.在回到宿主横须Program类中.再次运行Run PEX:

出了能看到原来Pex Test Results窗体测试结果.注意这时PEX内部根据测试需要会在测试项目对应测试ProgramTEst类中.创建普通测试方法[TestMethod]同时也会创建PEX下参数化单元测试. 创建普通测试的数量和测试结果中测试用例的数量是一致的.如果TestReaults.PEX使用7个用例那么在ProgramTest.SpiltStringToMerme.g.cs文件中肯定会有相同数量的普通测试方法存在.PEX参数化单元测试方法则放在ProgramTest.cs文件中.

如果你觉得这个过程不明显.或是想了解一些PEX工作处理过程.可以选中右键可以PEX->Delete Generated Unit Tests操作:

其实该操作的目的会自动删除ProgramTest.SpiltStringToMerme.g.cs文件中所有的普通测试方法[TestMethod]也就是当前使用测试用例.然后找到该方法在运行Run PEX./运行玩后可以找到对应测试实例的Save Test方式在把指定的测试用例保存到ProgramTest.SpiltStringToMerme.g.cs文件中.well 这里保存第一个通过的测试用例低级Save TEst:

Apply.完成后.会看到ProgramTest.SpiltStringToMerme.g.cs文件中多了一个普通测试方法.同时在Test Result窗体中发现每个测试的图标不再包含一个磁盘位图而是一个对号.:

1: public partial class ProgramTestTest 2: { 3: [TestMethod] 4: [PexGeneratedBy(typeof(ProgramTestTest))] 5: public void SpiltStringToMerge355() 6: { 7: string s; 8: ProgramTest s0 = new ProgramTest(); 9: Program s1 = new Program(); 10: s = this.SpiltStringToMerge(s0, s1, "", ""); 11: Assert.AreEqual<string>("", s); 12: Assert.IsNotNull((object)s0); 13: } 14: }

这样有选择的方式让开发人员很轻松能够保存在不同版本需求变动生成的测试用例/.而且是可选择的.当然在添加过程往往会提示一些命名上问题例如如下提示:

这是因为现在PEX现在对中文GB2312格式支持存在乱码的问题. 当然在创建是PEX为了防止访问路径过长.就限制在PEX所有文件命名长度.

其实到这里很多人依然对PEX 参数化单元测试的概念依然有些困惑.这个概念其实很简单.但在实际运用你会发现它的实际用途的好处.如果你熟悉并常用的单元测试.但还不理解PEX中参数化单元测试概念.可以从以下几个方向去考虑[仅作参考]：

理解参数化单元测试的方向:

[1]:当时你手写普通的单元测试.思考以下你要测试代码的行为.在构建单元测试时你的需要多少个独立参数传入.?

[2]:目前尚不清楚确切的数字可能会是什么.但在测试过程它是很重要的,因PEX角度来说开发人员永远有时间来即时创建和维护测试代码.

当然更多还请参考官方的资料:http://research.microsoft.com/en-us/projects/pex/default.aspx

<4>Pex小结
本篇PEX 自身应用角度来阐述PEX相对传统单元测试所具有的特点.作为一个白盒的测试工具.开发人员常在程序开发过程中.需求往往也是不断变化的.当然也无法避免未来开发过程中.或进入代码维护阶段是.所需要面对代码修正的问题.为了每次都能保证软件代码工作都正确无误.而且即时在需求发生变更需要添加新功能时.也能保证原有功能正常运行.使用可控的测试导向的开发模式是必行的.
当然作为开发人员要在开发过程手工编写大量的测试用例并维护笨重测试的代码.这会在一定程度上导致项目开发进度延缓。这也是很多开发人员忽视UT一个原因之一.但现在PEX白盒测试工具.可以把测试流程完全的自动化.把开发人员从单元测试的需求中解脱出来专注于核心业务开发之上.
本篇并没有急于在Windows phone Application 中验证PEX是否可行.但是PEX透露出来关于测试理念确实很有深入的价值.稍后会在下篇副中无论成功还是失败.演示Windows phone应用程序中使用PEX整个过程.
如有问题请在评论中提出.本篇所有源代码下载地址如下:/Files/chenkai/BasicConsolePexComponent_Demo.rar
本文链接

Git Tool Part 2

2012-01-13T07:51:00Z

针对Git的使用.在Git中文操作指南手册中.讲解大量关于GiT的细节操作.可是对于从SVN或是TFS转换的很多开发人员来说.很多并没有更多学习周期时间.那么如何才能短时间内抓住Git核心枝干.短时间内快速进入Git并在代码中集成使用工具呢.? 由于Git中富含大量的Git 命令.细节太多.本来打算在本篇中介绍一些Git通过命令的方式基本操作.等写了大概四分之一.发现完全和最初写这篇文章初衷完全背离了.

其实本篇的目的很简单.与其陷入在在长长的篇幅中介绍Git Command基本用法还不如直接采用Windows 平台开发人员最熟悉的GUI界面工具操作更为直观.Git原理理论和操作用法也是非常系统.如果你觉得有必要建立一个系统知识结构.当然也有很好的资源可以当做日常查看手册:

Git 系统资源:

Git中文操作指南 Download Link[http://vdisk.weibo.com/s/1UJq4]

Git Command指令在线文档: [http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/zh_cn/index.html]

<<Git Community Book中文版>>：[http://gitbook.liuhui998.com/]

注:如上在线文档或图书版权源作者拥有.本文只是添加引用.如转载请注明出处.

作为Windows 平台开发人员最常用的开发工具莫过于Visual Studio系列.但是可惜的Git作为从Linux平台的舶来品..NET开发人员更习惯于使用用户界面，所以在进行日常任务的时候更习惯使用操作基于具有IDE的界面.

作为一个Visual Studio用户.在使用Visual SouceSafe/Team Foundation Server、Subversion或甚至Mercurial的过程中.已经建立了使用源码控制习惯.更多的开发人员希望在Solution解决方案目录中就直观看到自己的SouceCode被版本管理工具所控制着.无论在代码修改或添加都能直接获得状态反馈.所以在Visual Studio使用Git需求就一直成为Git一块”硬伤”.

如何在Visual STudio系列开发工具中使用Git版本控制工具?

<1>Visual Studio 构建Git部署环境

Well，谈到这里在上章节中Git Tool Part 1中提到能够适用Windows 平台的Git工具主要具有两个模拟*nix like运行环境的工具：cygwin，msys；Git在cygwin，msys下都有相应的移植版本.不过就使用体验来说个人觉得msys平台下的msysGit最好用.在GUI图形工具上有Git extentions ，还是TortoiseGit.更加倾向于前者.

Linux开源社区也考虑到很多Windows平台开发人员的需求.在后来工具支持上推出可以Visual Studio系列开发工具集成Git版本控制系统插件-Gitextensions.这是目前Visual Studio系列开发工具唯一支持Git具有GUI操作界面的插件.

至此在Visual Studio IDE开发工具构建Git版本控制工具组合就诞生了:

Visual Stuido Git版本控制工具组合:

Git 命令行(MsysGit) + Git Extensions + Git Source Control Provider [Only Support Visual Studio 2010]

Git 命令行一般采用BitBash工具来直接采用命令操作.

Git Extensions：则是直接Visual Studio 开发工具中集成Git GUI操作工具.

Git Souce Control Provider:为Visual STudio 提供Git版本控制支持.

首先安装MsysGit可以在[http://code.google.com/p/msysgit/]下载到最新的FullInstall版本.安装步骤请参考GitHub上Wiki[https://github.com/msysgit/msysgit/wiki/InstallMSysGit].默认编辑工具是Vim/

因Git Extensions工具是基于Git 命令行,可以在安装MsysGit之后通过[http://code.google.com/p/gitextensions/]下载安装;在安装过程中因已经安装MsysGit版本[可选也可不选].所以只需选择集成KDiff3工具即可:

另外关于Git Extension传输协议选择:

OpenSSH 客户端，提供 Git 访问 ssh 协议的版本库.Git自身支持多种协议.在此选择默认安装OpenSSH.在GitExtension安装完成后.通过Start->Git Extension安装目录.打开Git Extension.找到Setting设置设置选项页Git:

一般情况如果安装顺序没有问题.安装Git Extension工具后都会自动找到对应Git命令行工具安装路径,git命令行工具有两种，一种是 cygwin 下命令行，一种是 msysGit 命令行，git extensions 可以配置使用哪一种命令行工具。因Git Extension是基于命令行操作的.在执行请检查该设置是否指向正确Git命令行安装工具路径.

最后需要安装Git Source Control Provider,打开Visual STudio 2010开发工具.找到Tools->Extension Manager选择Online Gallery选项页搜索:Git Source Control Provider 看到：

下载安装.当然也可以不用打开Visual Studio 也可以通过[Git Source Control Provider]地址直接下载安装即可.安装完成后找到Tools->Options->Souce Control选项中把Git Souce Control Provider作为默认版本控制工具:

至此在Visual Studio 2010搭建好了Git版本控制需要环境.

<2>Git在Visual Studio 基本操作

构建好Git在Visual Studio 2010开发工具版本控制.通过一个具体的Windows phone Application 来演示一下Git基本操作，首先在硬盘上开辟一个独立的文件夹CodeDevelopment：在该项目源码放在该目录下新建解决方案如下.看看初始状态：

在初始状态下并没有继承Git版本控制.如果在Setting目录下设置Git.可以通过右键点击文件可以看到Git操作的选项:

如要对某个项目执行Git版本控制管理.只需到此项目所在的目录创建一个仓库.也就是Git-New Repotiory操作，执行完成后能在项目目录下看到多了Git文件目录:

初始化后，在当前目录下会出现一个名为 .git 的目录，所有 Git 需要的数据和资源都存放在这个目录中。不过目前，仅仅是按照既有的结构框架初始化好了里边所有的文件和目录，但我们还没有开始跟踪管理项目中的任何一个文件.和.git同处一个目录的所有文件，现在就纳入了这个版本库的范围之内.可以在改目录下执行Git命令.也能够看到Visual STudio多了两个View窗口:

当创建完一个仓库发现解决方案的代码文件并没有类似SVN或TFS发生状态变化-即通过文件前小图标标识状态.不知道为何这可能Git Extension一个Bug.这时只有通过重启VS工具才能看到文件跟踪的状态:

well.是否可TFS和SVN体验一致.Well来看看库当前状态右键点击项目找到Git->GitBesh通过Git指令:Git Status执行

这说明你现在的工作目录相当干净。换句话说，当前没有任何跟踪着的文件，也没有任何文件在上次提交后更改过。此外，上面的信息还表明，当前目录下没有出现任何处于未跟踪的新文件，否则 Git 会在这里列出来。最后，该命令还显示了当前所在的分支是 master，这是默认的分支名称.在没有进入代码修改之前.可以提交解决方案最原始的版本.通过右键点击解决方案找到Git->Commit执行第一次版本提交:

执行后看到Commit页面,因现在文件都没有添加到Git暂存区.所以如果直接提交会提示：

所以在执行操作之前可以把所有文件添加到Git暂存区，添加MEssage 直接提交:

点击提交Commit按钮提交成功:

现在在代码修改Mainpage页面PageTitle为chenkai.后再次提交.就能直接看到修改的差异:

关于我们创建没有做任何操作直接执行提交操作时提示. 其实是说明Git在执行提交操作必要的流程.在工作目录下面的所有文件都不外乎这两种状态：已跟踪或未跟踪。已跟踪的文件是指本来就被纳入版本控制管理的文件，在上次快照中有它们的记录，工作一段时间后，它们的状态可能是未更新，已修改或者已放入暂存区。而所有其他文件都属于未跟踪文件。它们既没有上次更新时的快照，也不在当前的暂存区域.文件在整个Git版本控制状态周期：

Git的暂存区是在版本未在提交之前存储位置.从上图可以看出.整个提交流程目录变化位置:工作目录->暂存区->版本库.暂存区的目的相当于实际编码和真正提交到Git执行版本追踪之间一个缓冲地带.这有什么好处呢.?很简单.暂存区的文件可以任意的在工作目录和版本库实现自由的交互.这样设计目的用户在操作过程可能会出错.暂存区也就给了用户撤销原来操作的可能.在文件没有进行任何操作之前一般通过Git Add指令吧文件添加到暂存区.在执行Commit操作时文件状态就有暂存区提交成为Git版本受控制的版本库中.

在Commit页面可以看到一个键便捷的操作:

实现从工作目录到暂存区文件批量操作.其实Stage的操作内部封装就是Git add指令.当然也可以通过AddFiles 执行这种批量操作:

当然在Git中执行提交操作依然可以跳过暂存区操作.尽管使用暂存区域的方式可以精心准备要提交的细节，但有时候这么做略显繁琐。Git 提供了一个跳过使用暂存区域的方式，只要在提交的时候，给 `git commit` 加上 `-a` 选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交：这就是从工作目录->版本库直接操作.可以打开命令行:

可以看到，提交后它会告诉你，当前是在哪个分支（master）提交的，本次提交的完整 SHA-1 校验和是什么（`463dc4f`），以及在本次提交中，有多少文件修订过，多少行添改和删改过.提交成功后.看一下文件状态:

由原来的加号变锁.标识当前所有的文件已经第一次提交到版本库.如果当前再次修改MainPage.xaml则可以看到文件状态发生改变:

红色对勾标识当前文件已经发生了修改.而浅黄色的感叹号.标识当前文件状态由工作目录已经存放暂存区等待提交.假如我们在正常编译操作.执行多次提交.可能某一次版本提交时会出现手工操作失误.比如在这次版本提交以往提交某些文件，或是忘记修改某些文件.可能需要撤消刚才所做的某些操作,请注意，有些操作并不总是可以撤消的，所以请务必谨慎小心，一旦失误，就有可能丢失部分工作成果。可以使用 `--amend` 选项重新提交.:

1: $ git commit --amend
令将使用当前的暂存区域快照提交。如果刚才提交完没有作任何改动，直接运行此命令的话，相当于有机会重新编辑提交说明，而所提交的文件快照和之前的一样,如果刚才提交时忘了暂存某些修改，可以先补上暂存操作，然后再运行 `--amend` 提交:
1: $ git commit -m 'initial commit' 2: $ git add forgotten_file 3: $ git commit --amend
ok.现在修改MainPage.xaml。在把这个文件追加上一个版本中添加Add Files操作后执行Git命令如下:
well顺利提交.有时我们通过Git Extension集成的命令通过Add Files 方式把当前所有工作的目录的文件添加到暂存区.也就是添加Git版本跟踪. 可能为了减轻操作的负担.对于有些应用程序编译中自动生成的文件.类似日志.或编译的文件并不需要Git版本管理.需要把这些文件从暂存区剔除掉.取消暂存区文件.可以执行如下Git命令:
1: git reset HEAD <file文件名称>...
在我们执行提交多次可以Git Extension中查看提交的版本.当然也可以通过命令Git Log方式查看同样的效果:
可以看到最后一次提交版本Message.总共提交三次版本.当然也可以在Git History看到图形化的提交历史版本:
当我们修改完成之后.在编辑过程达到一个满意的过程.,git 是分布式版本系统，都有一个 git 版本库的拷贝，为了和远程其他版本库同步，需要进行同步操作.同步操作一般分为拉取pull.另外一个推送Push.针对Git的服务器.如果比较大的组织结构可以企业内部构建自己的Git服务器.如果是小型团队.完全没有必要这么麻烦.现在依然很好第三方托管服务类似GitHub.
首先需要建立一个GitHub账号.就不多说了打开后能看到操作流程如下:
因已经配置过Git环境.所以直接创建一个Create Repository：
填写项目名称.描述和HomePage是可选项.当然最关键是可以设置GitHub托管的项目是否公开或私密状态.创建库Repository完成可以看到具体操作Git指令的流程如下:
首先需要见车Git Bash是否设置对应的全局的用户名和Email:
设置完成后需要在GitHub针对托管的项目添加一个公钥，如果没有公钥则可以通过Bit Extension工具自动生成一个匹配的公钥和私钥文件并保存在本地,带卡Bit Extension 找到：
打开操作General 生成一对公私密钥,并保存本地硬盘目录中:
保存上面的公钥字符串和公钥key文件为public文件，密钥为private.ppk文件.保存完成后需要到GitHub控制面版页面把该公钥添加上去:
添加成功后.在指令操作流程页面就可以GitHub对外公开该项目访问路径:git@github.com:chenkai/GitBaseOperator_Demo.git,对于Github上对外访问路径格式一般是：一般是 git@github.com:yourName/yourProject.git 格式. 这时我们可以把已经修改的应用程序通过Visual Studio 中Git Push到GitHub上:
这时会提示一个窗体:
首先点击Manage添加默认的添加项目信息. 找到 Default Pull:
添加远程的Github项目信息.并save，在选择Remote REspositories设置对应项目Reposity的基本信息并Save:
关闭窗体回到Push主页面就会看到对应默认项目是BitBaseOperator_Demo.ok此时点击Push开始推送代码到Github上:
确定.在调用Git.Exe是需要允许其对外访问输入yes:
开始推送如果提示出错类似如下:
提示当前权限不允许操作.远程连接中断.好吧这个问题折腾我好久.后来在官方社区看到解决方法.其实这主要是GitBash通过cmd命令进入命令行输入界面的。正确的操作是，在git附带的bash（GitBash可以在开始菜单的git目标里面找到）里面运行命令，就可以一切正常。当然如果觉得这种界面操作麻烦也可以根据官方给出的纯指令的方式操作吧代码Push到GitHub上操作流程如下或是参加如下小白解决方案[ttp://help.github.com/win-set-up-git/]:

github的官方文档
#1. Check for SSH keys.
$ cd ~/.ssh
#2. Backup and remove existing SSH keys.
$ lsLists all the subdirectories in the current directory
$ mkdir key_backupmakes a subdirectory called "key_backup" in the current directory
$ cp id_rsa* key_backupCopies the contents of the id_rsa directory into key_backup
$ rm id_rsa*
#3. Generate a new SSH key.
$ ssh-keygen -t rsa -C "your_email@youremail.com"
#4. Add your SSH key to GitHub.
#5. Test everything out.
$ ssh -T git@github.com
Git Bash中执行push令如下:
Push指令： $ git remote add origin git@github.com:testinguser/yourproj.git
$ git push origin master
在实际操作还有另外一种情况.也会导致这种情况出错.出错的原因是因为公私密钥保存位置不在默认目录下.导致在Push时提示需要提示提供公钥.所以在并不推荐使用工具的方式生成密钥，如果要保存最好不要自定义保存目录: 当然最好的方式就是官方给出通过Bit Bash指令工具自动生成.操作流程如下:
首先通过自己的电子邮件生成对应的公私密钥.保存和存储指令一律采用默认为空的方式保存默认目录下.注意这个默认目录在User创建成功可以通过如下指令测试是否连接GitHub成功"：
1: ssh -T git@github.com
测试成功成功后.在来通过Visual STudio 中Git集成Push到GitHub上:
you see Push成功.GitHub也能看到对应目录和Code.
well.当我们通过GitHub首先第三方代理时.通过和其他开发人员或第三方团队时很方便.随时随地就可以把代码Commit或是Pull一个版本，这样分布式结构完全体现Git的威力.ok加入Team另外一个成员修改Github上源码并Commit一个完整版本.现在Pull下来一个最新SouceCode.在Visual Studio中：执行Pull:
分支选择以主干Master. 合并策略Merge默认以GitHub SouceCode为基准覆盖本地.
Pull 成功.
如果在GitHub看到不错的项目可以通过本地找到指定目录Clone本地:
Clone操作执行本地源码:
…
Git操作的细节太多了. 我这个短短的篇幅中是无法写完的.只能列举一些在Visual Studio最基本的应用.展示一下Git作为版本控制工具强项.权当抛砖引玉.

<3>Git小结
Git作为很好的分布式的版本控制工具.在版本控制能够优雅实现多种类型模式和Team的协作模式.机动灵活处理了版本控制各种问题.当然这篇文章我写了两天.主要是要重现Git大量细节操作太费时费力了.写的很累.篇幅毕竟有限.不能全面覆盖.只能抛砖引玉.对于Windows平台的用户来这种分布式控制版本控制工具.与强大Visual Studio集成.对Windows 平台开发人员和日常团队管理来说也是”福音”,极力推荐.
可以参考上篇:Git Tool Part 1
本文链接