オープンソースC＃プロジェクトのサードパーティライブラリ
ソースを管理するために（githubを介して）gitを使用して、オープンソースプロジェクトをゼロから始めます。プロジェクトはC＃で記述され、少なくとも2つの外部ライブラリに依存します（今後追加される可能性が高くなります）。ライブラリをどのように参照すればよいのかと思い、次のアイデアが思い浮かびました。
DLLとしてすべての外部ライブラリを含むプロジェクト内のフォルダー
これは、レポジトリにDLLファイルがあることを意味します。ソースではないため、これは悪いと思います。また、Visual Studio（または他のIDE）がライブラリのパスをどのように格納するのかわかりません。絶対パスを使用している場合、それは不可能です。Nugetを介して外部ライブラリを取得する
これは、ライブラリを整理するためのクリーンでナイスな方法ですが、必要なライブラリにnuget-packageがない場合はどうなりますか？ただ作成することはできませんか？私のリポジトリの一部として外部ライブラリのソースを保存する
愚かな考えのように聞こえます。ライブラリを更新するのは面倒です。どういうわけかgitを介して他のプロジェクトのリポジトリを参照します。
いいですね。自分でフォークして、状態を保持したり、コミットをポイントしたりできます。しかし、それは可能ですか？それは良い方法ですか？
tl; dr：オープンソースのC＃プロジェクトで外部ライブラリをどのように処理すればよいですか？
Nugetが使用できない場合、最もクリーンな方法は、必要なライブラリのソースコードを（ライブラリベンダーの）外部リポジトリから作業ディレクトリにプルするエクスポートスクリプトを提供することです。 SCC外部ライブラリのシステムがGitと異なる場合でも、これは機能します（コマンドラインインターフェイスがある限り）。編集：これは、ソースコードがない場合にも機能します。 SCCシステムで使用できます。たとえば、ftpやhttpのダウンロードと同じです。
もちろん、そのスクリプトをビルドプロセスに統合できます。 Visual Studioを使用するときは、言及したように、クラシックメイクファイル（NMakeを使用）を作成するか、外部ビルドが作業ディレクトリにないときにMSBuildを使用してそのスクリプトを呼び出すことができます。おそらく最も単純なアプローチは、そのスクリプトを事前構築イベントに追加することです。詳細は、残りの構築プロセスの編成方法に大きく依存します。
私はこれに反対票を投じるかもしれないと思うが、とにかくこれをそこに捨てたかった。
DLL自体を含めることは、本当に悪い考えではないと思います。
もちろん、text;ではありません。ただし、これは、ソースリポジトリ（画像など）に一般的に含まれている多くのアセットタイプに当てはまります。
もちろん、実際にそれらを比較することはできません。しかし、alsoがリポジトリに含まれることが多い他のコンパイル済みリソース（たとえば、縮小および圧縮されたJavaScriptファイル）についても同様です。
一般的に言えば、それらはそれほど大きくあるべきではありません（Mbや2を超えるDLLはめったに見ません）。そのため、リポジトリを肥大化し、クローンを作成するのが面倒になることも問題になりません。
NuGetが.NETの外部依存関係を管理するための事実上の標準であることを認識しています。ただし、使用するライブラリでNuGetパッケージを使用できない場合は、DLLを含めるのが最も苦痛のないアプローチであり、深刻なひどい欠点はありません。見る。
これは、これらのDLLを頻繁に更新しないことを前提としています（つまり、それらは成熟度に達したライブラリであり、多くても新しいバージョンを頻繁にリリースすることはありません）。この場合、DLLを含むフォルダーは、履歴の任意の時点での依存関係のスナップショットです。依存関係を更新するときは、DLLを更新するだけで済みます。
一方、これらが頻繁に変更されるライブラリである場合（たとえば、それらは、並行して作業しているownライブラリである場合）このプロジェクトで）、私は今言ったすべてを取り戻します。定数DLLの更新でGit履歴を乱雑にしたくありません。この場合、実際には Gitサブモジュール についてさらに学習するか、または Doc Brownのスクリプトのアイデア 。