.NET Framework 3.5环境下是否存在MEF的等效替代方案？

首先排除进程内直接通过.NET托管API加载DLL的方案：

1. 你使用的定制mscorlib已移除System.IO，Assembly.LoadFrom/LoadFile等托管加载API底层依赖System.IO读取DLL文件，无法正常调用
2. .NET Framework 3.5使用CLR 2.0运行时，高版本.NET（4.0+）使用CLR 4.0运行时，同进程内默认无法兼容，即便通过CLR寄宿实现共存，也会和你定制的mscorlib产生类型冲突，直接触发崩溃

以下是经过验证的可行方案：

方案1：独立宿主进程 + 跨进程IPC通信（优先推荐） #

该方案完全规避你当前环境的限制，兼容性最高，支持所有类型的插件DLL：

• 单独开发不受.NET 3.5限制的独立宿主程序，可选用.NET Framework 4.8、.NET 6+ 甚至C++ 开发，该宿主负责从指定文件夹读取、加载所有插件DLL（支持高版本.NET、其他编程语言生成的DLL），完成实例化和逻辑运行
• 你的.NET 3.5主程序和独立宿主之间通过轻量IPC通信完成交互，无需依赖被裁剪的System.IO类：可直接P/Invoke调用Windows原生API实现内存映射文件或者Windows消息队列通信
• 通信协议自定义轻量二进制规则即可，比如前4字节标识消息长度、后续为消息载荷，序列化直接用基础类型硬编码，避免依赖.NET自带的序列化类

方案2：P/Invoke调用原生API + C++/CLI桥接层（适合同进程需求场景） #

如果要求插件和主程序运行在同一进程内，可采用该方案：

• 对于标准非托管DLL（比如C/C++编译、导出标准C接口的DLL），直接P/Invoke调用Windows原生的LoadLibrary、GetProcAddress、FreeLibraryAPI加载调用，无需依赖System.IO，示例声明如下：

[DllImport("kernel32.dll", SetLastError = true)]
public static extern IntPtr LoadLibrary(string lpFileName);

[DllImport("kernel32.dll", SetLastError = true)]
public static extern IntPtr GetProcAddress(IntPtr hModule, string lpProcName);

[DllImport("kernel32.dll", SetLastError = true)]
public static extern bool FreeLibrary(IntPtr hModule);

• 对于高版本.NET生成的托管DLL，额外开发C++/CLI桥接层：桥接DLL同时兼容CLR 2.0和CLR 4.0，内部自行寄宿CLR 4.0运行时加载高版本.NET DLL，之后导出标准C接口给.NET 3.5主程序通过上述P/Invoke方式调用

通用注意事项 #

• 所有跨运行时、跨进程的交互都不要传递自定义托管类型，仅使用int、字符串指针、字节数组等基础类型传递参数和返回值，避免类型不兼容或者触发定制mscorlib的缺失依赖崩溃
• 禁止尝试在.NET 3.5进程内直接加载高版本.NET托管DLL，运行时和mscorlib的双重冲突大概率直接导致程序崩溃

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