build.cmd and VS builds have different 'packages' folders

[mschofie]

build.cmd restores and builds with a specific packages directory:

call .nuget\nuget.exe restore "%%D" -configfile Samples\nuget.config -PackagesDirectory %~dp0packages
call msbuild /warnaserror /p:platform=%platform% /p:configuration=%configuration% /p:NugetPackageDirectory=%~dp0packages /bl:"%%~nD.binlog" "%%D"

which resolves to be :/packages. It's trying to amortize the C++ 'packages' directories for all of the solutions, which would help with disk usage and restore times. But since vcxproj's need to address the contents of the unpackaged NuGet packages, then the .vcxproj's would need to agree on the path to the 'packages' folder, and since it would be different between a build.cmd build and a Visual Studio IDE build, then there would need to be parameterization. But there isn't; I'm seeing build errors from build.cmd builds saying that the restore was successful but the vcxproj is failing to find files in the NuGet. For example, Samples\BackgroundTask\OutOfProc BackgroundTask\cpp-winui\BackgroundTaskBuilder\BackgroundTaskBuilder.vcxproj contains:

    <Error Condition="!Exists('..\packages\Microsoft.Windows.CppWinRT.2.0.240405.15\build\native\Microsoft.Windows.CppWinRT.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.Windows.CppWinRT.2.0.240405.15\build\native\Microsoft.Windows.CppWinRT.props'))" />

With a 'build.cmd' restore, the 'packages' folder would be :/packages, and with a Visual Studio build it would be relative to the .sln file (Samples\BackgroundTask\OutOfProc BackgroundTask\cpp-winui\BackgroundTask_WinAppSDK.sln), so :/Samples/BackgroundTask/OutOfProc BackgroundTask/cpp-winui/packages.

It would be great to have consistent 'packages' folder for all .sln files, and all builds - that would be possible by setting the repositoryPath in the :/Samples/nuget.config file, and removing the logic from build.cmd. But that would require fixing up all of the paths in the .vcxproj files, and that seems like a lot of churn.

[mschofie]

Ah.. Some samples are parameterized, :/Samples/DynamicDependenciesSample/DynamicDependencies/DirectX/D3D9ExSample.vcxproj says:

  <PropertyGroup>
    <!-- When building centrally, this will define a single nuget package location for all samples -->
    <NugetPackageDirectory Condition="'$(NugetPackageDirectory)'==''">packages</NugetPackageDirectory>
  </PropertyGroup>
  <Import Project="$(NugetPackageDirectory)\Microsoft.WindowsAppSDK.1.5.240227000\build\native\Microsoft.WindowsAppSDK.props" Condition="Exists('$(NugetPackageDirectory)\Microsoft.WindowsAppSDK.1.5.240227000\build\native\Microsoft.WindowsAppSDK.props')" />

The parameterization makes it tidier to see what's going on, TBH.

[mschofie]

But it looks like Visual Studio won't update parameterized Imports to NuGet artifacts when updating NuGet versions. Sad.

[adrastogi]

But it looks like Visual Studio won't update parameterized Imports to NuGet artifacts when updating NuGet versions. Sad.

Indeed, we've stumbled on this with some of the Windows ML samples- the process is a little cumbersome (I can't remember exactly at this point, but I believe it involved temporarily making the project imports relative, loading things in VS and having VS do the updates, and then finally restoring the macro). If there's a better way of managing this, would love to know (cc: @Scottj1s)

[mschofie]

I think the right answer is:

1. Force all samples to use the same packages folder - regardless of how they're built - by setting <add key="repositoryPath" value="packages" /> in the :/Samples/nuget.config.
2. Stop passing -PackagesDirectory to nuget.exe and /p:NugetPackageDirectory to msbuild.exe in :/build.cmd.
3. Fix all Import paths to be relative - non-parameterized - paths to the :/Samples/packages folder.