Description
Problem
When building and packing the MVVM SourceGenerator projects, pack fails to find the output artifacts when we use custom output paths. This is observed in #96 when I tried to use a common output path for building the entire solution. I could update the current method to find the artifacts but it feels hacky and not integrated with the build pipeline.
Thus, any change like changing the output paths not just in the build definition but also changing via terminal invocation (say dotnet build -o path_to_out_dir) will definitely break the build and it won't pack those files. Worst of all, sometimes, the build pipeline won't fail. So, we won't know if the MVVM package was properly packed.
To Reproduce
- Clone the repo or clean it
git clean -Xdf - Build MVVM SourceGenerator project (with a different output path).
dotnet build CommunityToolkit.Mvvm.SourceGenerators -o bin_dir - Pack the MVVM project (with a different output path).
dotnet pack CommunityToolkit.Mvvm -o pkg_dir
Result
| Expected | Actual |
|---|---|
| Build and pack should have succeeded and the outputs of the MVVM SourceGenerator project should be in the target path of NuGet package generated from the MVVM parent project. | Pack in the final step fails (in a clean repo but succeeds when older artifacts are present). When it does succeed, we either find the older artifacts or no artifacts in the NuGet package of the parent MVVM project. |
Solution
Get the build outputs dynamically via GetBuildOutputs MSBuild target mirroring NuGet's Pack targets and add it to pack via _PackageFiles internal MSBuild item used by NuGet's Pack targets. This is brittle only if @NuGet team decides to modify/remove _PackageFiles which is highly unlikely.
One interesting side-effect of this implementation is that when we decide to multi-target, we can easily modify our solution to be more resilient without having to tackle the problem again since we already output the artifacts by TFM. This should save hours of headbutting against the wall 😉!!