4

アセンブリがホストされているコンテキスト(ASP.NET、Windows サービス、Windows アプリケーションなど)を知る必要があります。

私のアセンブリは、コンテキストに基づいてさまざまな関数を呼び出す必要があります。たとえば、その場所に関連するフォルダーを作成する必要がある場合、どちらの方法を使用するかを知りたいと思います:Path.GetFullPath(dirName)またはServer.MapPath(dirName).

4

1 に答える 1

5

他の開発者が使用する DLL を開発しているようです。また、環境を知らない、または制御できない場所に一時ファイルを作成しようとしているかのようにも聞こえます。

上記に該当する場合は、特に一時ファイルで使用するパスを含む構成ファイル (DLL と同じディレクトリにある) を作成することをお勧めします。(または、さらに良いことに、 Log4Net に似た App.Config または Web.Config で AppSettings を利用ます)

この構成ファイルがない場合は、 を使用できますが、ASP.NETGetTempPath()では失敗する可能性があります(他の状況では失敗する可能性があります)。

一時ファイルの作成に失敗した場合は、必要な情報をメモリに保存してみてください (たとえば、MemoryStreamを使用します)。

それが失敗した場合は、いつでもユーザーに構成ファイルを使用するように指示できます。


あなたの実際の質問に答えて、私はあなたがどのような種類のプロジェクトを扱っているかを確実に言う方法を知りません. .NET の優れた点は、その柔軟性です。理論的には、Web サーバー、デスクトップ アプリ、または Windows サービスとして実行できるコンソール アプリケーションを作成できます。3つすべてが1つになる可能性があります。

呼び出し元の実行可能ファイル(System.Windows はおそらくデスクトップを意味し、System.Web はおそらく ASP.NET を意味するなど) の参照アセンブリに基づいていつでも推測を試みることができますが、それにはエラーがつきものです。Web アセンブリを参照するデスクトップ アプリケーションをいくつか作成し、デスクトップ アセンブリを参照する Web サイトを作成しました。

しかし、構成ファイルにパスを入れると、コンテキストを知る必要がない場合があります... GetFullPath() または MapPath() を使用しなくても、必要な完全修飾パスが既にあります。

本当に区別する必要がある場合は、構成ファイルに設定を含めることができます。DLL のユーザーは、アセンブリが使用されている環境に合わせてアセンブリを構成できます。もし彼らが設定を間違えたら... まあ... あなたが設定を間違えるとほとんどのソフトウェアは誤動作します。それがその通りです。

または...さらに良い...開発中に不明な条件に基づいて特定のタスク(ファイルのパスを見つけるなど)の動作を変更する必要がある場合は、依存性注入をサポートするようにDLLをコーディングして、ユーザーを有効にすることができます必要に応じて適切な機能を提供します。

于 2013-05-03T19:49:12.167 に答える