DLL hellの理解

Visual Studioが.NET DLLへの依存関係を解決するメカニズムを理解することができません。いくつかの.csprojファイルでは、次のようにいくつかの依存関係があります。DLL hellの理解

<Reference Include="SomeDependency, 
        Version=SomeVersion, 
        Culture=neutral, 
        PublicKeyToken=SomePublicKeyToken, 
        processorArchitecture=MSIL"> 
    <SpecificVersion>False</SpecificVersion> 
    <HintPath>SomeHintPath</HintPath> 
</Reference>

しかし、HintPathは、無効なパスを指摘し、まだVisual Studioは、明らかどこかからDLLを取って、必要に応じてプロジェクトをビルドし、展開することができました。私の場合は、最終的な結果が望みどおり重要な問題ではありませんでしたが、最終的にどのメカニズムによって.NET DLLへの依存が解決されるのか分かりません。

Visual StudioプロジェクトをビルドするときにどのDLLが実際に参照されているかを知るにはどうすればよいですか？ dllの許可された場所は何ですか？あなたはすべてのロードされたアセンブリを決定するために、次のコードを使用し、また、それらのパスを確認することができます

出典

2016-06-24 Codor

これはあなたの質問に答えるん：（http://stackoverflow.com/questions/49972/in-what-order-are-locat ion-searched-to-load-referenced-dlls） –

@KevinWallisはい、ありがとう、参考になりました。しかし、2番目の考えでは、そうではありません。基本的に答えは「それは依存している」ということです。 – Codor

：

AppDomain ad = AppDomain.CurrentDomain; 
Assembly[] loadedAssemblies = ad.GetAssemblies(); 

Console.WriteLine("Here are the assemblies loaded in this appdomain\n"); 
foreach (Assembly a in loadedAssemblies) 
{ 
    Console.WriteLine(a.FullName); 
}

ポストから（Determine Loaded Assemblies）

そしてここでは、「どのようにランタイムのドキュメントですがアセンブリを検索する」

https://msdn.microsoft.com/en-us/library/yx7xezcf(v=vs.110).aspx

出典

2016-06-24 09:16:32

明らかにリンクが最も包括的な情報源であるため、明確な回答として受け入れられます。しかし、私は事がそれほど複雑ではないことを望んだ。 – Codor

@Codor yeahその静かな複合体 –