我之前也踩过这个坑，问题本质其实很明确：当你用/clr编译C++/CLI项目时，Visual Studio会默认把.c后缀的文件当成纯C代码处理，但/clr编译模式并不支持纯C文件的编译，所以才会抛出error D8045: cannot compile C file 'Device.c' with the /clr option这个错误。下面给你几个靠谱的解决思路，按优先级排序：

方案1：重命名C文件为.cpp（最简单推荐） #

直接把Device.c改成Device.cpp，同时保留你原来写的extern "C" {...}代码块。这样编译器会把它当成C文件处理，而extern "C"能保证C代码里的函数名不会被C的名字修饰（name mangling），完美兼容原来的调用逻辑。

• 小提醒：如果你的C代码里有C特有的语法（比如非标准的bool定义、某些C专属宏），可能需要微调，但绝大多数标准C代码都能直接被C++编译器兼容。

方案2：单独为C文件禁用/clr编译 #

如果不想修改文件名，可以针对单个C文件覆盖项目的全局/clr设置：

1. 在Visual Studio的解决方案资源管理器里，右键点击Device.c文件，选择「属性」
2. 依次展开「配置属性」→「C/C++」→「常规」
3. 找到「公共语言运行时支持」选项，选择「无公共语言运行时支持」
4. 同时确保该文件的「编译为」选项设置为「编译为C代码(/TC)」（避免被误当成C++编译）

• 这个方法的好处是保留C文件的原生编译方式，适合那些依赖纯C特性的代码。

方案3：将C代码编译为独立库（最彻底） #

如果你的C代码库比较大，或者有复杂的依赖关系，最好把它单独编译成静态库（.lib）或动态库（.dll）：

1. 创建一个新的纯C项目（不要勾选CLR选项），把所有C代码加入进去，编译成静态库
2. 在你的C++/CLI项目中，添加对这个静态库的引用
3. 在CLI代码里用extern "C" {...}声明C库的函数原型，之后就能正常调用了

• 这种方式完全隔离了纯C代码和托管代码的编译环境，避免任何编译冲突，适合大型项目的长期维护。

额外注意 #

不管用哪种方案，extern "C"代码块都是必须的——它能告诉C++编译器不要对C函数名做名字修饰，确保托管代码能正确找到C函数的入口地址。

内容的提问来源于stack exchange，提问作者areify