C#项目程序集引用路径切换及版本优先级问题咨询

Hey there! Since you're coming from a C++ background where dependency paths are explicitly configured, let's unpack your C# assembly referencing questions clearly.

1. Why does the System.dll reference path switch to NuGet after enabling the package? #

When you add a NuGet package like Microsoft.NETCore.Portable.Compatibility, here's what's happening under the hood:

• NuGet packages often include reference assemblies (the ones in the ref folder) that are designed for compilation—they contain only the metadata needed for the compiler, not the full runtime code.
• Visual Studio and the .NET build system prioritize NuGet-provided reference assemblies over the default Framework reference assemblies (from C:\Program Files (x86)\Reference Assemblies\...). This is because NuGet packages are meant to override or supplement platform-specific references for compatibility (like in this case, enabling .NET Core/portable compatibility for a .NET Framework project).
• While the reference window might not show an explicit path configuration, your project file (.csproj) does track this. If you open it, you'll see a <PackageReference> entry for Microsoft.NETCore.Portable.Compatibility—this tells the build system to pull the reference assembly from the NuGet packages folder instead of the default Framework directory.

2. When two versions of System.dll appear in references, which is prioritized? Do both take effect? #

Great question—this breaks down into compile-time and runtime behavior:

• Compile-time: The NuGet-provided reference assembly will be used first. The .NET build system orders reference paths such that NuGet package references come before the default Framework references. You can confirm this by checking the project's build output logs, which will show the exact assembly path used during compilation.
• Runtime: Things shift a bit. For .NET Framework projects, the runtime typically loads assemblies from the Global Assembly Cache (GAC) first, unless you've configured otherwise. So even if you compiled against the NuGet reference assembly, the runtime will use the System.dll matching your target Framework version (v4.5.2 in your case) from the GAC—unless you've added binding redirects or copied a different version to your output directory.
• Do both take effect? No, only one is used at each stage (compile-time vs runtime). The reference window showing both is just listing all available candidates, but the build system and runtime will pick the highest-priority one based on their rules.

3. Does C# have explicit dependency configuration like C++'s SDK version/toolset? #

Absolutely—you have full control over dependencies, similar to C++:

• Target Framework: Explicitly set your project's target framework in the .csproj file with the <TargetFramework> element, e.g.:

  <TargetFramework>net452</TargetFramework>
  

  This is analogous to specifying a C++ SDK version, as it defines the base Framework assemblies your project relies on.
• Manual Assembly Paths: If you want to force a specific assembly path (like C++'s explicit library paths), use the <Reference> element with a <HintPath> in your .csproj:

  <Reference Include="System">
    <HintPath>C:\Path\To\Your\Preferred\System.dll</HintPath>
  </Reference>
  

• NuGet Version Locking: Use <PackageReference> with explicit versions (or package version constraints) to lock down NuGet dependencies, just like how you'd pin a C++ library version. You can also use a Directory.Packages.props file to manage version constraints across multiple projects.
• Runtime Binding Redirects: For runtime version control, add <assemblyBinding> entries to your app.config or web.config to specify exactly which version of an assembly the runtime should load. This is similar to configuring C++ runtime library search paths:

  <dependentAssembly>
    <assemblyIdentity name="System" publicKeyToken="b77a5c561934e089" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
  </dependentAssembly>
  

Keep in mind that while Visual Studio's UI might hide some of these details, the .csproj and config files are where all the explicit configuration lives—just like how C++ projects use .vcxproj and property sheets for dependency control.

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