迁移至新.csproj格式后，Release编译生成的.dll与旧版不一致问题咨询

Hey there! Let’s dig into why your Release-mode DLLs don’t match after migrating from your old VS2015 class library project to the new SDK-style .csproj in VS2017, and walk through how to fix this.

1. Default Compilation Option Discrepancies #

The old non-SDK-style .csproj and the new SDK-style project have different default settings for Release builds:

• Old projects might have OptimizeCode enabled but with different sub-options, or the new project defaults to DebugType set to portable while your old project used full or pdbonly.
• New SDK projects enable Deterministic compilation by default (which produces identical output as long as inputs don’t change), but your old VS2015 project likely didn’t have this turned on.

2. Dependencies and References Handling #

• Old projects often include implicit references to certain .NET Framework system assemblies that the new SDK-style project doesn’t add automatically. You might be missing indirect dependencies, or the referenced versions could differ slightly.
• The new PackageReference system (used by SDK-style projects) handles NuGet dependencies differently than the old packages.config—this can lead to minor version differences in the components included during compilation.

3. Subtle Target Framework Differences #

Even though you’ve specified net452;net46 in your new project, the SDK interprets target frameworks slightly differently than the VS2015 project system. This can affect defined compilation symbols, leading to different code paths being used via conditional compilation.

1. Match Compilation Settings #

Copy the critical Release-mode configuration from your old project into the new .csproj to ensure parity. For example, add or adjust this section in your <Project> block (tweak values to match your old project’s settings):

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
  <Optimize>true</Optimize>
  <DebugType>pdbonly</DebugType> <!-- Common default for old VS2015 projects -->
  <Deterministic>false</Deterministic> <!-- Disable if your old project didn't use this -->
  <DebugSymbols>true</DebugSymbols>
  <!-- Add other Release-specific settings from your old project, like WarningLevel or TreatWarningsAsErrors -->
</PropertyGroup>

You can find all your old project’s Release settings by right-clicking the project in VS2015 → Properties → Build tab.

2. Validate Dependencies and References #

• Compare the reference lists of both projects. Add any missing system assemblies to the new project using <Reference> tags:

<Reference Include="System.Web" />

• For NuGet packages: Ensure all package versions in the new project’s PackageReference match exactly what was in the old project’s packages.config. You can check and adjust versions via the NuGet Package Manager in VS2017.

3. Verify Conditional Compilation Symbols #

Check that the compilation symbols defined for your target frameworks are identical between the old and new projects. You can view the actual symbols generated during compilation by enabling detailed build logs, then cross-reference to ensure conditional code paths execute the same way.

4. Compare Build Logs #

Enable detailed build logging for both projects to spot exact differences in the compilation process:

• For the old VS2015 project: Go to Tools → Options → Projects and Solutions → Build and Run, set "MSBuild project build output verbosity" to "Detailed", then build and save the log.
• For the new VS2017 project: Do the same, build, save the log, then compare the two logs to identify differing compile parameters, referenced assemblies, or build steps.

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