我正在尝试构建一个本机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/