我来帮你排查这个VS2017远程Linux（树莓派）项目的链接问题——你已经设置了项目依赖，头文件编译也没问题，但Project_B还是出异常，大概率是链接阶段的库引用配置没到位，毕竟头文件解决的是编译期的符号声明，链接期才需要找到实际的库文件实现。咱们一步步来排查：

1. 先确认Project_A的项目类型是否正确 #

右键点击Project_A → 属性 → 配置属性 → 常规，检查「项目类型」是不是静态库(.a) 或者动态库(.so)。如果设成了「可执行文件」，它不会生成可供其他项目链接的库文件，这肯定会导致Project_B找不到符号。

2. 检查Project_B的链接器附加库目录配置 #

右键Project_B → 属性 → 配置属性 → 链接器 → 常规，在「附加库目录」里，必须添加Project_A在远程树莓派上的输出路径：

• VS远程项目的默认输出路径一般是~/projects/你的解决方案名/Project_A/$(Configuration)/（比如Debug模式就是~/projects/MySolution/Project_A/Debug/）
• 你可以直接用相对路径../Project_A/$(Configuration)/，这样不管是Debug还是Release模式都能自动适配。

3. 指定要链接的库文件 #

还是在Project_B的链接器配置里，切换到「输入」选项卡，在「附加依赖项」里添加Project_A生成的库文件名：

• 如果是静态库，填libProject_A.a
• 如果是动态库，填libProject_A.so
• 也可以用更简洁的格式-lProject_A（链接器会自动匹配带lib前缀的库文件）

4. 验证远程树莓派上的实际文件是否存在 #

打开VS的「远程资源管理器」，找到Project_A的输出目录，确认libProject_A.a/libProject_A.so确实存在，而且是最新编译的（修改时间和你编译的时间一致）。
有时候VS的本地状态和远程实际文件会不同步，你可以手动删除远程的输出目录，然后重新全量编译整个解决方案试试。

5. 动态库的额外注意事项（如果用的是动态库） #

如果Project_A是动态库，除了上面的链接配置，还要确保：

• 远程树莓派的LD_LIBRARY_PATH环境变量包含该动态库的路径；
• 或者在Project_B的链接器→命令行里添加参数-Wl,-rpath=../Project_A/$(Configuration)/，这样程序运行时就能自动找到动态库了。

最后确认项目生成顺序 #

虽然你已经设置了项目依赖，但有时候VS的生成顺序可能出现偏差。右键解决方案 → 属性 → 通用属性 → 项目生成顺序，确认Project_A排在Project_B前面，确保编译Project_B时，Project_A的库文件已经生成完毕。

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