.NET の構成ファイルが何のためにあるのかを正確に考える必要があります。これらは、アプリケーションの異なるデプロイメント間の違いを定義する場所です。したがって、コード化されたロジックに基づいて構成を動的に変更することについて話すときは、間違った方向に進んでいる可能性があると思います。構成を介して注入された設定から指示を受けるのは、コードです。
ある種の構成エディターを構築しようとしているようですか? Visual Studio に 2 つが組み込まれているのに、なぜこれを行うのですか? 編集ウィンドウとさまざまな構成エディター、ASP.NET 構成エディター、Microsoft サービス構成エディターなど。
私の経験では、開発環境とテスト環境と本番環境の web または app.config の違いは、通常、接続文字列、AppSettings、メッセージ キュー アドレス、サービス エンドポイント、Log4Net 設定など、いくつかの設定だけが異なります。 .
かなりの数の設定がありますが、構成の各ブロックには、通常、環境ごとに異なる属性が 1 つまたは 2 つしかありません。これに対する例外は、Spring.NET、CastleWinsor、Unity などの IOC 構成です。しかし、それでも、これらは多くの場合、環境ごとにまったく同じです。
離れて、このことについて少し考えてみることをお勧めします。あなたが解決しようとしている実際の問題について考えてみてください。おそらく、データベース主導のワークフローが必要ですか? 知らない。
config はランタイム コードによって駆動されるべきではないことを知っています。これは、展開とビルド時のことです。
そうは言っても、環境固有の構成を簡単に生成できる ConfigGenなどのツールがあります。これが本当に必要なときにチェックしてください。