我们在2个应用程序之间有一个自动化场景（主要是MSUIA），目标是32位，我的应用程序（自动化的）是64位，64位win7。 需要共享的一些信息必须通过direkt Win SDK调用（如SendMessage，GetFocus等）来访问。
根据我的理解，Win64和32子系统是完全独立的，所以任何这种类型的交互都应该立即失败（试图通过64位应用程序访问32位应用程序的部分）。但奇怪的是，大多数东西看起来都很好。所以在内部似乎有某种编组方式。
我现在遇到了几个场景，但是我定义p / invoke函数的方式似乎有些问题。我已经宣布它们是“正式MS方式”，只要有可能改变大小（也使用伟大的http://www.pinvoke.net/default.aspx/站点）使用IntPtr，所以因为我强制我的.net应用程序是64位（使用编译开关），他们应该使用64位版本的dll编译为64位。
现在奇怪的是，当使用这些调用来访问32位应用程序时（例如GetWindowText实际上从其他进程的内存中读取）这些调用似乎工作正常。但。随后的MSUIA呼叫似乎随机失败。
如果我（错误地）为p / invoke调用声明了32位签名，即使编译为64位，一切运行正常。
对我来说，这毫无意义。
最干净的解决方案可能是将我的应用程序编译为32位（或与目标应用程序相同），仍然......我将不胜感激任何有关此问题的见解。
答案 0 :(得分：2)
64位进程只能执行64位代码。 32位进程只能执行32位代码。现在，对于32位进程，操作系统内核将切换到64位模式，用于任何内核级系统调用。但这确实是操作系统的业务。
当您从64位进程调用GetWindowText时，您正在调用64位user32.dll。当您从32位进程调用时，您正在调用32位user32.dll。目标窗口是在32位还是64位进程并不重要，重要的是执行代码的位数。
你的问题部分讨论了32位版本的p / invoke签名对我来说没有多大意义。如果没有看到任何代码，我真的不能说更多。
您想知道是否需要编译32位应用程序。我对此表示怀疑。您正在进行不同流程的自动化。 32位进程自动执行64位进程是完全正常的，反之亦然。
您不能混合的是同一过程中的不同位模块。您无法从64位可执行文件加载32位DLL。反之亦然。但是你没有这样做，这意味着你可以编译32位或64位的应用程序。
现在，说过你可以使用32位或64位进程，我建议你定位32位。原因在于它使您的部署更简单，因为您只有一个版本的应用程序。是的，你可以使用AnyCPU，但为什么要这么麻烦。如果你不需要64位进程，那么坚持最低公分母就更容易了。