blocks|key|2536231|text|框架中的候选API：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2536232|2536233|+有一个只在Core.|unordered-list-item|offset|length|2536234|System.Reflection.MetadataLoadContext+(source+on+GitHub，package+on+nuget.org)上可用的方法string+ResolveAssemblyToPath(AssemblyName+assemblyName)，它显然面临着完全相同的问题:能够从AssemblyName中检索Assembly，这显然需要从某个地方加载前者。|style|BOLD|CODE|2536235|2536236|该库的创建者通过要求程序员提供一个具有MetadataAssemblyResolver依赖项的MetadataLoadContext来解决这个问题。|2536237|虽然此库附带了单个具体实现(PathAssemblyResolver)，但它没有提供封装运行库的本机程序集探测/解析算法的实现。|2536238|框架外的其他库如何处理程序集解析？|2536239|2536240|Mono.Cecil使用它的IAssemblyResolver+abstraction对程序集解析进行建模，并且在BaseAssemblyResolver+class.|2536241|Roslyn中有一个基本实现，它有一个MetadataReferenceResolver+abstraction，它在RuntimeMetadataReferenceResolver+class中实现。|2536242|2536243|(我通过the+blog+post+"Referencing+system+assemblies+in+Roslyn+compilations"+by+Luís+Gonçalves和this+GitHub+post+by+@tmat.)了解到了这一点|2536244|一些特定于平台的指针|2536245|2536246|.NET核心：在.NET核心上，上述两个库似乎都依赖于AppContext中的TRUSTED_PLATFORM_ASSEMBLIES数据属性，该属性在"Write+a+custom+.NET+Core+host+to+control+the+.NET+runtime+from+your+native+code"中有说明。还有一个可用于probing.|2536247|.NET框架的APP_PATH数据属性：，用"How+the+Runtime+Locates+Assemblies"描述了程序集解析算法。我希望框架能用一个API公开这个算法(它没有)，但至少这个算法可以在这个information.|2536248|中重现。|2536249|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/dotnet/coreclr/blob/master/src/System.Private.CoreLib/src/System/Runtime/Loader/AssemblyDependencyResolver.cs|1|https://github.com/dotnet/corefx/tree/master/src/System.Reflection.MetadataLoadContext|2|https://www.nuget.org/packages/System.Reflection.MetadataLoadContext|3|https://github.com/dotnet/corefx/blob/master/src/System.Reflection.MetadataLoadContext/src/System/Reflection/MetadataAssemblyResolver.cs|4|https://github.com/dotnet/corefx/blob/master/src/System.Reflection.MetadataLoadContext/src/System/Reflection/PathAssemblyResolver.cs|5|https://github.com/jbevain/cecil/blob/1b79b96d29f1e8e9ba832191b1b42ea9cb750d20/Mono.Cecil/MetadataResolver.cs#L17-L20|6|https://github.com/jbevain/cecil/blob/master/Mono.Cecil/BaseAssemblyResolver.cs|7|https://github.com/dotnet/roslyn/blob/357fa7e9dc82e5c8c2ca49e3033362e90ac9f287/src/Compilers/Core/Portable/MetadataReference/MetadataReferenceResolver.cs|8|https://github.com/dotnet/roslyn/blob/357fa7e9dc82e5c8c2ca49e3033362e90ac9f287/src/Scripting/Core/Hosting/Resolvers/RuntimeMetadataReferenceResolver.cs|9|https://luisfsgoncalves.wordpress.com/2017/03/20/referencing-system-assemblies-in-roslyn-compilations/|10|https://github.com/dotnet/roslyn/issues/16846#issuecomment-276443112|11|https://docs.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting|12|https://docs.microsoft.com/en-us/dotnet/framework/deployment/how-the-runtime-locates-assemblies^0|0|0|0|1|0|0|0|11|2B|1J|4C|C|4R|8|13|G|1|1K|K|2|0|0|J|O|1B|J|J|O|3|0|E|K|E|K|4|0|0|0|0|A|E|H|1L|K|E|T|5|1L|Q|6|0|0|6|J|P|1N|W|J|11|7|1N|12|8|0|0|4|2E|9|2J|P|A|0|0|0|0|6|R|A|13|R|23|29|B|0|0|K|7|8|M|10|C|0|0^^$0|@$1|2|3|4|5|6|7|26|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|27|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|28|8|@]|9|@$F|29|G|2A|1|2B]]|A|$]]|$1|H|3|I|5|E|7|2C|8|@$F|2D|G|2E|J|K]|$F|2F|G|2G|J|L]|$F|2H|G|2I|J|L]|$F|2J|G|2K|J|L]]|9|@$F|2L|G|2M|1|2N]|$F|2O|G|2P|1|2Q]]|A|$]]|$1|M|3|-4|5|6|7|2R|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|2S|8|@$F|2T|G|2U|J|L]|$F|2V|G|2W|J|L]]|9|@$F|2X|G|2Y|1|2Z]]|A|$]]|$1|P|3|Q|5|6|7|30|8|@$F|31|G|32|J|L]]|9|@$F|33|G|34|1|35]]|A|$]]|$1|R|3|S|5|6|7|36|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|37|8|@]|9|@]|A|$]]|$1|U|3|V|5|E|7|38|8|@$F|39|G|3A|J|K]|$F|3B|G|3C|J|L]|$F|3D|G|3E|J|L]]|9|@$F|3F|G|3G|1|3H]|$F|3I|G|3J|1|3K]]|A|$]]|$1|W|3|X|5|E|7|3L|8|@$F|3M|G|3N|J|K]|$F|3O|G|3P|J|L]|$F|3Q|G|3R|J|L]]|9|@$F|3S|G|3T|1|3U]|$F|3V|G|3W|1|3X]]|A|$]]|$1|Y|3|-4|5|6|7|3Y|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|3Z|8|@]|9|@$F|40|G|41|1|42]|$F|43|G|44|1|45]]|A|$]]|$1|11|3|12|5|6|7|46|8|@]|9|@]|A|$]]|$1|13|3|-4|5|6|7|47|8|@]|9|@]|A|$]]|$1|14|3|15|5|E|7|48|8|@$F|49|G|4A|J|K]|$F|4B|G|4C|J|L]|$F|4D|G|4E|J|L]]|9|@$F|4F|G|4G|1|4H]]|A|$]]|$1|16|3|17|5|E|7|4I|8|@$F|4J|G|4K|J|K]|$F|4L|G|4M|J|L]]|9|@$F|4N|G|4O|1|4P]]|A|$]]|$1|18|3|19|5|6|7|4Q|8|@]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|4R|8|@]|9|@]|A|$]]]|1B|$1C|$5|1D|1E|1F|A|$1G|1H]]|1I|$5|1D|1E|1F|A|$1G|1J]]|1K|$5|1D|1E|1F|A|$1G|1L]]|1M|$5|1D|1E|1F|A|$1G|1N]]|1O|$5|1D|1E|1F|A|$1G|1P]]|1Q|$5|1D|1E|1F|A|$1G|1R]]|1S|$5|1D|1E|1F|A|$1G|1T]]|1U|$5|1D|1E|1F|A|$1G|1V]]|1W|$5|1D|1E|1F|A|$1G|1X]]|1Y|$5|1D|1E|1F|A|$1G|1Z]]|20|$5|1D|1E|1F|A|$1G|21]]|22|$5|1D|1E|1F|A|$1G|23]]|24|$5|1D|1E|1F|A|$1G|25]]]]

<h3>Candidate APIs in the framework:</h3>

<ul>
<li><a href="https://github.com/dotnet/coreclr/blob/master/src/System.Private.CoreLib/src/System/Runtime/Loader/AssemblyDependencyResolver.cs" rel="nofollow noreferrer"><code>AssemblyDependencyResolver</code> in System.Runtime.Loader</a> having a method <code>string ResolveAssemblyToPath(AssemblyName assemblyName)</code>, which is currently only available on .NET Core.</li>
<li>System.Reflection.MetadataLoadContext (<a href="https://github.com/dotnet/corefx/tree/master/src/System.Reflection.MetadataLoadContext" rel="nofollow noreferrer">source on GitHub</a>, <a href="https://www.nuget.org/packages/System.Reflection.MetadataLoadContext" rel="nofollow noreferrer">package on nuget.org</a>), which apparently faces the exact same problem: being able to retrieve an <code>Assembly</code> from an <code>AssemblyName</code>, which obviously requires loading the former from somewhere.

The creators of that library have externalized this problem by requiring the programmer to provide a <code>MetadataLoadContext</code> with a <a href="https://github.com/dotnet/corefx/blob/master/src/System.Reflection.MetadataLoadContext/src/System/Reflection/MetadataAssemblyResolver.cs" rel="nofollow noreferrer"><code>MetadataAssemblyResolver</code></a> dependency that does that work for it.

While this library comes with a single concrete implementation (<a href="https://github.com/dotnet/corefx/blob/master/src/System.Reflection.MetadataLoadContext/src/System/Reflection/PathAssemblyResolver.cs" rel="nofollow noreferrer"><code>PathAssemblyResolver</code></a>), it does not provide an implementation that encapsulates the runtime's native assembly probing/resolution algorithm.</li>
</ul>

<h3>How do other libraries outside the framework deal with assembly resolution?</h3>

<ul>
<li>Mono.Cecil models assembly resolution with its <a href="https://github.com/jbevain/cecil/blob/1b79b96d29f1e8e9ba832191b1b42ea9cb750d20/Mono.Cecil/MetadataResolver.cs#L17-L20" rel="nofollow noreferrer"><code>IAssemblyResolver</code> abstraction</a> and has a base implementation in the <a href="https://github.com/jbevain/cecil/blob/master/Mono.Cecil/BaseAssemblyResolver.cs" rel="nofollow noreferrer"><code>BaseAssemblyResolver</code> class</a>.</li>
<li>Roslyn has a <a href="https://github.com/dotnet/roslyn/blob/357fa7e9dc82e5c8c2ca49e3033362e90ac9f287/src/Compilers/Core/Portable/MetadataReference/MetadataReferenceResolver.cs" rel="nofollow noreferrer"><code>MetadataReferenceResolver</code> abstraction</a> which is implemented in e.g. the <a href="https://github.com/dotnet/roslyn/blob/357fa7e9dc82e5c8c2ca49e3033362e90ac9f287/src/Scripting/Core/Hosting/Resolvers/RuntimeMetadataReferenceResolver.cs" rel="nofollow noreferrer"><code>RuntimeMetadataReferenceResolver</code> class</a>.

(I found out about this via <a href="https://luisfsgoncalves.wordpress.com/2017/03/20/referencing-system-assemblies-in-roslyn-compilations/" rel="nofollow noreferrer">the blog post "Referencing system assemblies in Roslyn compilations" by Luís Gonçalves</a> and <a href="https://github.com/dotnet/roslyn/issues/16846#issuecomment-276443112" rel="nofollow noreferrer">this GitHub post by @tmat</a>.)</li>
</ul>

<h3>Some platform-specific pointers</h3>

<ul>
<li>.NET Core: On .NET Core, both of the above libraries appear to rely on the <code>TRUSTED_PLATFORM_ASSEMBLIES</code> data property in <code>AppContext</code>, which is documented in <a href="https://docs.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting" rel="nofollow noreferrer">"Write a custom .NET Core host to control the .NET runtime from your native code"</a>. There's also an <code>APP_PATH</code> data property that could be used for probing.</li>
<li>.NET Framework: The assembly resolution algorithm is described in <a href="https://docs.microsoft.com/en-us/dotnet/framework/deployment/how-the-runtime-locates-assemblies" rel="nofollow noreferrer">"How the Runtime Locates Assemblies"</a>. I was hoping that the framework would expose that algorithm with an API (it doesn't), but at least the algorithm can be reproduced given this information.</li>
</ul>

Is there any public API in the .NET Framework, in .NET Core, or in .NET Standard that can resolve a <code>System.Reflection.AssemblyName</code> to a file path of the assembly file that would be loaded, without actually loading that assembly?

The best I've currently got is this:

<pre class="lang-cs prettyprint-override"><code>string ResolveToPath(AssemblyName name) =&gt; Assembly.ReflectionOnlyLoad(name).Location;
</code></pre>

But that still causes the assembly to be loaded (albeit only into the reflection-only context).

(Assume that I do not want to change the way how the runtime locates assemblies. I'm asking this for use in a library, where I am not free to inspect application configuration files, defining an <code>AppDomain.AssemblyResolve</code> handler, etc.)

How can I resolve an AssemblyName to an assembly file path without loading that assembly?

在.NET框架、.NET核心或.NET标准中是否有任何公共API可以将System.Reflection.AssemblyName解析为将要加载的程序集文件的文件路径，而无需实际加载该程序集？我目前得到的最好的结果是：string ResolveToPath(AssemblyName name) => Assembly...

问如何在不加载程序集的情况下将AssemblyName解析为程序集文件路径？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何在不加载程序集的情况下将AssemblyName解析为程序集文件路径？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何在不加载程序集的情况下将AssemblyName解析为程序集文件路径？
EN