Change GacFileResolver.IsAvailable to check a type from System.Core #46493
Conversation
| @@ -20,7 +20,9 @@ internal sealed class GacFileResolver : IEquatable<GacFileResolver> | |||
| /// <summary> | |||
| /// Returns true if GAC is available on the current platform. | |||
| /// </summary> | |||
| public static bool IsAvailable => typeof(object).Assembly.GlobalAssemblyCache; | |||
| public static bool IsAvailable | |||
| // Check a type from System.Core since Mono doesn't load mscorlib from the GAC. | |||
There was a problem hiding this comment.
This type is actually in System.Linq.dll in certain distributions. Part of the problem is that it's hard to depend on the assembly location of a given type because the runtime team moves them around.
Think a better approach would be to pick a type like this then assert it's in a different assembly than object. That way we catch ourselves if this ever gets invalidated.
There was a problem hiding this comment.
@jaredpar Any idea why mscorlib is not loaded from GAC?
There was a problem hiding this comment.
Hmm.. I guess what I'm really looking for is an Assembly that will always load from the GAC for platforms that support a GAC and a repeatable method for locating the Assembly. mscorlib does not satisfy that requirement for at least some versions of Mono.
Could look through AppDomain.GetAssemblies() to see if any were loaded from the GAC and cache the result.
There was a problem hiding this comment.
That doesn't seem like it would be reliable in the same way checking a specific one isn't. Maybe we could detect presence of GAC on Mono in a different way.
There was a problem hiding this comment.
Any idea why mscorlib is not loaded from GAC?
On mono? No idea.
Maybe we could detect presence of GAC on Mono in a different way.
Is there a case on Mono where the GAC isn't used?
There was a problem hiding this comment.
Yes, on Mono. The current code works fine on .NET Framework.
Is there a case on Mono where the GAC isn't used?
Apparently there is - @JoeRobich just found out.
Maybe @marek-safar knows?
There was a problem hiding this comment.
For Mono GAC is optional (there is also option to have multiple GACs). The most reliable way is probably check GAC location calling into https://github.com/mono/mono/blob/master/mcs/class/corlib/System/Environment.cs#L975 and then compare the paths/MVIDs/what-ever-is-appropriate
There was a problem hiding this comment.
How does the runtime know to look (or not) into GAC? Does it always look there and if it's not found it looks somewhere else? Where else?
There was a problem hiding this comment.
There is whole assembly loader logic with tons of rules and config options (it's similar to FW assembly binder). There is no documentation covering all the possible combinations and the behaviour though. You'd need to read the code.
There was a problem hiding this comment.
@JoeRobich I think the best thing we can do here to return true if we run on Mono: Type.GetType("Mono.Runtime") != null http://sourceroslyn.io/#Microsoft.CodeAnalysis.Scripting/Hosting/Resolvers/MonoGlobalAssemblyCache.cs,160 will get called if this property returns true.
|
@tmat Updated to check for Mono. |
ghost
added this to the 
I've been looking at unit test failure on Mono platforms in an OmniSharp-Roslyn PR (OmniSharp/omnisharp-roslyn#1867) where I update to a more recent build of Roslyn.
It is unable to resolve "System.Xml" with the RuntimeMetadataReferenceResolver. This is because the
gacFileResolveris being set tonulland theAppContext.GetData("TRUSTED_PLATFORM_ASSEMBLIES")is also coming backnull.For the
objecttype which is in mscorlib, I am seeing mscorlib loaded from "/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/4.5/mscorlib.dll" and returnsfalseforAssembly.GlobalAssemblyCache.However, the
Enumerabletype from System.Core loads from "/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/gac/System.Core/4.0.0.0__b77a5c561934e089/System.Core.dll" and returnstrueforAssembly.GlobalAssemblyCache.