VBのWindowsフォームアプリでApp.configを環境ごとに分けてビルド

ありがとうございます。
フレームワークは「.NET8」です。
（10月からWindows Formアプリ開発に手を出し始めたくらいの初学者のため、言葉の使い方が間違えているかもしれません。）

すみません。大事なことを書いていませんでした。

このWindows Fromアプリを顧客ごとに設定を変えてリリースしたいと考えています。
顧客は定期的に増えてくるため、

• 設定ファイルとビルド定義を増やすだけで個社対応をしたい。
  というのが、要求に入ります。

教えていただいた内容の場合、顧客が増えるたびにコード修正が入れなくてはならないと理解しました。
ただ、.NET8の場合、App.configではなく、appsettings.jsonを使うほうが標準。というようですので、こちらの観点で調べていこうと思います。

また、追加の質問ですが、Windows FormアプリではDBの接続場やAPIのトークンなどの機密情報はどこに保持するのが一般的なのでしょうか？
珍しい要件ではないと思っていますが、調べても回答に辿り着けないため、私のアプローチがズレているような気がしています。

このWindows Fromアプリを顧客ごとに設定を変えてリリースしたいと考えています。
設定ファイルとビルド定義を増やすだけで個社対応をしたい。

「設定ファイルとビルド定義」って何ですか？

何にせよ、「顧客ごとに設定」する情報を構成ファイルに格納するのであれば、顧客ごとに構成ファイルを書き換えるのは当たり前の話で、絶対に「増やすだけ」という話にはならないはずです。

違いますか？

また、追加の質問ですが、Windows FormアプリではDBの接続場やAPIのトークンなどの機密情報はどこに保持するのが一般的なのでしょうか？

app.config とか appsettings.json を構成ファイルに使うのであれば、暗号化した情報を構成ファイルに保持してアプリで復号するということぐらいでしょうか。

その前に、WinForm アプリから直接 DB にアクセスすること自体が悪手だと思いますので、WinForms ⇔ Web API ⇔ DB という構成を考えることをお勧めします。そうすれば少なくとも WinForms のユーザーからは接続文字列は見えません。

本題とは関係ない話ですが・・・

フレームワークは「.NET8」です。

Windows OS 上で動かす Windows Forms アプリとか WPF アプリは、無理（？）してターゲットフレームワーク .NET で作らない方がよいと思います。

特定の OS に依存する機能は Visual Studio のテンプレートで作るプロジェクトには含まれてないとか（例: GDI+ に依存するグラフィックス機能、Shift_JIS エンコーディングなど）、ReportViewer や Chart が使えないとか、データソース構成ウィザードが使えないとか乗り越えなければならない壁に比較してメリットが少なそうな気がします。また、Web アプリですと、ASP.NET Web Forms アプリは対応できないという乗り越えられない壁があります。

ライフサイクル（サポート期間）を考えているなら、.NET 8 より .NET Framework 4.8 の方が長いはずです。

ありがとうございます。

「設定ファイルとビルド定義」って何ですか？

設定ファイルはApp.configであれば、App.xxxx.configで
ビルド定義は「Debug」「Release」「xxxx社」のようなイメージです。
これらはビルド定義とは言わないですかね？

「増やすだけ」という話にはならないはずです。

個社ごとのカスタマイズは行わないので、増やすときのコストを可能な限り減らすことを想定しています。

保持してアプリで復号する

となると鍵などの管理も面倒になりそうですね。

WinForms ⇔ Web API ⇔ DB

おっしゃることはわかりますが、今回の件に限らず小規模アプリだとなかなか厳しいところがあります。

Windows OS 上で動かす Windows Forms アプリとか WPF アプリは、無理（？）してターゲットフレームワーク .NET で作らない方がよいと思います。

今後の参考にさせていただきます。

ライフサイクル（サポート期間）を考えているなら、.NET 8 より .NET Framework 4.8 の方が長いはずです。

知りませんでした。むしろ逆のイメージを持っていました。

失礼しました。

これらはビルド定義とは言わないですかね？

質問者さんの言う「設定ファイルとビルド定義を増やす」というのは「構成ファイルの追加・差替えとプロジェクトファイルの書換」という意味だと想像しています。そうだとすると、少なくとも自分の知識の範囲では、言わないです。

なので、少なくとも私にとっては正しい用語ではなくて話が通じてないです。多分、他の人もそうだと思います。

個社ごとのカスタマイズは行わないので、増やすときのコストを可能な限り減らすことを想定しています。

前にも書きましたが、「顧客ごとに設定」する情報を構成ファイルに格納するのであれば、顧客ごとに構成ファイルを書き換えて差し替えるのは当たり前の話で、絶対に「増やすだけ」という話にはならないはずです。App.xxxx社.config という構成ファイルは顧客ごとに作るのではないのですか？

手間がかかろうが何であろうが払うべきコストは払うべきです。今回の質門者さんの案のように、コスト削減（ホントになっている？）のため、普通やらないことを無理してやるのは、かえってコストを増やすことにつながります。保守を考えた場合は特に。もし自分が質問の実装のようなアプリの保守を引き継いだら、こういう普通ではない独自実装した人を恨みますよ。

普通のやり方、Microsoft が推奨・サポートしているやり方をお勧めします。

最初の回答で紹介した記事に Microsoft のドキュメント「.NET Framework から .NET にアップグレードした後に最新化する」へのリンクが張ってありますが、その記事に書いてあるように、構成ファイルには appsettings.json を使うことが推奨されてます。

そして、「WinForms アプリで構成情報の上書き (CORE)」で紹介したように、複数の appsettings.json を作って実行時に上書きする機能が提供されています。その記事は appsettings.json, appsettings.Production.json の 2 つだけの例ですが、さらに、例えば appsettings.User.json という名前の構成ファイルを追加することもできます。

普通のやり方、Microsoft が推奨・サポートしているやり方はすでに教えたので、後は質問者さんの方で考えてください。

ありがとうございます。
「普通」がわかってないので助かります。

.NET Framework 版の ASP.NET Web アプリの場合は定番のやり方があります。

WinForms や WPF での「定番のやり方」とまでは言えないかもしれませんが、同等なことは可能です。ネットを調べてみるとよく行われている方法のようです。

詳しくは以下の記事に書きましたので、興味があれば読んでください。

App.Debug.config と App.Relese.config を使った構成ファイル作成

なお、接続文字列など構成情報の暗号化の話ですが、これも .NET Framework 版の ASP.NET Web アプリの場合は定番のやり方があります。

web.configの暗号化

同様なことが App.config でもできるそうで、以下の Microsoft のドキュメントに書いてあります。（未検証・未確認です）

App.config の例

Release, Debugくらいのパターンならいいんですけど、顧客ごとに的な事も書いてるので、そうなってくるとプロジェクトファイルの構成が肥大化しそうという懸念はありますね。
暗号化については、参考になりました。

私の回答で紹介した記事は appsettings.json, appsettings.Production.json の 2 つだけの例ですが、さらに、例えば appsettings.User.json という名前の構成ファイルを追加することもできます。私の質問者さんへのお勧めはそちらです。