現在、複数のクライアントに使用するWeb APIプロジェクト/フレームワークを持つクライアントで動作します。コードの98％が再利用されますが、新しいクライアントごとにリポジトリがコピー＆ペーストされます。コピーして貼り付けた後、実際に変更されるのはWeb.Configsと今やOOTB APIへのいくつかの拡張です。例えば。 api api/rockets/にカスタムモジュールをスタンドアップするか、既存のAPIを拡張して新しいメソッドを追加します（&アクション）。C＃Web APIプロジェクトの共有方法
私はこれをネットで取り除く方法を見つけることができません。現在私はフォークを使ってgit経由でこれを解決できると思っていますが、これを解決する方法があれば疑問に思っていました。既存のWebプロジェクトを拡張する方法はありますか？
gitのアプローチはそれを行う方法の1つですが、おそらくNugetパッケージのために行くでしょう。
すべてのソリューションに共通するもの、さらにはリソースを抽出してパッケージを作成します。 パッケージのバージョン管理などを活用してください。バグがある場合は、パッケージに修正し、単にプロジェクトのナゲットアップデートを実行するだけです。あるいは、依存関係の変更があったときに再構築および更新するための継続的な統合をセットアップするだけです。
1つのオプションは、「エリア」を使用する複数のクライアントに対して1つのWebプロジェクトを作成することです。そうすれば、それぞれを個別にオン/オフすることができます。
また、一般的なビジネスロジックをNugetパッケージに入れて、顧客ごとにインポートすることもできます。しかし、毎回ビジネスロジックをフォークするのは本当に悪い考えです。あなたが欠陥を見つけたらどうなりますか？あなたはN個のプロジェクトで同じ問題を解決しなければなりません。
envs sepを維持するための厳しいセキュリティ要件があります。私たちのための問題は、私たちが実際にそれを拡張してカスタマイズしたいblを捨てるだけでは簡単ではありません。私はそれを拡張可能にするために.netでどのように構造化するかを理解できません。 – Nix
私はこれをやりたがっていますが、startup.cs（owin stuff）、app_startなどの基本Webプロジェクトにあるすべてのものはどうですか？ – Nix
Nugetの優れた機能の1つは、設定やソースコードを含めてから変換を行うことができるということです。 https://docs.nuget.org/Create/Configuration-File-and-Source-Code-Transformations。とにかく、トレードオフは複雑です。銀色の弾丸がないので、私は常にそれをできるだけシンプルに保つように勧めます。 Nugetの機能をあまりにも深く掘り下げて動作させる必要がある場合は、おそらく間違った方向に向かいます。その場合、gitでのフォークアプローチはそれほど悪くないかもしれません。 –