-
-
Notifications
You must be signed in to change notification settings - Fork 639
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NullReferenceException when trying to resolve ModuleReference members #725
Comments
Hey, thanks for filing this and investigating. Could you zip the binaries and attach them to the issue? Thank you! |
Or better yet, start a PR with a failing test! |
Failed test added in #730 |
Thank you, I'll have a look! (Using netmodules is not a good idea they're just a source of pain on earth) |
Yeah, i'm aware of it. Easily the much flawed design choice of the ECMA Spec, but I'm developing tools tools which need to handle the full ECMA and that sadly includes multi-module assemblies and shared modules. |
Fixed by #730 |
The testcode i used is copied from https://docs.microsoft.com/en-us/dotnet/framework/app-domains/build-multifile-assembly
Scenario:
I compiled the tutorial from the link above.
This yields the following files:
myAssembly.exe
Client.netmodule
andStringer.netmodule
I'm trying to resolve as many Reference members into their matching Definitions (e.g. TypeReference --> TypeDefinition)
Error Description:
i'm running the following code:
The line
var methodTypeDef = methodTypeRef.Resolve();
fails with an NRE becuase:methodTypeRef
's module is 'Client.netmodule'null
). According to ECMA this is valid.var modules = type.Module.Assembly.Modules;
As you see it assumes, a ModuleDefinition always has an Assembly assigned to it.Solutions
I see a couple of solutions here.
a. return
null
in that case, indicating that it was impossible to find a proper TypeDefinitionb. Have some heuristic-based logic which tries to find a ModuleDefinition which matches the ModuleReferenc's name. Either lookup the assembly resolver's lookup directories for such a module or try on some cached ModuleDefinitions. Return null when no module was found or no module contained to TypeDefinition of the searched TypeReference. Or return the TypeDefinition if found. I think it should be noted however that this approach might return a wrong TypeDefinition if the wrong module matched.
There are probably more and smarter solutions but I think that's up to you to decide @jbevain
The text was updated successfully, but these errors were encountered: