使用 ReSharper对.NET解决方案进行全面重构
ReSharper是面向微软开发环境Visual Studio(2005、2008、2010)的重构工具，对包含着众多项目的一个解决方案可作完美重构，只要按照正确的方法操作，诸如命名空间、程序集名称等都可顺利替换，最重要的是这一过程不会影响到各程序集间的引用关系。
引用一段官网的说明：
ReSharper is a renowned productivity tool that makes Microsoft Visual Studio a much better IDE. Thousands of .NET developers worldwide wonder how they've ever lived without ReSharper's code inspections, automated refactorings, blazing fast navigation, and coding assistance.
翻译：
ReSharper 是让微软 Visual Stuido 成为更好IDE(集成开发环境)的著名效能工具。遍布于世的成千上万.NET开发者无不为ReSharper的代码检查、自动重构、迅捷导航和代码辅助提示感到惊奇不已。(去官方网站瞧瞧)
In meet the ReSharper before...(不好意思，马上切换到汉语状态)在发现 ReSharper 之前，我对项目的整体重构怀揣着强烈的敬畏之感，当默认命名空间、程序名称确定之后，在开发过程中根本不敢乱动，更别说项目的文件夹等名(一经修改，启动.sln后VS百分百出错，不过现在不怕了)，唯恐VS在加载各项目时出现“某某程序不可用”等情况，更何况代码是受SVN的版控，一旦本地乱了套，那"提交"操作更是让人惶恐不安(吃不下、睡不香)，即便公司有牛人帮咱顶着，但若屡次出现这般情况势必会在Team中给自己造成不好的印象。接下来我想说说ReSharper是怎么重构项目而统一命名，但在此之前需要对.NET解决方案的文件层次有个了解，先看一个截图，有个感性认识：
图片说明：有一主窗体程序Java.UI，还有一类库项目Java.Model，同时主窗体程序引用了类库项目。
OK，我们现在重构的目标是：将所有以Java打头的名称，统统修改为NET打头。（不留任何死角喔！）
以上解决方案的截图想必大家再熟悉不过，所以乍一听似乎没什么大不了，但你若想作全面修改、不留Bug、不留死角，嘿嘿，可没那么简单喔(^_^)，接下来我们先对VS的文件架构作一下剖析，于是我将上述解决方案先作四个层面的划分：
-
基于本地磁盘文件存放时呈现出的名称
图片说明：VS中每一个项目(Project)对应着本地磁盘的一个文件夹，文件夹的名称在创建之初得以确认。需强调的是，其名称更改只能在本地磁盘相关文件夹上修改，VS无论如何也改不了，那么经我手动修改后造成的问题会在下文讲解。
另外还有一个额外文件叫：_ReSharper.ReSharpterDemo，它是ReSharper临时生成的缓存文件，关闭VS后可手动删除。 - 基于VS解决方案整体架构名称：
位于解决方案资源管理器上这两个项目的名称是可以随便更改的，且不会破坏引用关系(UI已引用了Model)，编译也可顺利通过。值得注意的是一经修改它影响到的是.csproj文件的名称：
-
应用程序的默认命名空间、程序集名称：
图片说明：上图中的两个名称是用以限定生成的exe和dll文件的名称(他们位于bin/Debug或bin/Release中)，如图：
-
源代码中的各种相关名称，主要是using块的引用：
到此为止，我们已将解决方案的各个死角全部罗列清晰。
---------------------------------------------------------------------------------------------------
接下来我们一个一个解决：
❶首先修改解决方案整体架构名称：
图片说明：通过这一步修改，VS整体架构名称得到了修正，与此同时两个项目的.csproj名称也一并修正，如图：
图片说明：.csproj的新名称会自动同步到.sln文件中，所以下一次重新打开整个解决方案是没有任何问题的，不妨看一看.sln文件：
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Net.UI", "Java.UI\Net.UI.csproj", "{BF0E3C7D-8D79-4CBA-84B3-CEF490B98271}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Net.Model", "Java.Model\Net.Model.csproj", "{680B5493-8970-41E9-891A-92AF8216497E}"
EndProject
❷接下来修改应用程序的程序集名和默认命名空间：
图片说明：程序集名称会影响着bin/Debug文件夹中生成的exe或dll文件的名称。
与此同时，ReSharper会在源代码提示命名空间的声明与文件位置(File Location)不一致，看看：
图片说明：原先我们定义的命名空间名叫：Java.Model，而我们的修正期望结果是Net.Model，
于是ReSharper给出了修正建议。(注：VS不会报错，编译可照常通过)
❸接下来该修改源代码，通过ReSharper统一修改源代码中的命名空间，而无需关心引用关系，即可以先对Java.Model进行名称修正，也可以先对Java.UI进行名称修正。值得一提的是Java.Model，因为它被外观层Java.UI所引用，一看便知：
图片说明： 可以将该处的Java.Model看作是命名空间的声明
图片说明：而该处的Java.Model便是引用
只要在声明处，右键，"Refactor"-->"Rename"项:
弹出菜单作修改成Net.Model：
到了这一步，源代码中命名空间名称的"声明"和"引用"将完成一体化修正：
❹文件夹名称修正：
如果项目受SVN的版控，显然要通过SVN的右键菜单来修改文件夹名称，若是无版控，则可直接修改：
修改为：
我们把VS关闭，重新开启，发现两个项目都不可用
这是因为文件夹名称修正后，.sln(Visual Studio.Solution)文件中的引用路径未经修正，尽管其他名称都是按预期的NET字样打头：
# Visual Studio 2010
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Net.UI", "Java.UI\Net.UI.csproj", "{BF0E3C7D-8D79-4CBA-84B3-CEF490B98271}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Net.Model", "Java.Model\Net.Model.csproj", "{680B5493-8970-41E9-891A-92AF8216497E}"
EndProject
怎么修复呢？直接修改.sln吗？目前该解决方案中只有两个项目，手动修改很简便，但若是像PetShop项目有22个项目的话，那还能手动修改吗？显然行不通。我们把“不可用”的项目全部移除，然后“添加(D)”-->“现有项目(E)”，以此来重新构建.sln文件，如下图：
添加现有项目是件很有讲究的事情，因为项目间是有引用关系的，我可不想在添加完所有现有项目后，其包含的引用关系全部“断裂”，而导致我不得不重新引用一次，多浪费时间！也许您会说，这个浪费的时间，跟我去思考如何缕顺每一层的引用关系所花时间是一样一样的，那我得提醒你：引用关系的“断裂”意味着错误，而且添加重新引用时你也不得不弄清楚谁引用了哪些项目，但反过来缕顺关系按次序添加则是正确的做事方法。
我们知道 Net.UI 层引用了 Net.Model层，可见Net.Model是高层建筑的“基础”，故在添加现有项目时，得先引用Net.Model层。在这里，我且贴出先引用Net.UI时会出现的错误：
图片说明：可以看到，未添加Net.Model时，引用项里会给出感叹号图标。
先引用Net.Model，再引用Net.UI：
至此，一个解决方案的程序集名称、默认命名空间名称：从文件夹到项目文件(.csproj)，再到bin生成文件(.exe和.dll)，最后到源代码都一一重构完毕。
