Various SDK build fixes within VS

[MiYanni]

Builds on: #49746

Summary

After trying to do "Rebuild All" within VS for the repo, I ran into a bunch of problems. This should address some of them.

Changes

• Changed manifest-packages.proj to manifest-packages.csproj for VS compatibility
• Added NU5039 to NoWarn since we get this warning for all the packages we make
• Added -ExecutionPolicy Bypass since you cannot build the redist project if your PowerShell is set to Restricted ExecutionPolicy (default on new Windows installs)
• Added GetTargetPath target to sdk-tasks.csproj as it was complaining about it when trying to rebuild
  • I was trying to find the correct fix from here but it didn't work
• Added script to copy the downloaded runtime into Program Files
  • I was unable to run tests within VS. I was told that the runtime needed to be in Program Files, so I added a script that needs to be ran as Administrator to copy this over.
  • The cause of this issue was this commit from this PR.
  • Removed the script as copying rogue runtimes into Program Files is not good practice. Actual issue details here for running tests without using the sdk-build-env script: SdkResolver may need to set DOTNET_ROOT in order for framework-dependent processes inside an IDE to run correctly #49825

[Copilot]

Pull Request Overview

Addresses several build and tooling issues when performing a full rebuild in Visual Studio by renaming project files for VS compatibility, suppressing new NuGet warnings, ensuring PowerShell scripts run under restrictive execution policies, and adding a helper script for runtime copying.

• Rename manifest-packages.proj → manifest-packages.csproj and update all references.
• Suppress additional NuGet warnings (NU5039) and add -ExecutionPolicy Bypass to MSI-generation scripts.
• Introduce an empty GetTargetPath MSBuild target and add a new copy-runtime.ps1 script to copy built runtimes into Program Files.

Reviewed Changes

Copilot reviewed 12 out of 13 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
test/Microsoft.DotNet.PackageValidation.Tests/*.csproj	Added Microsoft.CodeAnalysis.CSharp package reference
test/Directory.Build.props	Combined and clarified NoWarn entries for NU5125/NU5123
src/Workloads/VSInsertion/workloads.csproj	Updated <ProjectReference> to point at .csproj file
src/Workloads/Manifests/Directory.Build.props	Added NU5039 to NoWarn
src/Tasks/sdk-tasks/sdk-tasks.csproj	Added stub <Target Name="GetTargetPath" />
src/Layout/redist/targets/GenerateMSIs.targets	Added -ExecutionPolicy Bypass to PowerShell <Exec> commands
src/Layout/redist/targets/BundledManifests.targets	Updated MSBuild project path to .csproj
src/Layout/redist/redist.csproj	Updated <ProjectReference> to .csproj
sdk.slnx	Updated solution entry for manifest-packages.csproj
eng/copy-runtime.ps1	New admin-run PowerShell script to copy built runtime into Program Files
Directory.Build.props	Added NU5039 to root NoWarn
.vsconfig	New Visual Studio configuration file

[MiYanni]

I just moved this into the ItemGroup that is for PackageReferences. Not sure why it was here to begin with.

[ViktorHofer]

manifest-packages shouldn't be a csproj as it doesn't invoke the compiler. We have many proj files in our repos so that should work. Otherwise this is a VS / project-system bug.

[MiYanni]

manifest-packages shouldn't be a csproj as it doesn't invoke the compiler. We have many proj files in our repos so that should work. Otherwise this is a VS / project-system bug.

That's not how it works with solutions in Visual Studio. You can't have .proj files as part of the solution. All the .proj files in this repo are not part of the solution; they are invoked via other targets. The project itself is using the Microsoft.Build.Traversal SDK, which (I believe) doesn't use the C# compiler. It should be functionally similar to a NoTargets project in that way. And not using .proj in a solution in VS is not a bug; .proj has no language identified with it in the project system, so VS doesn't know what to do with it by design. Just like if you made up something like .blahproj. It'll know it is a project, but it doesn't have a clear path on how to build it.

I know don't of the specifics beyond that, but it has always been that way. My general rule-of-thumb has always been; if the project needs to be in a solution, I use a .csproj with the NoTargets SDK. If not, I can use a .proj if something else is building it, outside a solution.