<_BuiltArcadeSdkPackageVersion>$([System.String]::new('%(_BuiltArcadeSdkPackage.FileName)').Substring($([MSBuild]::Add($(_ArcadeSdkName.Length), 1))))</_BuiltArcadeSdkPackageVersion>

I think it would be better to retrieve that information from Arcade's build manifest which is already available at that time. The XmlPeek msbuild task allows that. The manifest(s) are stored here:

We will do the same for baseline testing the produced nuget packages but with the merged vertical manifest as an input. Here we just need the Arcade build manifest(s).

EDIT: I also just filed dotnet/source-build#4297. It would be great if you could fix the NoTargets and Traversal versions as part of this. They will need the same treatment in the new target.

All this doesn't need to be perfect as we will eventually get rid of all this when we have the necessary NuGet support.

<_BuiltArcadeSdkPackageVersion>$([System.String]::new('%(_BuiltArcadeSdkPackage.FileName)').Substring($([MSBuild]::Add($(_ArcadeSdkName.Length), 1))))</_BuiltArcadeSdkPackageVersion>

I think it would be better to retrieve that information from Arcade's build manifest which is already available at that time. The XmlPeek msbuild task allows that. The manifest(s) are stored here:

installer/src/SourceBuild/content/repo-projects/Directory.Build.props

Line 41 in 144a405

<RepoAssetManifestsDir>$([MSBuild]::NormalizeDirectory('$(AssetManifestsIntermediateDir)', '$(RepositoryName)'))</RepoAssetManifestsDir>

We will do the same for baseline testing the produced nuget packages but with the merged vertical manifest as an input. Here we just need the Arcade build manifest(s).

EDIT: I also just filed dotnet/source-build#4297. It would be great if you could fix the NoTargets and Traversal versions as part of this. They will need the same treatment in the new target.

All this doesn't need to be perfect as we will eventually get rid of all this when we have the necessary NuGet support.

I agree with using the merged manifests eventually but we could do it in one fell swoop and change the other PackageVersion*.props generation to work off the manifests at the same time. That said, there are still two scenarios and we unfortunately can't drive everything off of the merged manifests:

• Generation of new PVPs or extra version props based on the output of previous repo builds - This can probably be driven by the merged manifests. One exception here may be source-build-reference-packages. /cc @dotnet/source-build-internal
• Generation of previously SB props files based on an input directory of packages - We can't rely on the exist of merged manifests for this case.

I don't love the current path manipulation approach above but I'm fine with it as a temporary measure (please include a comment and issue link)

I have an idea of how to make this all work cleanly though asset manifest inspection (and in general update how we look at dependencies), but I'll do that in a follow-up PR.

I have an idea of how to make this all work cleanly though asset manifest inspection (and in general update how we look at dependencies), but I'll do that in a follow-up PR.

Sounds good. Please file an issue so that we can discuss that.

I have an idea of how to make this all work cleanly though asset manifest inspection (and in general update how we look at dependencies), but I'll do that in a follow-up PR.

Sounds good. Please file an issue so that we can discuss that.

Filed dotnet/source-build#4302