Azure Function依赖DLL版本冲突求助：需同一DLL两个版本

我之前帮不少开发者搞定过这类Azure Function依赖版本冲突的问题，你的情况典型是Azure Function运行时自带的Microsoft.SharePoint.Client.Runtime版本和你的自定义DLL依赖版本不匹配，导致加载时出现循环要求不同版本的矛盾。下面是几个针对性的解决方案，按优先级尝试：

1. 配置程序集绑定重定向（最常用） #

绑定重定向可以强制应用加载你指定版本的程序集，忽略runtime自带的版本。具体操作分两种情况：

如果你用的是.NET Framework函数 #

在函数项目的web.config（注意不是本地开发的app.config）中添加程序集绑定配置，把所有SharePoint相关组件指向你上传的版本：

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.SharePoint.Client.Runtime" 
                          publicKeyToken="71e9bce111e9429c" 
                          culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-16.1.3912.1204" 
                         newVersion="16.1.3912.1204" />
      </dependentAssembly>
      <!-- 同步添加Microsoft.SharePoint.Client的重定向，避免同类问题 -->
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.SharePoint.Client" 
                          publicKeyToken="71e9bce111e9429c" 
                          culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-16.1.3912.1204" 
                         newVersion="16.1.3912.1204" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

把修改后的web.config和你的DLL一起上传到Azure Function的wwwroot目录。

如果你用的是.NET Core/.NET 5+函数 #

在项目的.csproj文件中添加自动生成绑定重定向的配置：

<PropertyGroup>
  <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
  <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>

本地编译发布后，在输出目录找到[你的函数项目名].dll.config文件，把这个文件和所有DLL一起上传到Azure。

2. 强制优先加载你上传的DLL（绑定重定向失效时用） #

如果绑定重定向没起作用，可以通过代码让函数优先从你上传的目录加载依赖：

在函数项目中添加一个启动类：

using System;
using System.IO;
using System.Reflection;
using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection;

[assembly: FunctionsStartup(typeof(YourNamespace.Startup))]
namespace YourNamespace
{
    public class Startup : FunctionsStartup
    {
        public override void Configure(IFunctionsHostBuilder builder)
        {
            // 监听程序集加载失败事件，手动指定加载路径
            AppDomain.CurrentDomain.AssemblyResolve += (sender, args) =>
            {
                var assemblyName = new AssemblyName(args.Name);
                // 指向你上传DLL的目录，默认是wwwroot/bin
                var dllPath = Path.Combine(Environment.GetEnvironmentVariable("HOME"), 
                                           @"site\wwwroot\bin", 
                                           $"{assemblyName.Name}.dll");
                
                if (File.Exists(dllPath))
                {
                    return Assembly.LoadFrom(dllPath);
                }
                return null;
            };
        }
    }
}

编译发布后，把所有文件上传到Azure，这样当程序集加载冲突时，会优先加载你上传的版本。

3. 确保所有依赖版本一致且完整 #

• 检查你的自定义DLL和所有间接依赖的DLL是否都使用同一个版本的SharePoint Client组件。可以用dotnet list package命令（.NET Core）或者NuGet包管理器查看依赖树，把所有相关包统一到同一个版本。
• 不要手动挑选DLL上传，而是用dotnet publish（.NET Core）或者Visual Studio的“发布到Azure”功能生成完整的发布包，确保所有直接和间接依赖都包含在内，避免遗漏。

4. 清理Azure Function缓存 #

有时候旧版本的程序集会被缓存，导致新上传的文件不生效：

• 进入Azure门户的函数应用页面，点击顶部的“重启”按钮，重启整个应用。
• 如果还是不行，打开Kudu控制台（通过门户的“高级工具”进入），删除D:\home\site\wwwroot下的所有旧文件，重新上传最新的发布包。

按照上面的步骤一步步排查，应该能解决这个版本循环的问题。如果还有疑问，可以查看函数的日志（门户的“监控->日志”），获取更详细的错误信息，定位具体是哪个依赖导致的冲突。

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