互操作程序集指针长度

为什么Visual Studio有时会将COM库中的SAME指针参数变为uint，有时会变成ulong？我有了一些方法与参数，如互操作程序集指针长度

当我引用我的台式电脑上的这个库，互操作程序集变成了ULONG_PTR到uint一个COM库。当我在笔记本上做同样的事情时，它变成了ulong。这会在机器之间共享项目时造成问题。我可能可以将Interop程序集与项目的其余部分一起存储在SVN中，但是如果在更新COM库之后需要重新生成它，则会导致问题。

的系统有：

 
Desktop        Laptop 
- Windows Vista Professional 64-bit - Windows 7 Ultimate 64-bit 
- Visual Studio 2008 Professional  - Visual Studio 2008 Team System 
    (SP1)         Development Edition (SP1) 
- .Net Framework 3.5 SP1    - .Net Framework 3.5 SP1

启用UAC和Visual Studio中以管理员身份运行。

我会尝试在笔记本电脑上应用Visual Studio 2008 SP1以防这种情况发生。

编辑：笔记本电脑上的应用SP1没有效果。

更新：

当添加引用Visual Studio中的COM库，进程监视器显示devenv的台式计算机上阅读COMLibrary.dll而它在笔记本电脑读取COMLibrary64.dll。这绝对是桌面显示指针而笔记本电脑显示过长的原因。

现在它为什么这样做？两台电脑上的Devenv进程都在WoW64下运行。

运行该程序时，它根据进程监视器在两台计算机上使用COMLibrary64.dll。所以这个问题似乎只是在参考添加期间。

接下来将手动尝试执行interop生成。

来源

2009-12-05 Mikko Rantanen

它是绝对相同的COM服务器，而不是32和64位版本？您所描述的具有针对不同位的所有特征，正如您可能知道的那样 - ULONG_PTR在32位编译目标中为32位，在64位编译目标中为64位，但本机代码在编译时必须为其中一种或另一种。

名义上的“正确”翻译应该是UIntPtr，但是这取决于.NET客户端进程运行的是什么框架，而不是什么要求，即COM服务器的位数。

来源

2009-12-06 02:29:16

是的，它肯定听起来不同的是来自32位和64位版本。现在我已经想出如何确认这一点，稍微更新了原文。仍然不知道为什么差异。 – 2009-12-06 12:58:39

哦，我认为（U）IntPtr在任何情况下都是正确的。这些参数大多是窗口句柄，并且至少WinForms控件将Handle属性显示为IntPtr。现在我只需要弄清楚如何告诉tlbimp。 – 2009-12-06 13:23:18

COM是一个二进制标准。 COM接口不能在32位和64位之间浮动，具体取决于使用哪个.NET框架来执行它，但.NET代码将会。如果您的可执行文件被固定为一个或另一个（即不是AnyCPU），则只应使用U/IntPtr。 – 2009-12-06 16:36:48

互操作程序集指针长度

回答

相关问题