问题标签 [64-bit]

如何让 Visual Studio 2005/2008 引用 64 位 GAC 而不是 32 位 GAC 中的程序集？我们将目标平台设置为 x64，编译器抛出错误

错误 2 警告为错误：程序集生成 -- 引用的程序集“System.Data.dll”针对不同的处理器

错误 3 警告为错误：程序集生成 -- 引用的程序集“mscorlib.dll”针对不同的处理器

错误 4 程序集签名失败；输出可能没有签名——系统找不到指定的文件。常见的

2008 年 12 月 29 日更新

一直在尝试Aaron Stebner将 64 位程序集放置到隔离位置（例如 C:\Windows\Microsoft.NET\Framework64\v2.0.50727\GAC_64）的建议，并在注册表中创建其他条目，如 HKLM\SOFTWARE\Microsoft.NETFramework \AssemblyFolders\GAC_64 或 HKLM\SOFTWARE\Microsoft.NETFramework\v2.0.50727\AssemblyFoldersEx\GAC_64 但 Visual Studio 2005 仍然没有选择它....

我最近升级了 ac# windows 服务以作为 64 位 .net 进程运行。通常，这很简单，但系统使用了一个用 C++ 编写的 32 位 DLL。将此 DLL 转换为 64 位不是一个选项，因此我将 DLL 包装在一个单独的 32 位 .net 进程中，并通过远程处理公开了一个 .net 接口。

这是一个非常可靠的解决方案，但我更愿意将系统作为单个进程运行。有什么方法可以将我的 32 位 DLL 加载到 64 位进程中并直接访问它（可能通过某种 thunking 层）？

I am porting an existing windows based C++ application to 64 bit environment, and this is one of those weird errors. In the code snippet you can that I am using openforwardonly and it used to work fine with our old setup but in the 64 bit environment it gives the problem of fetching only ONE recordset. Or it could be a problem with the MoveNext(); of ADO.

To circumvent it we started using adOpenStatic, and it worked fine for me for a while but only later realized that it has a performance hit and it is taking forever to get/iterative through values. I request someone to try this code with both the flags and validate the behavior I am seeing.

Information about ado flags: http://www.w3schools.com/ADO/met_rs_open.asp

Another EE topic http://www.experts-exchange.com/Programming/Languages/Visual_Basic/VB_DB/Q_11520558.html

I remember seeing a MS support case, but I can't get to it now.

I would appreciate any help or suggestions. I know we are using old technology, but we want to move to the additional capabilities without changing code much.

JVM 如何在 32 位处理器上处理 64 位的原始“long”？

在多核 32 位机器上可以并行使用多核吗？
32 位机器上的 64 位操作要慢多少？

您建议在 64 位环境中使用什么来进行代码覆盖。似乎 NCover 仅在 Enterprise 版本中支持 64 位，这似乎相当昂贵。或者不是吗？人们在 64 位系统上使用什么来进行 .NET 代码覆盖？

编辑：我知道 CorFlag 解决方法。我想知道其他人在做什么/使用什么。您是在使用其他东西还是在使用带有 CorFlag 技巧的 NCover（免费版）？

我想知道当不是每个人都可以立即升级到 x64 操作系统时，.NET 团队如何处理程序集引用路径。现在的关键问题是 x64 版本的 Windows 会将 32 位安装植入 C:\Program Files (x86)\ 而不是常规的 C:\Program Files。这意味着来自第三方的许多额外组件和框架最终位于 C:\Program Files (x86) 中。

因此，当将在 x86 工作站中创建/修改的源项目下载到 x64 工作站时，需要进行一些修改工作才能使参考路径正确。很典型的是，x64 用户可能会保存修改并将他们的“偏好”提交回版本控制存储库，从而打破 x86 用户的节奏。

有哪些好的方法可以在不同的团队中保持和谐？

那么，您不能在 windows 2008 64 位上安装 Team Foundation 是经过认证的答案吗？

更新

将它安装在 Windows 2003 或 2008 上会更好吗？

如果我要说的任何内容毫无意义或忽略了一些显而易见的事情，我深表歉意——我对 CLR 内部的了解参差不齐。

如果我理解正确，那么如果我只是在 VS2K5 中为“AnyCPU”构建一个解决方案（或使用这些设置将 MSBuild 指向那个 .sln 文件），那么二进制文件只能编译到 MSIL。然后，如果在 32 位平台上执行，它们会被 JITted 到 32 位；如果在 x64 上执行，它们会被 JITted 到 64 位代码......对吗？

DLL 用于 Web 应用程序并托管在 W3WP.exe 进程中。Process Explorer 告诉我 W3WP 是一个 64 位进程。

但是，当我使用 Process Explorer 在 DLL 视图中检查其中一个 DLL 的属性时，它会显示：“图像：32 位”。是什么赋予了？

如果我对有问题的 dll 运行 corflags，它会告诉我： ILONLY 1 , 32BIT 0 but PE PE32 。我的理解是，这意味着是的，它只编译到 IL，不，它不限于 32 位或 64 位，但我并不完全清楚。PE32 标志是否与上述显示为 32 位有关？

我试图获得关于 COM 在 x64 机器上的行为方式的明确答案。在向 x64 机器上的 COM 接口调度调用时，Windows 是否使用正常的 x64 调用约定（假设 COM 实现是 64 位）？具体来说，我动态生成我的 vtbl 条目以指向在运行时动态加载的程序集块。这个程序集需要知道如何正确地从调用它的人那里获取参数。因此，我想知道 COM 是否使用标准 x64 调用约定（几乎是 fastcall）设置对我的程序集的调用。

我们有一个文件，其中有一个 64 位整数作为字符串。我们如何 scanf() 或以其他方式将此数字字符串解析为 C++ 中的无符号 64 位整数类型？

我们知道诸如 %lld 之类的东西，但是执行此解析的许多方法似乎会破坏不同编译器和标准库下的编译。代码应该在 gcc 和 Microsoft C++ 编译器下编译（当然完全符合标准将是一个加号）