Run binding redirect generation during `restore` instead of `build`

[julealgon]

When using GeneratedBindingRedirectsAction with, say, the Overwrite option, this custom SDK will refresh the section after the project is built.

Needing to perform a build however makes the dependency upgrade process inherently incompatible with what dependabot does when creating NuGet update PRs, thus requiring extra manual steps to force the build and then append the web.config updates on top of the branch created by dependabot.

I did a quick investigation, and it appears that dependabot already performs a dotnet restore today as part of its process, which is useful for producing needed diffs on packages.lock.json files when using locked restore mode.

If this SDK could also tap into the same process as lock files do (run binding redirect updates on restore), it would naturally work with dependabot PRs and we would be able to merge those with zero manual intervention.

I wasn't sure whether or not it was possible to tap into the restore process from MSBuild, but it appears to be possible using BeforeTargets="Restore" and AfterTargets="Restore" as long as the project is leveraging SDK-style csproj.

Can this SDK be updated in such a way that it does the binding redirect regeneration step during restore instead of during build?

[CZEMacLeod]

I'm not sure that this is actually possible.
The binding redirects are done by the Microsoft.NET.Sdk targets - this sdk only adjusts the target to update the web.config file.
I don't think you can trigger these targets during the restore process.
The dotnet restore command has some clever logic in it such that it doesn't actually pull in the full SDK targets etc. and can run even when there are errors - otherwise it would throw an error when trying to import "$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" as it does if you try dotnet build.
I did some quick tinkering and came up with adding the following to your project file - you are welcome to try this and/or do some more investigation yourself.

  <Target Name="UpdateBindingsOnRestore" AfterTargets="_GenerateRestoreProjectSpec" DependsOnTargets="GenerateBindingRedirects">
    <Message Text="Updating binding redirects in $(_GenerateBindingRedirectsIntermediateAppConfig)" Importance="High" />
  </Target>

This outputs something like Updating binding redirects in obj\Debug\ExampleRazorLibraryApplication.dll.config which shows that the SystemWebProject_ChooseConfigFileForGenerateBindingRedirects target isn't firing.
You might be able to use the MSBuild Structured Log Viewer tool to work out more about what is, and what isn't happening here.

My suggestion would be to add a github or azdo workflow to trigger on PRs created by dependabot.
That could perform a full build (which you might want anyway to check that nothing breaks) and then grab the changed web.config files and add them as a commit to the PR.

If you have a look at CZEMacLeod/C3D.Extensions.Aspire#43 you can see that it ran a full build of the solution and ran tests on this PR from dependabot.

There are some security things I think you need to do to allow the gh action to push back to the repo, even under a pr, but I think you need something like the following (untested)...

# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.
name: Dependabot Build & Commit

on:
  pull_request_target:
    types: [opened, synchronize]

permissions:
  contents: write
  pull-requests: write

jobs:
  build-and-commit:
    if: github.event.pull_request.user.login == 'dependabot[bot]'
    name: Dependabot Build & Commit
    runs-on: windows-latest

    strategy:
      matrix:
        configuration: [Release]

    env:
      Solution_Name: C3D.Extensions.Aspire.slnx

    steps:
    - name: Checkout
      uses: actions/checkout@v4
      with:
        fetch-depth: 0


    - name: Install .NET
      uses: actions/setup-dotnet@v5
      with:
        global-json-file: global.json

    - name: Install .NET
      uses: actions/setup-dotnet@v5
      with:
        dotnet-quality: 'ga'
        dotnet-version: |
            6.0.x
            8.0.x
            9.0.x
            10.0.x

    # Add MSBuild to the PATH: https://github.com/microsoft/setup-msbuild
    - name: Setup MSBuild.exe
      uses: microsoft/setup-msbuild@v2
      with:
        msbuild-architecture: x64

    - name: VSWhere VSToolsPath WebApplicationsTargetPath
      id: vswhere-paths
      run: |
          $vs_path = vswhere -latest -property installationPath
          Write-Host "vs_path=$vs_path"
          $vs_version = "$($([Version]$(vswhere -latest -property installationVersion)).Major).0"
          Write-Host "vs_version=$vs_version"
          $vs_tools_path = "$vs_path\MSBuild\Microsoft\VisualStudio\v$vs_version"
          Write-Host "vs_tools_path=$vs_tools_path"
          $web_applications_target_path = "$vs_tools_path\WebApplications\Microsoft.WebApplication.targets"
          Write-Host "web_applications_target_path=$web_applications_target_path"
          "vs_tools_path=$vs_tools_path" | Out-File -FilePath $env:GITHUB_OUTPUT -Append
          "web_applications_target_path=$web_applications_target_path" | Out-File -FilePath $env:GITHUB_OUTPUT -Append
          
    # Restore the application to populate the obj folder with RuntimeIdentifiers
    - name: Restore the application
      run: msbuild $env:Solution_Name /t:Restore /p:Configuration=$env:Configuration /p:ContinuousIntegrationBuild=true '/p:AfterMicrosoftNETSdkTargets=${{ github.workspace }}\build\vs-workaround.targets'
      env:
        Configuration: ${{ matrix.configuration }}

    # Build the application
    - name: Build the application
      run: msbuild $env:Solution_Name /t:Build /p:Configuration=$env:Configuration /p:ContinuousIntegrationBuild=true '/p:AfterMicrosoftNETSdkTargets=${{ github.workspace }}\build\vs-workaround.targets'
      env:
        Configuration: ${{ matrix.configuration }}

    - name: Run tests
      run: dotnet test --no-restore --no-build --logger "console;verbosity=detailed" --logger "trx;verbosity=normal" --collect:"XPlat Code Coverage" --results-directory "TestResults"
      env:
        Configuration: ${{ matrix.configuration }}
        # VSToolsPath: ${{ steps.vswhere-vs-tools-path.outputs.vs_tools_path }}
        WebApplicationsTargetPath: ${{ steps.vswhere-paths.outputs.web_applications_target_path }}

    - name: Upload dotnet test results
      uses: actions/upload-artifact@v4
      with:
        name: dotnet-results
        path: TestResults
      # Use always() to always run this step to publish test results when there are test failures
      if: ${{ always() }}

    - name: Commit changes
      run: |
        git config user.name "github-actions[bot]"
        git config user.email "github-actions[bot]@users.noreply.github.com"
        git add .
        git commit -m "chore: auto‑generated build output" || echo "No changes to commit"
        git push

[julealgon]

I'm not sure that this is actually possible.

Oh... that's unfortunate. I wasn't 100% sure myself so I just took a stab at making the request in hopes that you or someone with more MSBuild experience would be able to make it happen.

If it turns out it is really not possible, then that's fair enough.

My suggestion would be to add a github or azdo workflow to trigger on PRs created by dependabot. That could perform a full build (which you might want anyway to check that nothing breaks) and then grab the changed web.config files and add them as a commit to the PR.

I did think about this option but I was looking for a cleaner solution without the need to maintain a custom GitHub actions workflow. The solution where we are using this SDK currently is fairly large and the server build already takes ~20 minutes to run. I was hoping that by moving the binding redirect regeneration to the restore procedure we would also get the modified results much earlier.

Running a manual build on dependabot PRs is not prohibitive today, but it would make the whole process significantly slower overall for us. In particular, it would consume even more build resources from our self-hosted runners which are already a bit of a bottleneck.

In terms of "validating" the PR, we already have a gated build process today that triggers on PR creation. Attempting to somehow "reuse" that existing build would be bad since we do restore with --locked-mode there today.

Thanks for the sample workflow there. We'll probably start implementing dependabot soon, so I'll definitely refer back to it.