我目前正在完成由其他人啓動的應用程序。他正在使用app.config進行一些設置，併爲其他部分使用自定義xml文件。這迫使我堅持下去，並且我想將配置整合到一個文件中。爲什麼使用app.config來存儲配置數據？
但我不確定是否將所有內容都移動到了app.config文件中，並拋出定製的xml文件，或者將所有內容移動到另一個文件中，而忘記了app.config。
我可以看到兩個參數，一個用於每個選項：
但我敢肯定，有一個事情比很多我現在可以想到。這就是爲什麼我問：
使用app.config存儲配置與「傳統」配置文件的優缺點是什麼？
使用app.config的主要好處是它是.NET應用程序存儲其配置的默認支持方式。任何人使用該應用程序或有朝一日繼承您的應用程序將感謝您使用既定的標準，而不是「自己動手」。另外，.NET框架支持使用，編寫，創建和修改app.config文件 - 如果你使用自己的方案，你將不得不多次重新發明輪子。
所以我肯定會推薦使用app.config - 這是THE在.NET中進行配置的方式，並且這是一個廣爲接受和支持良好的標準。
Marc
簡單性和程序可讀性。
App.config是.NET中用於存儲配置的常規方法，因此其他程序員可能會看到它。它存儲在XML中，因此與XML配置文件相比不會有任何性能。
它還可以處理的地方保存的app.config（的Documents and Settings/用戶名 /本地設置/應用程序數據/ 您的應用程序 /）位置，並自動保存根據您的應用程序的位置和版本的配置，允許同一應用程序的多個版本共存。
我想說，不需要兩個app.config和一個自定義XML文件，所以將兩者結合起來可能是一個好主意。
恕我直言的應用程序。配置是不存儲配置數據的一個非常方便的方式，主要是爲那些有兩個原因：
我更喜歡使用我自己的配置類，我使用XML序列化來加載和保存。您仍然可以從強類型設置中獲益，而且它更加靈活，因爲您可以定義任何需要的結構
如果項目的生命週期將其從一個環境移動到另一個環境，將它分割成不同的文件非常有用。
例如，當開發人員在處理代碼時，您可能希望應用程序指向「devsql」框。當是時候進行QA'd，代碼被部署到登臺服務器，並且你希望應用程序指向'stagingsql'。
如果您保留了app.config中的所有配置，並且已對app.config的dev版本進行了設置更改，則會將其複製並截斷暫存版本 - 現在您的QA人員正指向開發數據庫。
通過將'database.xml'與'app.config'分開，您可以允許不同環境之間的差異，但仍然允許更改配置文件從每個環境流向下一個環境，而不必擔心覆蓋定製。
我同意將XML序列化程序與「設置」類相結合是存儲設置的絕佳位置，尤其是在您有很多自定義類型或對象的情況下。
在Web.config中創建類來定義自己的配置部分非常簡單，它將爲您提供對配置數據的強類型訪問，允許您爲配置信息定義一種模式等。請參閱，例如，this article [4guysfromrolla.com]獲取實施細節。
App.config對連接和日誌記錄配置有很好的支持，您幾乎可以在所有應用程序中使用它們。重寫它們可能會帶來很多工作。另外，如果在app.config中使用「sectionGroup」，則可以具有某種結構靈活性。
但是在做某件事之前，我會詢問創建自定義配置文件的人爲什麼要這樣做。有一些不尋常的情況，app.config會給你帶來一些麻煩，比如你想通過Assembly.Load加載另一個DLL（帶有它自己的app.config）。在這種情況下，您需要將兩個配置合併到一個app.config中，並祈禱它們不會使用相同的密鑰進行任何配置。
在網絡測試中，您無法覆蓋web.config配置，因此也可能會帶來一些麻煩，因此無法執行您想要的操作。
但恕我直言，它只是在不尋常的情況下，app.config不會很好地工作。在大多數情況下，我認爲不值得創建自己的配置框架。
App.config是默認設置，在大多數情況下，它是處理應用程序配置的最佳方式，當您需要解析文件以獲取值以及文件變得足夠大時，這成爲一個問題。
這對於具有大型網站的網絡應用來說更是一個問題。配置文件，每次你提出請求時，web.config得到解析，這可能會導致稅收，你會看到一些ORM mapers。
您還可以輕鬆加密app.config的各個部分。 – RichardOD 2009-06-25 20:30:48
優點，是的！ – 2009-06-25 20:31:39
@RichardOD如果你可以添加一個詳細介紹如何進行加密的鏈接，這將是非常棒的。 – 2010-03-29 18:27:14