编译 CounterStrikeSharp 插件时如何修复 "Missing Project Reference" 错误
有些插件分布在两个仓库中:插件本身,以及它所依赖的一个单独的 "API" 或 "shared" 项目,通常作为 git 子模块链接。如果你从 GitHub 下载插件的普通 .zip 压缩包,该子模块的内容不会包含在内,只会有一个指向它的指针。结果就是构建失败,出现几十个令人困惑的 CS0246/CS0103 错误,"type or namespace not found",缺失的项目本该提供的每个类都会对应一个错误。真正的原因只有一行,很容易被忽略。
找到真正的错误
滚动到构建失败日志的最上方,也就是 CS0246 错误墙的上面。查找类似下面这样的一行,它才是真正的原因,下面的所有内容都是它的后果:
warning MSB9008: The referenced project ../ggmcAPI/ggmcAPI.csproj does not exist.
理解它的含义
插件的 .csproj 文件通过一个相对路径引用了另一个项目,在上面的例子中,是一个名为 ggmcAPI 的文件夹,位于插件自身文件夹的上一级。这个文件夹根本不存在于你上传的压缩包中。
检查它是否是 git 子模块
在 GitHub 上打开插件的页面,查找一个显示为小箭头图标和短 commit 哈希值的文件夹,而不是普通的文件列表,那就是子模块。GitHub 的 "Download ZIP" 按钮从不包含子模块的内容,只包含一个指向应该是哪个 commit 的指针。你需要单独打开该子模块自己的仓库,并单独下载它。
正确的文件夹深度
这是大多数人第一次尝试时通常会弄错的一步。.csproj 中的相对路径(我们例子中的 ../ggmcAPI)是相对于包含 .csproj 文件本身的文件夹来解析的,而不是相对于你的 .zip 压缩包的根目录。如果你的插件文件夹和依赖文件夹不是同级的,上一级就会指向错误的位置。
一个应该避免的常见错误
把依赖文件夹放在插件自己的文件夹内看起来很合理,但这并不是相对路径所期望的。这种结构会以和完全没有该文件夹一样的方式失败:
重新编译
一旦两个文件夹以正确的深度并排放置,重新压缩压缩包并再次上传。如果日志中的 MSB9008 已经消失,但你仍然看到错误,那么现在这些就是值得单独排查的真实编译错误了。
打开 CS2Sharp 编译器这篇教程对你有帮助吗?
Barlap 为社区打造。