DotNet CLI对比：dotnet运行dll与dotnet run的差异及WebAPI 404问题

两种执行方式的核心差异 #

• dotnet "xxx.dll" 是纯运行时层面的启动命令：直接把指定路径的dll加载到.NET 运行时进程中启动，全程不会读取目录下的项目文件（.csproj）、不会触发任何编译流程，进程的工作目录、环境变量完全继承你当前打开的命令行窗口的上下文，没有任何项目级的自动配置注入，这也是为什么你执行这个命令时不会看到“Building...”的输出。
• dotnet run "xxx.dll" 是面向开发场景的项目托管启动命令：执行时会先扫描当前目录下的项目文件，自动完成增量编译流程（也就是你看到的“Building...”提示的来源），编译完成后再启动对应产出的dll。过程中会自动注入一系列开发场景的默认配置：包括自动将环境变量ASPNETCORE_ENVIRONMENT设置为Development、修正进程工作目录、加载项目文件中定义的启动参数，所有跟在命令后面的额外参数会被透传给最终启动的应用进程。

Web API 直接运行dll时Swagger返回404的根本原因 #

• .NET 5.0默认Web API模板中，Swagger中间件的注册逻辑是严格绑定开发环境判定的：模板自动生成的启动代码里，只有当进程检测到ASPNETCORE_ENVIRONMENT变量值为Development时，才会把Swagger JSON接口、Swagger UI页面的路由挂载到请求管道中，生产环境下这类调试端点会被默认禁用。
• 当你用Visual Studio F5启动、或者用dotnet run执行项目时，工具链会自动在进程启动前注入ASPNETCORE_ENVIRONMENT=Development的环境变量，因此Swagger路由正常生效，不会出现404。
• 当你直接执行dotnet "xxx.dll"时，当前命令行窗口的环境里没有预先设置这个开发环境变量，程序默认以Production环境启动，Swagger中间件根本没有被注册到请求管道，访问对应路径自然返回404——这不是编译产出的dll有损坏或者配置错误，是运行时缺少了必要的环境配置。
• 你可以通过极简操作验证这个结论：在直接运行dll之前，先在当前命令提示符窗口执行set ASPNETCORE_ENVIRONMENT=Development手动设置环境变量，再重新启动dll，此时Swagger地址就能正常访问。
• 普通Web应用没有出现同类问题的原因：默认Web应用模板的静态首页、页面路由没有做生产/开发环境的区分逻辑，不管跑在什么环境下路由都会正常开放，因此两种执行方式下的访问表现完全一致，感知不到环境变量带来的差异。

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