jbevain
Framework64 returned for 32-bit images
A project I'm working on walks the references of a given assembly and I'm curious how the resolver resolves some of the framework/GAC paths.
For example say I have a 32-bit assembly (explicitly set to x86) on 64-bit Windows. If I analyze the references I have mscorlib, System.Windows.Forms etc as expected. Now System.Windows.Forms points to a file image under GAC_MSIL which is fair enough, but mscorlib is under Framework64.
Surely that's wrong? Shouldn't it be Framework as it's a pure 32-bit image?
Actually looking at the BaseAssemblyResolver it looks like you base this on the path of the assembly you resolve object to and only in the case of mscorlib, so i'm pondering just patching the path to the 32-bit variant in this instance.
2 thoughts:
- You can always provide your own resolver to workaround any issue the base one might have.
- In that case I think it might makes sense to support that scenario in the BaseAssemblyResolver.
Care to provide a PR?
Out of curiousity I looked at ILSpy and on the surface it seemed to be working correctly, it'd return GAC_32\...\mscorlib.dll for my x86 binary.
Looking at their code it seems they use a variant of your GACInterop that resolves AssemblyNameReference to a GAC entry.
However digging deeper there's an issue and it affects the Cecil code as well. Basically it's a first-wins scenario so it reaches GAC_32 before GAC_64. This means if I flip my binary x64 it would still return the GAC_32 file name (assuming the GAC'd assembly exists in both).
I'm wondering if I should add a flags enum to ReaderParameters that can toggle the relevant GAC paths on or off then it can be configured as part of the resolver. Default to whatever it currently is. I know when loading a binary what platform they're targeting so can toggle the flags accordingly.
I'd then need to modify GetCorlib to choose the GAC version first, then fall back on other methods but mscorlib should always be in the GAC. I don't think you should rely on for example typeof(object).Module.FullyQualifiedName as that's always going to be based around whatever platform the resolver is running on and not the base assembly being read.
I'll have a play anyhow and submit a PR if I get it working.