ResolveNuGetPackageAssets fails when packaging and application projects share a directory

[SpareSimian]

Failing minimal project here: https://github.com/SpareSimian/ResolveNuGetPackageAssetsIssue

I just created a basic Hello World console app, added a "HeatWave project" (presumably really a Wix4 project, which was initially installed to a sibling directory and worked), and then moved the Wix4 project into the same directory as the sample console app. I edited the solution and WiX4 files to eliminate the "..\Package1". The result blows up with the errors below.

I'm using VS2022 on Win10 x64 with WiX.exe 5.0.2+aa65968c.

I have an ancient WiX 3 project I'm trying to update and I've been watching Rob's Deployment Dojo videos to make it happen. But I'm seeing this error in the application project which doesn't use any NuGet packages. I think the msbuild project synthesized from the solution file is injecting NuGet checks into the dependency.

Sample output:

Build started at 3:14 PM...
1>------ Build started: Project: ConsoleApplication1, Configuration: Debug x64 ------
1>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\NuGet\17.0\Microsoft.NuGet.targets(198,5): error : Sequence contains no elements
1>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\NuGet\17.0\Microsoft.NuGet.targets(198,5): error :    at System.Linq.Enumerable.First[TSource](IEnumerable`1 source)
1>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\NuGet\17.0\Microsoft.NuGet.targets(198,5): error :    at Microsoft.NuGet.Build.Tasks.ResolveNuGetPackageAssets.GiveErrorForMissingFramework()
1>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\NuGet\17.0\Microsoft.NuGet.targets(198,5): error :    at Microsoft.NuGet.Build.Tasks.ResolveNuGetPackageAssets.GetTargetOrAttemptFallback(JObject lockFile, Boolean needsRuntimeIdentifier)
1>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\NuGet\17.0\Microsoft.NuGet.targets(198,5): error :    at Microsoft.NuGet.Build.Tasks.ResolveNuGetPackageAssets.GetReferences(JObject lockFile)
1>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\NuGet\17.0\Microsoft.NuGet.targets(198,5): error :    at Microsoft.NuGet.Build.Tasks.ResolveNuGetPackageAssets.ExecuteCore()
1>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\NuGet\17.0\Microsoft.NuGet.targets(198,5): error :    at Microsoft.NuGet.Build.Tasks.ResolveNuGetPackageAssets.Execute()
1>Done building project "ConsoleApplication1.vcxproj" -- FAILED.
2>------ Build started: Project: Package1, Configuration: Debug x64 ------
2>Package1 -> F:\devel\DojoDeployment\NuGetTest\ConsoleApplication1\bin\x64\Debug\en-US\Package1.msi
========== Build: 1 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
========== Build completed at 3:14 PM and took 07.802 seconds ==========

[robmen]

.vcxproj is notoriously naive when it comes to NuGet integration and has not kept up with modern MSBuild concepts at all. Sdk-style projects are the perfect storm of newness to confuse .vcxproj. So, I'm not terribly surprised that it fails pretty spectacularly.

In the end, don't mix your projects like that and definitely don't mix .vcxproj like that. Keep .vcxproj on the leaves of your build tree as much as possible.

FWIW, I've never seen anyone merge projects like you have done here... and I've seen some pretty crazy things done with MSBuild. :)

[SpareSimian]

It never occurred to me that projects need to be in different directories. This started back in the days of workspace and vsproj and probably WiX 2. Since the project files had different extensions, and different tooling, I figured, they'd just coexist, and they did. Only with WiX 4+ and the arrival of NuGet do I see this weirdness brought on by shared state in their common obj subdirectory. Oh, and I've always had the solution file in the same directory as the main application vcxproj, since VC6 days.

I'm not opposed to moving all the installer projects to a sibling directory. (I have separate installers for each customer and for each supported compiler. Only one compiler version gets built, but all customer installers do. They differ in one configuration file that describes the physical product that the software controls.)

[robmen]

IIRC, WiX v2 was before MSBuild. So there was no standard way to integrate it into your build system. We made sure it'd work with NMAKE, NAnt, and other systems that don't exist today. :)

I think it was MSBuild that really formalized the one project per-directory behavior. And today, as you noted, shared obj folders are completely broken.

That's a blast from the past.

[SpareSimian]

The one to worry about is CMake, as it's favored across platforms and even Visual Studio supports it. I'm trying to get up to speed with it by reading a thick tome from one of its developers. https://crascit.com/professional-cmake/