0

状況は非常に複雑です（そして私の英語は非常に基本的です）が、説明してみましょう：

外部 dll からメソッドを呼び出す Asp.net Web サービスを開発しています。

この外部 dll は、他の .net dll から何らかのメソッドを呼び出します。

したがって、次のようになります。

Asp.net WS ----> External.dll ----> other.NEt.Dll(---> other .netdll)

外部 dll はパス (初期化メソッドで指定) を使用して内部参照を解決することを知っておく必要があります。

結論として、External.dll への参照が追加された Web アプリケーションと、external.dll に必要なすべての .net dll でいっぱいの完全に信頼されたパス ( c:\EXTERNAL ) があります。

周りを見回すと、このコードを application_START に追加することがわかりました:

Dim path As String = String.Concat(System.Environment.GetEnvironmentVariable("PATH"), ";", "c:\EXTERNAL)
    System.Environment.SetEnvironmentVariable("PATH", path, EnvironmentVariableTarget.Machine)

これにより、c:\EXTERNAL がグローバル環境 PATH に追加されます。

この構成を Visual Studio 開発サーバーから実行すると、エラーは発生せず、すべて正常に動作します。

ローカル IIS サーバーでアプリケーションを公開すると、さまざまなエラーが発生します。最初の結果は次のようになります。

Failure reading <Myobject> control of <(static)> type
Unable to create <myobject> object (<C:\(WRONGPATH)\needed.net.dll> assembly)

これを解決するために、必要な .net dll を wwwroot のアプリケーションの /bin に追加しようとしましたが、結果は次のようになります。

Failure reading <MyType> control of <Myobject> type
Error returned by .NET Framework: 
System.ArgumentException: Un oggetto di tipo 'ComNet.BaseControl.LoginDisplayLayout' non può essere convertito nel tipo 'ComNet.BaseControl.LoginDisplayLayout'.
   in System.RuntimeType.CheckValue(Object value, Binder binder, CultureInfo culture, BindingFlags invokeAttr)
   in System.Reflection.MethodBase.CheckArguments(Object[] parameters, Binder binder, BindingFlags invokeAttr, CultureInfo culture, Signature sig)
   in System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
   in System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   in System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, BindingFlags invokeAttr, Binder binder, Object[] index, CultureInfo culture)
   in System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, Object[] index)
   in CDotNetType.bSetProperty(CDotNetType* , Object gcrObj, SByte* pszNom, CSLevel* pclPile, Int32 nDimension, Int32* pnTabDimension, STOperationDotNet* pstOperation)

今回は、同じ dll をロードしているように見えますが、別の場所から競合が発生しています。

これですべてです。この dll 地獄を説明するのは難しいですが、基本的には、Visual Studio 開発サーバーでアプリケーションが正常に動作するときに何が起こっているかを再現したいと考えています。また、IIS は再起動せずに追加された PATH を解決しないことも読んだので、手動で c:\external を PATH に追加して再起動しようとしましたが、同じエラーが表示されます。

読んでくれてありがとう、誰かが助けてくれることを願っています。

(文法やスペルミスでごめんなさい! (私はイタリア人です..))

ニコラ

4

1 に答える 1

1

すべての外部 .NET dll を Web サイトの bin ディレクトリにドロップしてみてください。

Visual Studio で参照を別のライブラリまたはプロジェクトに追加すると、通常、DLL がそのプロジェクトから Web サイトの BIN ディレクトリにコピーされますが、そのプロジェクトが依存する DLL ファイルを常に取得するとは限りません。

したがって、次の場合: yourwebsite.dll --> helper.dll --> helperComponent.dll --> widget.dll (ここで --> は参照)、helper.dll のみをビルドすると、yourwebsite の横の bin ディレクトリに配置されます。 dll. 通常、それらすべてを同じ場所に配置する必要があります。そうすれば、パスやそのようなものについて心配する必要はありません。

または、これらのアセンブリすべてに厳密な名前が付けられている場合は、gacutil を使用してそれらをグローバル アセンブリ キャッシュに追加し、ファイルではなく識別子で参照することができます。

これは、プロジェクトの組織についての非常に良い読み物でした。「ローカルにコピー」のセクションはこれに関係しています。ビルド後のイベントで xcopy をセットアップして、これらの第 2 および第 3 レベルの参照をソリューション ファイルの下の bin ディレクトリに配置できます。

http://www.simple-talk.com/dotnet/.net-framework/partitioning-your-code-base-through-.net-assemblies-and-visual-studio-projects/

于 2011-02-19T22:14:05.467 に答える