3

このあたりでビジネス プロセスを実行するために、多数のコンソール アプリケーションを構築しています。ほとんどは同じ性質のもので、アプリケーション サーバーにデプロイされ、ソース データベースにアクセスし、ステージングされたデータをターゲット DB に配置します。一部のファイル共有などにアクセスします。

その設定を考えると、私は同じログ パッケージ (log4net) を何度も使用するのが好きです。各 app.config に構成を保持します。しかし、私は、log4net の DLL を私と一緒に「持ち歩いている」ことに気付き続けています。

つまり、新しいプロジェクトを開始するときに、log4net への参照を作成する必要があるということです。log4net を GAC に入れたり、開発マシンに完全にインストールしたりしないことにしました。代わりに、ダウンロード パッケージ全体をディレクトリに格納し、通常は次のようにします。

DLL を取得して、コンソール アプリ プロジェクトに /lib ディレクトリを作成し、それを参照します。

この縫い目の利点は、DLL をローカルにコピーするため、正しいバージョンがあることを常に知っていることです。私もプロジェクトでそれをチェックインします。

しかし、欠点は、多くの場合、同じ DLL が存在する /lib ディレクトリを持つ大量のプロジェクトになってしまうことです。

私は何を間違っていますか？ソリューション/プロジェクト開発の背後にあるアイデア全体を見逃しているだけですか? 私のプロジェクトはすべてばらばらで、すべてを 1 つのソリューションにまとめたくないと感じています。

他の人がこの問題にどのように取り組んでいるかを知りたいです。

4

2 に答える 2

1

ilmergeを見たことがありますか？log4net.dll を実行可能ファイルにマージして、スタンドアロンにすることができるはずです。

使用例 (ビルド後のステップとして):

"$(SolutionDir)Lib\ilmerge" /targetplatform:v4,C:\Windows\Microsoft.NET\Framework\v4.0.30319 /out:$(ProjectDir)bin\Merged\MyExe.exe MyExe.exe log4net.net40.dll
于 2013-08-16T14:26:37.183 に答える
1

DLL を格納するためだけにすべてのコンソール プロジェクトに lib フォルダーを作成することは、マシン上にローカルに存在することを保証することを除けば、実際の目的には何の役にも立ちません。編成について心配している場合は、事態がさら​​に悪化する可能性があります。これは、開発マシンとアプリ サーバーに DLL の複数の重複コピーがあり、それらはすべて同じであるためです。

そして、log4net がアップデートをリリースするとどうなるでしょうか? 次に、log4net、再構築、および再展開のために、すべての独立した/物理的なコピーと参照を更新する必要があります。また、log4net 以外の複数のサードパーティ DLL を使用すると、問題はさらに悪化します。

そうは言っても、サードパーティの参照を追加すると、デフォルトでは、コンパイルするたびにローカルの DLL がビルド フォルダーにコピーされ、コンソール プログラムはそのローカル コピーを使用します。これを確認するには、自分で追加しCopy Local、参照のプロパティを表示します (true に設定する必要があります)。したがって、基本的には、VS が既に行っている追加の作業を行ってきました。

私なら、すべてのサードパーティ DLL を開発マシンの中央ディレクトリに格納し、コンソール アプリケーションを作成するたびにそれらへの参照を追加するだけです。展開するたびに、DLL のローカル コピーが一緒に運ばれます。新しいサード パーティの dll リリースがある場合でも、各ソリューションの各参照を更新し、再構築して、アプリ サーバーにアプリを再デプロイする必要があります。ただし、違いは、更新するのは 1 つだけです。物理コピー！

于 2013-08-16T14:19:34.693 に答える