Closed patrickallensimpson closed 5 years ago
I'd fix this myself but I need guidance on the appropriate way we should special case this for .Net Core 3 builds in the project. My understanding of the issue is that when compiling under .Net Core 3 we simply need to remove the #if and keep the containing code that surrounds lines here: https://github.com/Microsoft/visualfsharp/blob/5cf2d974241efb1bfa525cb636d392960ce1f0b7/src/absil/ilreflect.fs#L1515-L1541
Thanks, -Patrick
@patrickallensimpson It looks like @KevinRansom is already working on it in https://github.com/Microsoft/visualfsharp/pull/6542
I just commented on that pull request, I'm very happy about this new fix!
-Patrick
Don Syme asked me to move this bug from fsharp/fsharp issue 886 to here. I describe a failure mode where F# interactive running under .Net Core won't generate correct PInvoke calls in your scripts. It was determined by @jkotas here and @KevinRansom here that the issue was related to originally missing functionality in .Net Core's Reflection.Emit.TypeBuilder that is now present in .Net Core 3.0.
Considering that we now have F# 4.6 FSI as a preview dotnet command dotnet fsi inside the .Net Core 3.0 preview 3 this needs to get fixed otherwise any existing scripts using PInvoke will not work reporting a rather esoteric error message. This is still an issue under 3.0.100-preview3-010431 running Microsoft (R) F# Interactive version 10.4.0 for F# 4.6
Here is the original issue:
When running the .Net Core version of the F# Interactive Service we get a security exception on any invocation of a PInvoke call that was generated in the script itself.
Start .Net Core version of fsi.exe
Enter the following script:
On .Net Framework fsi this will execute and return the last error this is just the simplest test case I could think of.
I investigated and this is due to a check in ecall.cpp:346 inside the coreclr project.
They perform a check on the incoming module to see if it is a system module (My guess is this means it's loaded from disk?) In any case if it is not then they throw this error. This means any scripts that were using PInvoke to call win32 services or other C api's CAN NOT work on the CoreCLR fsi version.
I've confirmed this is the case with .Net Core 2.0, 2.1, 2.2 and 3.0 preview at the exact same line number.
It there something that can be done to let the CoreCLR system know that the dynamically generated FSI assemblies are ok as far as this check is concerned?
Thanks, -Patrick Simpson
DotNetFSISecurityFailureTest.zip