-
Notifications
You must be signed in to change notification settings - Fork 123
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
Crash when using the assembly-resolve event and the checker from within a fsi session. #466
Comments
This issue might be another instance of where mono is just more eager in loading assemblies than windows is. One obvious workaround is to load the affected assemblies before the AssemblyResolve event is even triggered (but I don't think we should or even can add that to FSF because we don't know which assemblies will be problematic). The problem with this is that FCS doesn't show the name of the missing reference (the exception is not useful at all), so it's not trivial to figure out which assemblies need to be loaded beforehand... Note also that in FSF we only try to fetch metadata from assemblies, so it is not obvious why FCS tries/needs to load those assemblies at all (while in this repro-code I call a constructor of the assembly via reflection, that code is not even executed). Maybe related to some special handling of type-providers (which the stacktraces and error messages would support)? Trying to provide further info for example more verbose logging and a stacktrace where FCS tries to load the assembly. Maybe with this info somebody can help me understand what's going on here (This already took way too much time to track down ;) ):
Linux:
Windows:
The other threads don't seem to be doing anything useful:
|
So, if the type provider needs to be created in order to create the type information, would it make sense (in order to work-around this scenario) to find all references of the provider and load them before we try to initialize a new instance (We should know all paths because they should be given via "-r" arguments, correct)? Maybe only activate this code when running on linux? However, I think this bug can be triggered on windows as well as soon as the constructor of the type-provider is using a referenced assembly... |
It seems that FSharp.Compiler.Service crashes with a quite weird error message if you use the checker and the AssemblyResolve event from within a fsi-session.
The code to reproduce this can be found here: matthid@548894a
The problem can only be reproduced on linux/mono:
I noticed the following:
fsharpi
for some reason:We basically need this when executing FSharp.Formatting from within a FAKE script.
I think this might be a known issue/limitation because I read somewhere that there are limitations because of the globally installed event handler, but I currently cannot find it anywhere. But why is
fsharpi
working and can we somehow do the same with FCS?The text was updated successfully, but these errors were encountered: