使用 C# 识别 CPU 架构类型
我想检查用户运行的是哪个CPU架构,是吗 i386 或 X64 或 AMD64。 我想用 C# 来做。 我知道我可以尝试 WMI 或注册表。 除了这两种还有其他办法吗? 我的项目目标是.NET 2.0!
I want to check which CPU architecture is the user running, is it
i386 or X64 or AMD64. I want to do it in C#.
I know i can try WMI or Registry. Is there any other way apart from these two?
My project targets .NET 2.0!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(15)
我知道这个问题是过去的问题,但截至 2017 年,现在有一个简单的方法可以了解当前进程的体系结构,在 .net 标准中:
返回的值是 X86、X64、ARM、ARM64 之一,并给出它正在运行的进程的体系结构。
OSArchitecture
返回已安装操作系统的体系结构。文档链接(虽然没什么用......):
RuntimeInformation.ProcessArchitecture:
https://learn .microsoft.com/en-us/dotnet/api/system.runtime.interopservices.runtimeinformation.processarchitecture?view=netstandard-1.4
架构枚举:
https://learn.microsoft .com/en-us/dotnet/api/system.runtime.interopservices.architecture?view=netstandard-1.4
I know that this question is from the past, but as of 2017, there is now a simple method to know the architecture of the current process, in .net standard :
The value returned is one of X86, X64, ARM, ARM64 and gives the architecture of the process it's running in.
OSArchitecture
returns the architecture of the installed operating system instead.Links to the docs (pretty useless though...):
RuntimeInformation.ProcessArchitecture:
https://learn.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.runtimeinformation.processarchitecture?view=netstandard-1.4
Architecture enumeration:
https://learn.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.architecture?view=netstandard-1.4
您也可以尝试(仅在不被操纵的情况下有效):
You could also try (only works if it's not manipulated):
让我来到这里的是检查 32 位与 64 位操作系统。 评分最高的答案是查看当前进程的设置。 在找不到答案后,我找到了以下设置。 希望这对你有用。
What led me here is checking for a 32 vs 64 bit OS. the highest rated answer is looking at the setting for the Current process. After not finding an answer I found the following setting. Hope this works for you.
这是一段似乎可以工作的代码(基于 P/Invoke); 它允许确定 CPU/机器架构、当前进程架构以及给定的二进制文件架构(如何编译):
此代码支持 x86、x64 和 arm64 架构以及 Windows XP。 在现代版本的 .NET 中,您在 System.Runtime.InteropServices.RuntimeInformation 命名空间。
Here is a piece of code that seems to work (based on P/Invoke); It allows to determine the CPU/Machine architecture, current process architecture and also a given binary file architecture (how it's been compiled):
This code supports x86, x64 and arm64 architectures and Windows XP. In modern versions of .NET you have built-in functions in the System.Runtime.InteropServices.RuntimeInformation namespace.
Win32_Processor WMI 类将完成这项工作。 使用 MgmtClassGen.exe 生成强类型包装器。
Win32_Processor WMI Class will do the job. Use MgmtClassGen.exe to generate strongly-typed wrappers.
最后,解决 C# 中当前运行的 CLR 运行时的平台/处理器体系结构的最短技巧是:
这里 Module.GetPEKind 返回 ImageFileMachine 枚举,自 .NET v2 以来就存在:
为什么不使用
new AssemblyName(fullName)
或 <代码>typeof(object).Assembly.GetName()?ASP.NET MVC 源代码(自 1.0 起)中有这样的
HACK
注释:看看他们为自己使用了一些隐藏的技巧。 遗憾的是,
AssemblyName
构造函数没有正确设置ProcessorArchitecture
字段,对于任何新的 AssemblyName,它只是None
。因此,对于未来的读者,我建议您使用丑陋的 GetPEKind 和 ImageFileMachine!
注意:
也就是说,唯一的例外是 I386 运行时可以在 AMD64 系统上运行。
Finally the shortest trick to resolve the platform/processor architecture for the current running CLR runtime in C# is:
Here Module.GetPEKind returns an ImageFileMachine enumeration, which exists since .NET v2:
Why not use
new AssemblyName(fullName)
ortypeof(object).Assembly.GetName()
?Well there is this
HACK
comment in ASP.NET MVC source code (since 1.0):See they use some hidden tricks for themselves. Sadly, the
AssemblyName
constructor doesn't set theProcessorArchitecture
field appropriately, it's justNone
for whatever new AssemblyName.So for future readers, let me recommend you using that ugly GetPEKind with ImageFileMachine!
Notes:
That said, the only exception is that an I386 runtime may run on an AMD64 system.
这个怎么样?
但是
case *.Arm:
尚未测试。How about this?
However
case *.Arm:
isn't tested yet.也许这篇 CodeProject 文章会有所帮助? 它使用 System.Management 命名空间中的 ManagementObjectSearcher 来搜索硬件信息。
Maybe this CodeProject article could help? It uses the ManagementObjectSearcher in the System.Management namespace to search for hardware info.
根据您想知道的原因,您可能会发现检查 IntPtr 结构的大小是最简单的方法。
Depending on why you want to know, you might find that checking the size of the IntPtr structure is the easiest way.
你也许可以问问用户?
当然只是开玩笑...我认为 WMI 就是您所使用的。 但也许还有其他方法呢?
如果您选择 WMI,那么 LinqToWmi 可能会有用。 我尝试过一次,看起来非常简单 =) -> http://www.codeplex.com/linq2wmi
You could ask the user perhaps?
Just kidding of course... I think WMI is what you would use for that. But maybe there is some other way as well?
If you go for WMI then LinqToWmi could be of use. I tried it out once, and it seemed pretty straight forward =) -> http://www.codeplex.com/linq2wmi
这对我来说似乎是最简单的:
This seems the simplest to me:
这是我的方法:
如果操作系统是 Linux,则调用 libc-syscall uname,您将在 Machine 字段中看到处理器。
如果操作系统是Windows,检查System.IntPtr.Size * 8 = 64,则它是64位。
如果不是 64 位,则检查 IsWow64Process 是否存在,如果存在,并且进程是 Wow64,则它是 x86-64,否则它是 x86-32。
这个是可靠的。
检查处理器架构环境变量则不然。
代码:
Here is my way:
If the operating system is Linux, pinvoke the libc-syscall uname, where you will have the processor in the Machine-field.
If the OS is Windows, check if System.IntPtr.Size * 8 = 64, then it's 64 bit.
If it isn't 64-Bit, you check if IsWow64Process exists, and if it exists, and the process is Wow64, then it's x86-64, else it's x86-32.
This one is reliable.
Checking the processor-architecture environment variables is not.
Code:
我使用了这个:
Environment.Is64BitOperatingSystem
例如:
Environment.Is64BitOperatingSystem ? "win-x64" : "win-x86"
它适用于 .NET Framework 4.0、4.5、4.5.1、4.5.2、4.6、4.6.1、4.6.2、4.7、4.7。 1、4.7.2、4.8、4.8.1
I used this:
Environment.Is64BitOperatingSystem
for example:
Environment.Is64BitOperatingSystem ? "win-x64" : "win-x86"
it's applied to .NET Framework 4.0, 4.5, 4.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2, 4.8, 4.8.1
我相信你应该避免像 WMI 和 LINQ 这样的臃肿的东西..并且你最终必须这样做,以便在你进行的过程中获得更多的信息,而臃肿的 API 和框架无法满足这些信息。
只需调用一个 dll 来调用并提取 CPUID 信息。 C++/CLI 或 pinvoke 就可以,并获取您需要的有关供应商的所有信息。 首先您需要查看该指令是否受支持(99% 的情况下是支持的)。
要快速启动和运行,请检查 intel 站点上的 wincpuid 示例,并从那里提取 cpuid.h 中的部分。 只有 2 家供应商,其中一家在内存延迟方面表现出色,而另一家则不然(例如本机代码与托管代码)。 所以你会在其他架构等上遇到 Mono 的问题(顺便说一句谁没有)。 至于 x64,您已经知道它,或者只是获取 corflags(它已经存在并通过 .NET 发行版杀死您的客户硬盘驱动器)..
(http://software.intel.com/en-us/articles/api-detects-ia-32 -和-x64-平台-cpu-特性/)
I believe you should avoid heavy bloat like WMI and LINQ.. and you'll have to eventually, to get more info as you go along, none of which are satisfied by bloated apis and frameworks.
Just invoke a dll that calls and extracts CPUID info. C++/CLI or pinvoke would do and get all the info you need on the vendor. First you need to see whether the instruction is supported (99% of the time it is).
To get quickly up and running is to check the intel site for wincpuid sample and extract the piece from cpuid.h from there. There are only 2 vendors and one is good with memory latency and the other one isn't (like native vs managed code). So you'll have issues with Mono on other architectures etc (who doesn't btw). As for x64 you already know it or just get the corflags (its there already and killing your customer hard drive with .NET distribution )..
(http://software.intel.com/en-us/articles/api-detects-ia-32-and-x64-platform-cpu-characteristics/)
这就是我所做的:
如果您使用 64 位体系结构,您将有两个程序文件环境变量。 如果您使用的是 x86,则只有一个。
Here's what I did:
If you're on 64 bit architecture you'll have two program file env variables. If you're on x86, you'll only have the one.