C#新增的特性中引起爭議的有許多，分部方法（Partial Method）算是一個。分部方法通常被定義在一個分部類中，在常規的類文件中也可實現。如果分部方法沒有被實現，編譯器就不會對他們進行編譯。
分部方法有著嚴格的限制。它們必須是私有的，不能返回值，不能有輸出參數。因為任何針對沒有被實現的分部方法的調用都會簡單地被忽略，所以說這些限制是非常有必要的。反過來又意味著，分部方法不能作為一個明確分配的變量。Visual Basic也有分部方法，盡管VB不需要對變量的明確分配，它也有同樣的限制。
有那麼多的限制，有人可能會問，“它們有什麼優點？”。這個問題問得好，基本上，分部方法僅被代碼生成器在處理輕量級事件的時候使用。就像 Alexander Jung所解釋的：
分部方法通常（也可能是唯一相關的）的應用場景就是在代碼生成的時候用於處理輕量級事件。假設你解析一個數據庫或者一個XML文件，然後生成了數據類，結果你會發現有數十個類、幾百個屬性以及一大堆泛型和模板文件等。分部方法另外一個經常被用到的地方是驗證，或者讓屬性的setter去更新另一個屬性。所以如果你要使用產生的代碼，或者在運行時有幾百個事件和數千個方法調用的話（ 其實大多數情況下只用到了其中的一點點），就讓分部方法來吧！分部方法在聲明和使用時要比事件容易得多，如果沒有用到它們，它們就會消失。
性能的提升並不是沒有代價的。從分部方法必須是私有的限制中，Alexander發現了它們的不足之處：
缺點：如果你喜歡元數據驅動的應用，並且已經被ASP.NET的數據綁定所困擾時（因為沒有其他的方法可以附上元數據）……那麼，就准備著在將來丟失信息吧！如果你需要為屬性的setter增加一些事件（基於跟蹤和調試的需要），如果你需要某個動態的行為（比如附上某個通用規則引擎）等等，那麼就讓我們祈禱代碼分析器的開發人員能夠預知這個場景（或者已經做好了准備）吧！你有了一個清晰的層的分離，那麼實體就應該對UI一無所知嗎？是的，將代碼直接放到數據類中會破壞層的關系，但是你可以手動地用分部方法實現真正的事件啊！
另外一些人對於C#中的分部方法也是憂慮重重，大部分是關於代碼設計器的使用的。Stefan Wenig寫道：
首先，我不是非常熱衷於設計器。我憂慮的是設計器也許很快就會將我們送上過去基於COM開發時的老路，數百個設計器和向導產生了那麼多沒人想去看的ATL和MCF代碼。在我們陷於設計器、創建的無用文件和復雜的構建過程時，使用Ruby的家伙們在笑，因為他們用幾行代碼就可以解決（聯想一下上世紀90年代COM/C++和Java的比較）。難道對於基於代碼的開發人員生產率不是C#所首要考慮的（看看VB的設計器驅動的RAD路線圖）？我們不應該再沉浸於基於設計器的，企業類庫思想的，樂於使用軟件工廠代碼設計器的幻想中了。團結起來，抵制它們！
Ayende Rahien也沒有嘴軟：
讓我們一起埋葬這些代碼設計器吧，豎起分部方法的輝煌墓碑！
