Remove NuGet.SolutionRestoreManager.Interop from list

[heng-liu]

Bug

Fixes: https://github.com/NuGet/Client.Engineering/issues/1096

Regression? No

Description

Remove NuGet.SolutionRestoreManager.Interop from the checking list of scripts/utils/EnsureAllPackagesExist.ps1, as we no longer have/pack this project.

PR Checklist

• PR has a meaningful title

• PR has a linked issue.

• Described changes

• Tests

  • Automated tests added
  • OR
  • Test exception
  • OR
  • N/A

• Documentation

  • Documentation PR or issue filled
  • OR
  • N/A

[erdembayar]

@heng-liu
If we merge this now then does it fix one failure I have now?

[nkolev92]

Would it be a good idea to have the check run after build as well? Rather than at release only?

That way we don't run into this issue again.

[erdembayar]

@heng-liu
It looks Microsoft.Build.NuGetSdkResolver exist in non-RTM only, but not in RTM. In 5.11 it used to be in both build. It looks we need to add condition for this. You can create separate issue to track it.

@NuGet/nuget-client Is removal of Microsoft.Build.NuGetSdkResolver from RTM was intentional?

[heng-liu]

Would it be a good idea to have the check run after build as well? Rather than at release only?

That way we don't run into this issue again.

Actually, we do check packages in every build at https://github.com/NuGet/NuGet.Client/blob/dev/eng/pipelines/templates/Build_and_UnitTest.yml#L227-L232.
But it is with another approach: #3852.
That is, checking the count of projects with <PackProject>true</PackProject>, and the generated .nupkg file and .symbols.nupkg files. If there is any mismatch, it will fail the build with a message.
Since there is no hardcoded checklist in this approach, the build doesn't fail (as expected, since all packages are generated successfully).

Shall we use the hardcoded checklist in both build pipeline and release pipeline, to make them consistent?
I will use the hardcoded checklist in both build pipeline and release pipeline, to make them consistent.
I'll do this in a separate PR, so that the publishing won't be blocked.

[heng-liu]

@heng-liu
If we merge this now then does it fix one failure I have now?

For now, if this PR get merged, I guess it will fix the failure in the current release build if you redeploy it.
Since it's getting the script from dev branch (https://devdiv.visualstudio.com/DevDiv/_releaseDefinition?definitionId=257&_a=definition-tasks&environmentId=9031)

But soon we have to change the release pipeline to not get the script from dev branch (in case old serve branch also gets the checklist from dev branch, which doesn't reflect the fact of packages in serve branch). And in order to get the right version of the script, I need to work to finish this PR: #3926

[heng-liu]

@heng-liu
It looks Microsoft.Build.NuGetSdkResolver exist in non-RTM only, but not in RTM. In 5.11 it used to be in both build. It looks we need to add condition for this. You can create separate issue to track it.

@NuGet/nuget-client Is removal of Microsoft.Build.NuGetSdkResolver from RTM was intentional?

May I know which build you are referring to? I just checked build 6.0.0.165, both RTM and nonRTM have the package Microsoft.Build.NuGetSdkResolver . I think the only difference between RTM and nonRTM is https://github.com/NuGet/NuGet.Client/blob/dev/scripts/utils/EnsureAllPackagesExist.ps1#L37-L41

[erdembayar]

Microsoft.Build.NuGetSdkResolver

Could you check please this asset list please? I can see difference between RTM and non-RTM for Microsoft.Build.NuGetSdkResolver.

It looks not an issue.

[erdembayar]

Microsoft.Build.NuGetSdkResolver

Could you check please this asset list please? I can see difference between RTM and non-RTM for Microsoft.Build.NuGetSdkResolver.

Sorry here is correct asset in question.

It looks not an issue.