提问：

“devenv 只认 .sln，无法直接接受 .vcxproj 作为输入！”
这句话是错误的，用下面的命令就能编出xxx.dll
devenv /rebuild “Release|x86” “xxx.vcxproj” /OUT …\compileinfo\xxx_win32_2017_r.txt

你提得非常好！你的观察是正确的，我之前的表述 “devenv 无法直接接受 .vcxproj 作为输入” 确实不够准确，需要修正和澄清。

✅ 正确说法是：

devenv.exe 在命令行中 可以 接受 .vcxproj 文件作为参数，并成功编译它（生成 EXE/DLL 等），
但这本质上是因为 devenv 内部会自动为单个 .vcxproj 创建一个临时的解决方案（.sln）上下文来构建。

所以，技术上可行，但有前提条件和限制。

🔍 深入解释：为什么 devenv xxx.vcxproj 能工作？

Visual Studio 的 IDE（包括 devenv.com/.exe 命令行）从 VS2010 起就支持直接打开或构建单个 .vcxproj 文件。当你运行：

devenv /rebuild "Release|x86" mediasdk.vcxproj

• devenv 会：
  1. 将 mediasdk.vcxproj 视为一个“单项目解决方案”；
  2. 自动推断平台工具集、SDK、配置等；
  3. 调用底层 MSBuild（或旧版 VCBuild）完成实际编译；
  4. 输出结果与在 VS 中打开该项目并编译一致。

✅ 所以你的命令能成功生成 DLL，完全正常且被官方支持。

⚠️ 但为什么不推荐在脚本中用 devenv 编译 .vcxproj？

虽然可行，但在自动化脚本（如 CI/CD、批处理）中，仍建议优先使用 msbuild，原因如下：

💡 举个例子：如果你在 Jenkins 或 GitHub Actions 上只安装了 “Microsoft C++ Build Tools”（无 VS IDE），那么 devenv 命令根本不存在，但 msbuild 可用。

✅ 结论（修正版）

📌 建议

• 你在本地开发机上用 devenv mediasdk.vcxproj 完全没问题，尤其如果你已经装了 VS。
• 但如果写通用 .bat 脚本、分发给他人、或用于 CI/CD，请改用 msbuild，例如：

call "%VsInstallPath%\VC\Auxiliary\Build\vcvars32.bat"
msbuild mediasdk.vcxproj /p:Configuration=Release /p:Platform=Win32 /t:Rebuild

这样脚本在 仅有 Build Tools 的机器上也能运行。

技术细节上，devenv 对 .vcxproj 的支持是“向后兼容+便利功能”，而 msbuild 才是“标准构建入口”。