我正在尝试构建一个本机nuget软件包,该软件包提供了有关调用约定的枢纽,为x86构建版本的DLL提供了cdecl和stdcall约定。 (大多数用户喜欢使用cdecl调用约定,但是由于各种原因,P / Invoke这个库的.NET用户更喜欢使用stdcall。)

我的.autopkg包含cdecl和stdcall枢轴:

nuget
{
    [nuspec omitted for brevity]

    files {
            [Win32,cdecl] {
                lib: build\x86-cdecl\Debug\git2-0_21_0.lib;
                bin: build\x86-cdecl\Debug\git2-0_21_0.dll;
                symbols: build\x86-cdecl\Debug\git2-0_21_0.pdb;
            }

            [Win32,stdcall] {
                lib: build\x86-stdcall\Debug\git2-0_21_0.lib;
                bin: build\x86-stdcall\Debug\git2-0_21_0.dll;
                symbols: build\x86-stdcall\Debug\git2-0_21_0.pdb;
            }
    };
}


使用本机nuget脚本构建.nupkg似乎成功,并且在标准C项目(具有cdecl调用约定的一个)中安装和使用nuget包成功。

但是,如果我创建一个新的C项目并将调用约定设置为stdcall并安装nuget包,则不会获得我的库的stdcall版本。而是安装了cdecl版本,但无法链接。

我乐观地认为nuget软件包管理器将检测到我项目的配置并使用适当的调用约定枢纽(就像它对处理器类型所做的那样),但这似乎没有发生。我也没有选择手动选择调用约定的选项。但是,autopkg配置中有一个关键点,这一事实使我认为我可以选择一个。

我如何利用这一优势?

最佳答案

据我所知,这是完全不可能的。不幸的是,同样不可能获得帮助。

遗憾的是,Nuget原生村是一个未经测试,几乎无法操作且完全不受支持的错失机会的荒原。唯一的答案就是根本不使用它。

关于nuget - native Nuget中的cdecl和stdcall调用约定,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/24331880/

10-17 01:22