多级项目引用与DLL引用差异及.NET跨平台引用问题咨询

一、为什么项目引用和直接DLL引用的访问范围不同？ #

• 项目引用的依赖传递特性：同一个解决方案内的项目引用，MSBuild会自动处理完整的依赖链——当Project2引用Project1、Project3引用Project2时，构建系统会把Project1的输出纳入Project3的编译环境，自动完成依赖项的复制和引用关联，所以Project3能直接访问Project1的类型。
• 直接DLL引用的孤立性：当你只添加单个DLL引用时，编译器只会识别该DLL内的公开类型，不会自动查找它的依赖DLL，也不会将依赖DLL中的类型暴露给上层调用者。除非手动将所有依赖DLL放到可访问路径，并且显式处理类型可见性。

二、你的场景解决方案 #

你当前的问题核心是只复制了ChildProjectWrapper.dll，但缺少它的依赖项ChildProject1.dll，同时Wrapper未显式暴露ChildProject1的类型，具体解决步骤：

1. 复制全部依赖DLL：构建ChildProjectWrapper后，找到它的输出目录（如bin/Debug/netstandard2.0），把ChildProjectWrapper.dll和ChildProject1.dll（以及ChildProject1依赖的其他必要DLL）一起复制到Solution2项目的输出目录（如bin/Debug/net6.0），也可将这些DLL添加为Solution2项目的引用并设置“复制到输出目录”为“始终复制”。
2. 显式暴露ChildProject1的类型：
   • 如果ChildProject1的类型是internal，需要在ChildProject1的AssemblyInfo.cs中添加：

     [assembly: InternalsVisibleTo("ChildProjectWrapper")]
     

   • 若要在Solution2中直接使用ChildProject1的命名空间和类型，可在ChildProjectWrapper中添加类型转发：

     // 转发单个类型
     using ChildProject1.MyNamespace;
     public using ExposedMyType = MyNamespace.MyType;
     
     // 转发整个命名空间（C# 10及以上版本支持）
     global using ChildProject1.MyNamespace;
     

3. 兼容性检查：确保ChildProject1没有使用.NET Framework独有的API（如WPF的System.Windows相关类型），这类API在.NET Core环境下无法运行。如果存在此类API，需要在Wrapper中封装适配逻辑，仅暴露跨平台兼容的功能。

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