Stop making src modifications to every repo's NuGet.config

[MichaelSimons]

When building the VMR, there are several checked in files that are being modified. This yields a poor UX as these must be undone before you can build cleanly again. These edits will also become a nuisance in .NET 9 when the VMR can be used to checkin changes.

One type of file being modified is each repo's NuGet.config. The source-build sources are injected as the first feeds. If building offline, all other feeds are removed.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[NikolaMilosavljevic]

It appears that we'd need a different set of feeds for online vs offline builds. In a related issue cloaking of repo-specific nuget.config files was suggested as part of the solution.

@MichaelSimons what are the current thoughts on available options, considering that some VMR plans might have changed in the meantime?

[MichaelSimons]

It appears that we'd need a different set of feeds for online vs offline builds. In a #2838 cloaking of repo-specific nuget.config files was suggested as part of the solution.

@MichaelSimons what are the current thoughts on available options, considering that some VMR plans might have changed in the meantime?

Cloaking the repo-specific nuget.config files works when there are no prebuilts. Even though we have eliminated prebuilts for the most part, there are some scenarios when they still occur. For example, a developer would like to do some cross cutting feature work in the VMR. If you remove the nuget.configs it would hurt the VMR UX as the build would stop on the first prebuilt. I personally see this as a blocker for this approach. Maybe others have different opinions.

Another approach mentioned in the past is to perform the NuGet.config manipulation during/within the inner clone. I don't think this is a viable option either given our long term plan of removing the inner clone within the VMR.

An ideal solution to me would permit dynamically modifying/swapping out the nuget configuration. Are there any msbuild or nuget control that can be utilized for this?

[mthalman]

I think what we might need here is the RestoreSources MSBuild property. I've never used it before, but it seems like that's a way to dynamically provide the feed locations we want to use for the build.

[NikolaMilosavljevic]

An ideal solution to me would permit dynamically modifying/swapping out the nuget configuration. Are there any msbuild or nuget control that can be utilized for this?

This would be the best - I'll investigate what's possible.

[NikolaMilosavljevic]

I think what we might need here is the RestoreSources MSBuild property. I've never used it before, but it seems like that's a way to dynamically provide the feed locations we want to use for the build.

Thanks - this looks promising. There are few more related properties that could be useful as well.

[ViktorHofer]

I think what we might need here is the RestoreSources MSBuild property. I've never used it before, but it seems like that's a way to dynamically provide the feed locations we want to use for the build.

Note that RestoreSources doesn't support authentication but I guess we don't need this here as we just point to a local folder?

[NikolaMilosavljevic]

I think we should be able to use RestoreConfigFile MSBuild propery. A quick test with a small .NET project showed that this works as expected. I'm going to test it in source-build next.

[NikolaMilosavljevic]

@MichaelSimons this is the place where we document multiple possible NuGet.config files: https://github.com/dotnet/installer/blob/3479076aac5f65a37f98c860659006ac45495ad1/src/SourceBuild/content/repo-projects/Directory.Build.targets#L59-L62

    <!-- Update the detected or manually specified NuGetConfigFile, but also allow multiple. -->
    <ItemGroup>
      <NuGetConfigFiles Include="$(NuGetConfigFile)" />
    </ItemGroup>

We do process them all in various tasks, in the same target.

I do not see this used in source-build infra. If we got rid of this, it would simplify the changes I'm making, but also simplify existing infra.

The only other place where we reference NuGet.config files is here, and it is only using the single instance: https://github.com/dotnet/installer/blob/3479076aac5f65a37f98c860659006ac45495ad1/src/SourceBuild/content/repo-projects/source-build-reference-packages.proj#L22

      NuGetConfigFile="$(NuGetConfigFile)"

[NikolaMilosavljevic]

Unfortunately, RestoreConfigFile property cannot work for projects that use different SDKs, i.e. Microsoft.Build.NoTargets or Microsoft.Build.Traversal.

MSBuild needs to restore the SDK before evaluating properties. It uses Microsoft.Buid.NuGetSdkResolver APIs, which only support default nuget.config probing paths. There is an issue tracking support of alternate nuget.config content: NuGet/Home#7855