.Net Core FSI causes security exception when attempting to executing a PInvoke call about fsharp HOT 11 CLOSED

@patrickallensimpson We should ask the .NET Core team I think, can you open a .NET Core bug on this?

from fsharp.

I think this is caused by the following ifdef:

FSharp is not emitting actual PInvoke method for this that leads to this error.

The DefinePInvokeMethod method was added back to .NET Core. You should be able to delete this ifdef to fix this.

from fsharp.

@jkotas, Thanks mate.

from fsharp.

@jkotas

It looks like it will not be reintroduced until Dotnet Core 3.0

https://apisof.net/catalog/System.Reflection.Emit.TypeBuilder.DefinePInvokeMethod(String,String,String,MethodAttributes,CallingConventions,Type,Type(),Type(),Type(),Type()(),Type()(),CallingConvention,CharSet)

from fsharp.

Yes, you are right - this was fixed by dotnet/corefx#31096

from fsharp.

I've been going over the usage of the FX_RESHAPED_REFEMIT define in the ilreflect.fs and it looks like we might need a different set of defines or re-think API usage here. Are there specifications on what the absil is expecting as far as behavior regarding method usage from the Emit? I'm looking at some other cases related to the #defines that might be served by moving to other API's that both Core and Framework 4.5+ have in common. This is an area I'm particularly interested in and wouldn't mind helping to fix since I've got a significant amount of PInvoke scripts that I use with the Framework but want to start using Core going forward.

What are the framework expectations regarding F# moving forward do we need to keep supporting 2.0 and such?

To give you some background for why I want to get this fixed:

This whole issue came up when I started up a new Web project that I decided to target to CoreCLR. In the processes I wanted to use the SQLGeography implementation from Microsoft.SqlServer.Types but that doesn't work with CoreCLR. So I just re-implemented the Geography type using PInvoke direct to the underlying native DLL included in that project and in the process simplified the API for using with F#.

Everything was fine until I wanted to execute some code in in the REPL F# Interactive and I noticed that I get the security exception, unless I loaded the PInvoke calls from a DLL. (I hacked Visual Studio 2017 to use the CoreCLR fsi instead of the normal FSI, of course the debug feature doesn't work right since I'm spawning the CoreCLR fsi from another app).

I use the FSI all the time to test my code while writing it, it's better than unit tests honestly. I can write some code execute it right there and check that the results make sense. And if your doing things "Right" were the only dependencies in your function come from arguments its makes this strategy work really well. This is why I'm highly motivated to get this working for CoreCLR 3.0 at least. I'd move all my projects forward a version just for this feature.

Thanks,
-Patrick

from fsharp.

Are we using the System.Reflection.Emit API here because it's convenient or because the dynamic assemblies and modules allow us to keep adding types and functions on the fly with out having to deal with throwing away old versions of the assemblies as you're executing script code? Or is that just a happy coincidence. The reason I ask is would it be better to use Cecil to generate the Assemblies and then just load them on the fly as you go. I suppose that isn't really that much worse that what the FSI has to do now when types change. Though if you ask which assembly a type is coming from during reflection it might look weirder than it currently does.

from fsharp.

Considering that we now have F# 4.6 FSI as a preview dotnet command dotnet fsi inside the .Net Core 3.0 preview 3 shouldn't we fix that #define now? This is still an issue under 3.0.100-preview3-010431 running Microsoft (R) F# Interactive version 10.4.0 for F# 4.6

Thanks!

from fsharp.

@patrickallensimpson This should be a bug in Microsoft/visualfsharp I think - can you move this bug there and ask for @KevinRansom's input? thanks

from fsharp.

I've created a new issue over in Microsoft/visualfsharp as you requested. I'll contact @KevinRansom next.

from fsharp.

Thanks to the great work by @KevinRansom I'm closing this issue. Kevin, thanks again. This means I can move fully over to .NET Core now for all my scripts thanks again!

-Patrick

from fsharp.