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)，最后到源代碼都一一重構完畢。