我们有两个版本的托管C++程序集,一个用于x86,另一个用于x64.此程序集由符合AnyCPU的.net应用程序调用.我们正在通过文件复制安装部署我们的代码,并希望继续这样做.
当应用程序动态选择其处理器体系结构时,是否可以使用并排程序集清单分别加载x86或x64程序集？或者是否有另一种方法可以在文件复制部署中完成此操作(例如,不使用GAC)？
这是我的问题.我在C#中包装一个C dll.为此,我首先编写了一个C++/CLI包装器.本机C库链接到C++/CLI包装器.(C++/cli项目中的链接器属性).
以下是它现在的组织方式: - 本机C .lib:x86和64bit.
我的问题来自于我需要C#来定位"任何CPU".但是此选项在C++/CLI中不可用,因为它直接编译为本机代码.
我想解决这个问题的方法是: - 在x86中编译C++/CLI包装器,然后更改配置并编译为64位.当它编译时,我想告诉它基于平台采取哪个dll.即:如果在64位编译,链接64位本机C dll,否则如果x86,链接x86本机C. - 完成后,我应该能够在我的C#平台中拥有任何CPU目标.在这里,我将不再引用我的C++/CLI包装器项目,而是基于目标平台引用所需的dll.
我的问题是:
让我补充一点,C#项目是一个由x86或x64客户端使用的CLASS LIBRARY.
我希望我的问题很清楚.任何帮助将不胜感激!
UPDATE基于:.NET项目中的条件引用,有可能摆脱警告吗？...
所以现在我使用条件编辑我的.csproj文件来引用dll,如下所示:
<ItemGroup>
<Reference Include="AlibCppWrapper, Version=1.0.4303.21410, Culture=neutral, PublicKeyToken=c0c17a53adc44091, processorArchitecture=AMD64"
Condition="$(Platform) == 'x64'">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\x64\Debug\AlibCppWrapper.dll</HintPath>
</Reference>
<Reference Include="AlibCppWrapper, Version=1.0.4303.21410, Culture=neutral, PublicKeyToken=c0c17a53adc44091, processorArchitecture=x86"
Condition="$(Platform) == 'x86'">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\Debug\AlibCppWrapper.dll</HintPath>
</Reference>
</ItemGroup>
不幸的是,这不起作用,因为$(平台)设置为AnyCPU ...
我们有一个大型的VS 2010解决方案,主要是C#代码,但有一些本地DLL,各种C#项目依赖(包括我们的单元测试DLL).我们正在尝试支持32位和64位版本的库.所以我们现在将本机DLL构建为32位和64位.问题是我们的很多C#项目都有后期构建事件,它们将所需的本机DLL复制到项目的TargetDir中.现在我们有两个不同版本的本机DLL(32位和64位),我需要能够指定正确的dir来复制本机DLL.我原本以为我可以简单地在路径中使用$(Platform),如下所示:
copy $(SolutionDir)\NativeDll\$(Platform)\$(Configuration) $(TargetDir)
但这不起作用,因为$(Platform)是项目的平台,而不是解决方案级平台.在这种情况下,$(平台)是"任何CPU".从我所看到的C#项目中的后期构建事件宏看,似乎没有办法访问正在构建的解决方案级平台.有没有更好的方法来实现我的目标？
有没有办法让P/Invoke(DllImport)签名引用的特定DLL依赖于CPU架构？
我正在开发一个应用程序,它从第三方供应商的本机dll加载大量方法签名,在这种情况下是用户空间接口DLL到一块硬件.该供应商现在已开始提供DLL的x86和x64版本,我认为我的应用程序将受益于作为64位进程运行.除了这个DLL,一切都是.NET代码,所以构建为"任何CPU"都可以.
本机DLL中的所有方法签名在64位上都相同,但DLL的名称不同(Foo.dll与Foo_x64.dll).有没有办法通过P/Invoke签名或app.config条目我可以让它根据正在运行的CPU架构选择加载哪个DLL？
如果不是不同的DLL名称,它在不同的文件夹中是相同的名称,它是否打开任何其他选项？
注意:因为此用户空间DLL的版本必须与安装的硬件内核驱动程序匹配,所以DLL不与我们的应用程序捆绑在一起,而是依靠供应商安装程序将其放在%的目录中路径%.
我正在使用PInvoke和DllImport属性使用外部非托管DLL.例如.
[DllImport("mcs_apiD.dll", CharSet = CharSet.Auto)]
private static extern byte start_api(byte pid, byte stat, byte dbg, byte ka);
我想知道是否有可能以某种方式动态地更改dll文件详细信息(在此示例中为mcs_apiD.dll),例如,如果我想针对另一个dll版本构建
我已经阅读了很多问题和答案,表明如果我想将C#项目与本机库相关联,我就不能使用AnyCPU平台目标,但必须制作单独的32位和64位版本,每个版本都链接到相应的本机DLL位元.
这让我想知道.NET Framework程序集本身是如何构建的,或者至少看起来是如何构建的AnyCPU.也就是说,在添加对我的GUI应用程序的引用时,为什么我不必选择32位或64位版本System.Windows.Forms？我认为这可能只是一些Visual Studio魔法会解析到相应的GAC子目录(GAC_32或GAC_64),但我在GAC中搜索了System.Windows.Forms.dll并在以下位置找到它:
C:\ WINDOWS\Microsoft.NET \装配\ GAC_MSIL\System.Windows.Forms的\ v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll中
请注意"GAC_MSIL".那么这个DLL如何设法包装本机32位API,但仍然可以在64位应用程序中链接？为什么我不能使用类似的策略来制作一个链接本机32位库但仍然可以在64位模式下运行的C#DLL？