ライブラリと共有プロジェクトのどちらを選択するのですか？
他の開発者と一緒に.NET Core 2.0マイクロサービスのセットに取り組んでいます。 here の説明に従って、独自のカスタムロギングを追加するコードを記述しました。私のロガーは、ログメッセージを外部のクラウドベースのログシステム（コマンドラインではない）に送信します。私は今、コードを配置する場所を見つけようとしています。ログはすべてのマイクロサービスに必要です。
1つのオプションはライブラリです。このライブラリは、すべてのマイクロサービスから呼び出すことができます。これは明白な解決策のようです。ライブラリは一度コンパイルする必要があり、どこでも使用できます。
別のオプションは、共有プロジェクトです。各プロジェクトの一部としてコンパイルされます。これはあまり明確な解決策ではないように見えるかもしれません。コードは常に各マイクロサービスの一部としてコンパイルする必要があります。ただし、このソリューションには明らかな利点がいくつかあります。
- 共有プロジェクトには参照がありません。したがって、使用された参照は、マイクロサービス内の使用された参照とバージョンの競合を引き起こしません。それらは存在しません。
- 共有プロジェクトは、将来の.NET Coreバージョンの一部としてコンパイルすることもできます（可能性が高い）。共有プロジェクトには.NET Coreバージョン自体がないため、間違った選択をすることはできません。
どのように選択すればよいですか？それが将来の証明になるための最良のソリューションは何ですか？
私の見解では、共有プロジェクトの良いケースはめったにありません。
主な理由は、バージョン管理と変更管理です。ソースコードを再コンパイルすると、厳密に言うと新しいバージョンになります。最近のビルドサーバーとCIでは、それほど問題ではありません。しかし、開発者のマシンでビルドして本番環境にコピーするのが普通のことだったときを覚えている人もいます。さまざまなマシンとコンパイラーのセットアップが結果のバイナリーを変更するため、コードをコンパイルしたwhich devは心配する必要がありました。
ライブラリをコンパイルしてバージョン管理する必要があります。次に、nugetなどのパッケージマネージャーを介して他のプロジェクトでそのバージョン付きのバイナリを使用します。
.net標準の新しいバージョンが出たら、そのバージョンに対してライブラリを更新して再コンパイルできます。また、各ターゲットに1つずつ、2つのバージョンのライブラリがあります。
ライブラリのバグを修正した場合は、新しいバージョンを再度公開し、更新が必要な他のプロジェクトを確認できます。