Why does my dotnet build use the wrong target framework in the DevOps pipeline (NU1702)?

Below is an explanation of what’s happening and some steps you can take to resolve the build issues.

What’s Happening

• Mismatched Target Frameworks:
  The error message shows that one of the referenced projects (Tools\XXXX.csproj) is resolved using .NET Framework (v4.8) even though your main project is targeting .NET 6. This mismatch is indicated by the warning about NU1702 and ultimately the error NETSDK1005 when the assets file doesn’t contain a target for net48.

• Mixed References:
  The presence of duplicate references (for example, a direct <Reference> with a specific HintPath to a log4net assembly from net45 alongside a <PackageReference>) can lead the build system to pick up the wrong target framework, especially in a pipeline environment where dependencies are restored strictly.

• Pipeline Differences:
  Although your local workstation builds the solution fine, the build agents in your pipeline may use different restore or resolution logic. In your case, the Tools project might automatically default to its original target (net48) if it still contains hints or explicit references for that framework.

Steps to Resolve the Issue

1. Ensure Consistent Target Frameworks for All Projects:

   • Update the TargetFramework:
     Make sure every project referenced by your solution targets a compatible framework. For a multi-target solution, if you need to support both .NET 6/8 and .NET Framework 4.8, update the Tools project to multi-target by using:

     XMLCopied
     <PropertyGroup>
       <TargetFrameworks>net48;net6.0</TargetFrameworks>
     </PropertyGroup>

     Otherwise, if the Tools project isn’t meant to use .NET Framework, update its target to only .NET 6 or .NET 8.

2. Remove or Consolidate Duplicate References:

   • Remove duplicate references such as the direct <Reference> to log4net (which points to a net45 version) if you are already using <PackageReference>. This avoids ambiguity in the resolution process.

     For example, remove:

     XMLCopied
     <Reference Include="log4net">
       <HintPath>..\packages\log4net.2.0.15\lib\net45\log4net.dll</HintPath>
     </Reference>

     and keep:

     XMLCopied
     <PackageReference Include="log4net" Version="3.0.3" />

3. Verify Your Restore Process:

   • Ensure that during the pipeline, the restore step includes all target frameworks. When a project is multi-targeted, the restore step should generate assets for each target.

   • If a referenced project still targets net48, either update its project file or include net48 in its <TargetFrameworks> (if that is intended).

4. Global.json Considerations:

   • Since your global.json is empty, the pipeline picks up the latest available SDK. If you want to enforce a specific SDK version to avoid unexpected resolutions, specify the required version in global.json. For example:

     JSONCopied
     {
       "sdk": {
         "version": "6.0.x"
       }
     }

     or another version based on the primary target.

5. Check DevOps Tasks Ordering:

   • Verify that the usage of tasks like UseDotNet@2 and NuGetToolInstaller@1 are executed before the restore and build steps. Confirm that the environment variables and paths are set correctly for the intended SDKs.

Summary

The build failure in your DevOps pipeline is most likely due to a project reference that’s still targeting .NET Framework 4.8 (or being resolved as such) while your main project targets .NET 6/8. Consolidate your references (remove any duplicate or HintPath-based references), align your target frameworks across your projects, and ensure that your restore step is aware of all targets. These changes should resolve the asset file issues and the warnings/errors related to UG1702 and NETSDK1005.