System.Net.Http版本冲突与空引用异常问题咨询（关联.NET Standard 2.0）

Why Same NuGet Version, Different DLL Versions? #

The key thing here is that NuGet package versions don't always map 1:1 to the underlying DLL file versions. For System.Net.Http v4.3.3, the NuGet package includes different DLL builds tailored to target frameworks:

• When installed directly in a .NET Framework 4.7.1 project, it typically deploys System.Net.Http.dll v4.1.1.2.
• But your class library references a .NET Standard 2.0 project (which also uses the same NuGet package). The .NET Standard 2.0 build of the package includes a newer DLL (v4.2.0.0), which gets pulled into your class library via transitive dependencies—even though you explicitly installed v4.3.3.

Other contributing factors could be:

• Mixed reference formats: If your WebAPI uses packages.config while your class library uses PackageReference, NuGet may resolve dependencies differently, leading to mismatched DLLs.
• Accidental GAC references: Projects sometimes pull System.Net.Http from the Global Assembly Cache (GAC) instead of the NuGet package, which might be a different version.

Is the Null Reference Exception Caused by Version Conflicts? #

Absolutely. The version conflict warning is a clear sign the runtime is struggling to load the correct System.Net.Http assembly. Even though your HttpClient instance appears initialized (since setting DefaultRequestHeaders works), mismatched DLL versions can break internal dependencies in the HttpClient pipeline. When you call GetAsync, code from the wrong DLL version might try to access an uninitialized object, triggering the null reference exception.

Fixes to Try #

1. Enforce Binding Redirects Manually

Add an explicit assembly binding redirect in your WebAPI project's web.config (or app.config for class libraries) to force all versions of System.Net.Http to resolve to the same DLL version (we recommend aligning with the newer v4.2.0.0 from the .NET Standard 2.0 dependency):

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="System.Net.Http" 
                        publicKeyToken="b03f5f7f11d50a3a" 
                        culture="neutral" />
      <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" 
                       newVersion="4.2.0.0" />
    </dependentAssembly>
  </assemblyBinding>
</runtime>

2. Unify NuGet Reference Formats

Ensure all projects in your solution use the same NuGet reference format—either packages.config or PackageReference. PackageReference is preferred for better dependency resolution, especially with .NET Standard projects. If you’re mixing formats:

• Right-click the packages.config file in Solution Explorer → Migrate packages.config to PackageReference.

3. Clean Up and Rebuild

• Delete all bin and obj folders across your solution to remove cached DLLs.
• Run Clean Solution in Visual Studio, followed by Rebuild Solution. This ensures all projects pull fresh DLLs from the NuGet packages.

4. Enable Auto-Generated Binding Redirects

For .NET Framework projects, let Visual Studio handle version mismatches automatically by enabling auto-generated binding redirects. Add these properties to each project’s .csproj file:

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

5. Verify NuGet References

Double-check that all projects reference the NuGet package version of System.Net.Http, not the system/GAC version:

• Right-click each project → Manage NuGet Packages.
• Under the Installed tab, confirm System.Net.Http is listed as v4.3.3.
• In the project’s References folder, ensure System.Net.Http points to the packages/System.Net.Http.4.3.3/lib/... directory, not a system location.

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