目录
确认Windows 机器上全局安装 .NET SDK/Runtime
问题说明：在 UE5.1.1 环境中，使用 Visual Studio 2019 编译并启动项目时，本机能够正常运行；但将完整工程拷贝到其他机器后，却出现报错。原因分析如下：
| 文件 | 行 | 错误代码 | 说明 |
|---|---|---|---|
| Microsoft.MakeFile.Targets | 45 | MSB3073 | 命令已退出，代码为 6 |
| BulkData.h | 283 | E1835 | 特性 “deprecated” 在此处不适用 |
| RHI.h | 2233 | E0020 | 未定义标识符 “FRHIViewableResource” |
| BasicLayoutWidgetSlot.h | 37 | E0070 | 不允许使用不完整的类型 |
| SharedPCH.Engine.NonOptimized.ShadowErrors.h.pch | 1 | C1083 | 无法打开编译器中间文件 |
在不同机器上同一套 UE5+VS2019 工程，有的能跑、有的报上面那些错误，往往都是「环境不完全一致」导致的。常见差异有以下几种：
1. NET 运行时 安装 & 环境变量
能跑的机器：已经全局安装了 .NET 6.0 SDK/Runtime（默认装到
C:\Program Files\dotnet\…），VS2019 里直接能找到dotnet.exe，不用依赖 UE 自带的那个第三方包，也就不会报 hostfxr 或 MSB3073 退出码 6。报错的机器：没装全局 .NET，或者没设置
DOTNET_ROOT+ 把它加到Path，UE5 启动 UBT 时找不到dotnet／hostfxr，就直接编译不过。
检查DOTNOT_ROOT变量
如果没有增加DOTNOT_ROOT这个变量，则需要增加
一、新建系统变量 DOTNET_ROOT
右键「此电脑」→「属性」→「高级系统设置」→「环境变量(N)…」
在「系统变量(S)」区，点「新建(W)…」
变量名(N)：
DOTNET_ROOT变量值(V)：
D:\UE_5.1\Engine\Binaries\ThirdParty\DotNet\6.0.302\windows
- 确定保存
这一步相当于告诉系统：.NET SDK/运行时 的根目录就在上面这个文件夹里。
二、在 Path 里引用这个变量
同样在「系统变量」区，找到名为 Path 的那一行，点击「编辑(I)…」，然后
新增一行：
%DOTNET_ROOT%
这样就把 %DOTNET_ROOT%（也就是你刚才填的那个目录）加到了搜索可执行文件的路径列表里。为什么这么做？
DOTNET_ROOT变量只要改一次，以后升级 .NET 版本时修改这个值就行，不用每次都去改 Path在 Path 中写
%DOTNET_ROOT%，会在运行时自动展开到具体目录，保持环境整洁
确认Windows 机器上全局安装 .NET SDK/Runtime
要确认一台 Windows 机器上有没有全局安装 .NET SDK/Runtime，最简单的就是在命令行里查
方法一：用 CMD 或 PowerShell
打开命令行
Win+R → 输入
cmd或powershell→ 回车
执行下面两条命令
where dotnet dotnet --info如果
where dotnet能返回类似C:\Program Files\dotnet\dotnet.exe
说明全局安装了 dotnet，并且系统 Path 能找到它；如果提示 “INFO: Could not find files for the given pattern(s).” 或者
dotnet直接 “不是内部或外部命令”，就说明没安装或 Path 里没有指向它。dotnet --info会列出 SDK 和 Runtime 的版本号、安装路径等详细信息——有输出就说明装了哪个版本。
方法二：在「应用和功能」里看
打开 「设置」→「应用」→「应用和功能」
在搜索框输入
dotnet或 “.NET”如果列表里出现了
“.NET SDK x.x.x” 或
“.NET Runtime x.x.x”
那就证明系统里全局装了对应版本。
方法三：看看安装目录
默认安装在：
makefile
C:\Program Files\dotnet\如果能在这个文件夹下看到
dotnet.exe、hostfxr.dll、shared\子目录，那也是全局安装的标志。
2. MSVC 工具集 & Windows SDK 版本
UE5.1+ 官方推荐用 VS2022 + v143 工具集（C++17+）；VS2019 拖着 v142 虽然官方标称支持，但在新版 RHI、属性（
[[deprecated]]）等语法上就更容易踩坑。能跑的机器可能也装了更新的 Windows 10/11 SDK、并且项目里自动选中了 v142 的更新补丁；而出问题那台要么缺 SDK、要么选到了一个不完全支持 C++17 的老编译器。
3. 项目 路径 & 非 ASCII 字符
你出错机器的路径里有中文、空格、甚至罕见字符（“副本”“鍓🔳湰”……）
UE 的 PCH、批处理脚本和 MSBuild 都对路径敏感，一旦遇到中文或特殊符号，往往会在预编译头（PCH）阶段就出错，然后连锁导致一堆
不完整类型、找不到 FRHIViewableResource、.pch 丢失。能跑的机器一般把工程放在
D:\Projects\XXXX\…这种纯 ASCII 路径下。删去路径里面所有的中文、空格、罕见字符
4. 引擎源码 & 模块依赖
如果工作机上你改过引擎源码、或装过插件、手动补齐了
YourGame.Build.cs里的依赖（RHI、SlateCore、Slate等），就不会报那个找不到类型的错误。问题机上可能是新安装的 UE，引擎源码没补依赖、模块声明也没对上，导致编译器在头文件里一通缺失。