在Visual Studio中使用x64库的F#类型提供程序 [英] F# Type Provider that uses x64 libraries in Visual Studio

问题描述

下面的我的类型提供程序使用一些本机x64库.我用 anyCpu x64标志编译了类型提供程序库.

My type provider underneath uses some native x64 libraries. I compiled my type provider library with anyCpu x64 flag.

现在，当我尝试从另一个项目中加载类型提供程序时，Visual Studio中的IntelliSense给我以下错误:

Now, when I try to load my type provider from another project IntelliSense in Visual Studio gives me following error:

类型提供者"...我的类型提供者..."报告了一个错误: 试图加载格式不正确的程序(异常 从HRESULT:0x8007000B

The type provider '...my type provider...' reported an error: An attempt was made to load a program with an incorrect format (Exception from HRESULT: 0x8007000B

为了明确起见，我只是在Visual Studio中注册了类型提供程序，却在不运行任何代码的情况下得到了此错误.

Just to make it clear, I get this error without running any code, just by registering the type provider in visual studio.

当我尝试从32位fsi加载时，出现相同的错误.但是，当我尝试使用fsianycpu或64位fsi时，它可以正常工作.我在fsi中获得了类型和自动完成功能.

When I try to load it from 32 bit fsi I get the same error. But when I try with fsianycpu or 64 bit fsi it works fine. I get my types and auto-completion in fsi.

我想发生这种情况是因为VS本身就是x86，IntelliSense/静态代码分析也是x86，在某些时候，他们试图加载依赖x86 lib的类型提供程序代码，并且弹出错误.

I guess that this happens because VS it self is x86, IntelliSense/static code analysis are also x86, at some point they try to load type provider code that relies on x86 lib and errors pop up.

不幸的是，该库仅支持x64.

Unfortunately that library only supports x64.

有什么办法可以使它们一起工作吗?

Is there any way to make this work together?

推荐答案

如果您的提供程序使用本机64位库，则不应将其编译为AnyCPU(除非您可以提供32位回退).绝对不能在32位计算机上运行(或在Visual Studio的32位进程中运行).

If your provider uses native 64 bit libraries then it shouldn't be compiled as AnyCPU (unless you can provide a 32 bit fallback). Definitely it can't run on a 32 bit machine (or inside a 32 bit process as Visual Studio).

一种可能的解决方法是在32位进程中调用代码时提供一种后备托管方法(甚至是空的存根).例如:

One possible workaround is to provide a fallback managed method (or even an empty stub) when your code is called within a 32 bit process. For example:

static class NativeInterop {
    [DllImport("My64BitLibrary.dll", EntryPoint = "DoStuff")]
    private static int DoStuff64(int value);

    public static int DoStuff(int value) {
        if (Environment.Is64BitProcess)
            return DoStuff64(value);

        // This is a 32 bit process, I just return a dummy value
        // for Visual Studio integration (if applicable)
        return 0;
    }
}

您的代码将不会调用直接导入的DoStuff()函数，而是会调用托管包装程序，该包装程序将在64位进程上将调用重定向到本机函数，并在其他程序上执行其他 32位环境.如果在JIT编译此方法时(而不是在有效地调用它们时)加载依赖项，则可能需要(这是一个未经测试的解决方案)添加第二层间接访问.

Your code won't call directly imported DoStuff() function, instead it'll call a managed wrapper that will redirect call to native function on 64 bit processes and it'll perform something else on 32 bit environment. You may need (this is an untested solution) to add a second level of indirection if dependencies will be loaded when JIT compiles this method (and not when effectively they're called).

我想这不可能在所有地方都应用，这取决于调用64位代码的位置以及是否可以提供有效的存根.如果您不能满足此条件，那么您就没有机会将64位库(如果编译为AnyCPU则无关紧要)集成到32位进程中.

I suppose this can't be applied everywhere, it depends on where you call 64 bit code and if you can provide a working stub. If you can't satisfy this condition then you don't have chances to integrate a 64 bit library (it doesn't matter if compiled as AnyCPU) into a 32 bit process.

针对32位进程的替代方法(以防您无法提供C#实现或某些伪造的实现)可能是将平台特定的代码移至外部服务(例如用于IPC的WCF服务).该进程将始终为64位，但是您的类型提供程序(因为它不会直接依赖于本机库)可以编译为AnyCPU，并且可以在32位进程中正常运行.您要支付的价格是IPC，并且复杂度大大增加.

An alternative approach (in case you can't manage to provide a C# implementation or some fake one) for 32 bit processes could be to move your platform specific code to an external service (for example a WCF service used for IPC). That process will always be 64 bit but your type provider (because it won't have any direct dependency to a native library) can be compiled as AnyCPU and it'll run fine inside a 32 bit process. The price you'll pay is IPC and a big increment of complexity.

这篇关于在Visual Studio中使用x64库的F#类型提供程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！