运行时手动加载.NET程序集会产生开销吗？是否需放弃整理构建文件夹？

运行时开销分析 #

这种手动加载程序集的方式确实存在非常轻微的运行时开销，但在绝大多数场景下完全可以忽略：

• AssemblyResolve事件仅在CLR无法自动找到程序集时才会触发，不会对正常加载的程序集产生影响。
• 你的事件处理逻辑非常简洁：解析程序集名称、拼接路径、检查文件存在、加载程序集，这些操作的耗时远低于程序集本身的加载开销。
• 只有当大量依赖程序集都需要通过该事件加载时，首次触发的累积耗时可能会略有感知，但对于普通应用来说，这个影响几乎可以忽略。

是否需要放弃文件夹整理？ #

完全没必要放弃，整理构建文件夹带来的结构清晰性、避免根目录杂乱的价值，远大于这点微不足道的开销。不过可以通过一些优化让方案更完善：

优化1：简化构建脚本 #

你当前的嵌套if判断可以简化，用findstr批量排除目标文件，可读性和维护性更好：

setlocal enabledelayedexpansion
IF NOT EXIST "$(OutputPath)libs" mkdir "$(OutputPath)libs"
for %%F in ("$(OutputPath)*.*") do (
    set "filename=%%~nxF"
    echo !filename! | findstr /I /X /C:"$(TargetName).exe" /C:"$(TargetName).dll" /C:"$(TargetName).pdb" /C:"$(TargetName).dll.config" /C:"$(TargetName).deps.json" /C:"$(TargetName).runtimeconfig.json" >nul
    if errorlevel 1 (
        move "%%F" "$(OutputPath)libs"
    )
)

优化2：缓存已加载的程序集 #

在OnAssemblyResolve方法中添加缓存，避免重复执行路径拼接和文件检查操作：

private static readonly Dictionary<string, Assembly?> _loadedAssemblies = new();
const string LIB_FOLDER = "libs";
const string ASS_EXT = ".dll";

static Program()
{
    AppDomain.CurrentDomain.AssemblyResolve += OnAssemblyResolve;
}

private static Assembly? OnAssemblyResolve(object? sender, ResolveEventArgs args)
{
    if (_loadedAssemblies.TryGetValue(args.Name, out var assembly))
    {
        return assembly;
    }

    AssemblyName assemblyName = new(args.Name);
    string assemblyNameStr = assemblyName.Name + ASS_EXT;
    string assemblyPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, LIB_FOLDER, assemblyNameStr);

    if (File.Exists(assemblyPath))
    {
        assembly = Assembly.LoadFrom(assemblyPath);
        _loadedAssemblies[args.Name] = assembly;
        return assembly;
    }

    _loadedAssemblies[args.Name] = null;
    return null;
}

优化3：使用.NET原生机制替代手动实现 #

• .NET Framework：可以直接在配置文件中指定程序集探测路径，无需编写代码：

  <configuration>
      <runtime>
          <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
              <probing privatePath="libs"/>
          </assemblyBinding>
      </runtime>
  </configuration>
  

• .NET Core/.NET 5+：修改.csproj文件直接指定依赖输出目录，省去手动移动文件的步骤：

  <Project Sdk="Microsoft.NET.Sdk">
      <PropertyGroup>
          <TargetFramework>net6.0</TargetFramework>
      </PropertyGroup>
      <ItemGroup>
          <!-- 将非自身项目的依赖输出到libs文件夹 -->
          <None Update="$(OutputPath)*.dll" Condition="!$([System.String]::Copy('%(Filename)').Equals('$(TargetName)'))" 
                CopyToOutputDirectory="PreserveNewest" OutputPath="$(OutputPath)libs\" />
      </ItemGroup>
  </Project>
  

  这种方式完全符合.NET原生加载逻辑，不需要依赖AssemblyResolve事件，更可靠且无额外开销。

总结 #

• 手动加载程序集的开销可以忽略，整理构建文件夹的做法值得保留。
• 优先考虑使用.NET原生的配置或项目文件方式实现目录整理，比自定义脚本和事件处理更简洁可靠。

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