Use Microsoft.AspNetCore.InternalTesting.csproj for _GetPackageVersionInfo

[wtgodbe]

There's no need to use a node project to calculate the nonstable package version of the repo during publishing - use Microsoft.AspNetCore.InternalTesting.csproj instead.

Related - #53091. @javiercn, is the commented-out portion of the target going to be used anywhere other than in publishing.props? If so we should separate that out into a separate target & name it something else.

[javiercn]

This is incorrect, isn't it?
https://github.com/dotnet/aspnetcore/pull/53152/files#diff-87ba8ac7845060f8e3f14f5fb637b6790e56ce05e5503d2b96293301339d3910L38

returns the correct item group.

[javiercn]

The other part is that this doesn't need to match <Output TaskParameter="TargetOutputs" ItemName="_ResolvedPackageVersionInfo" /> The TargetOuput here is provided in the Returns, ItemName is only where in the calling context the output needs to be placed, but they both don't have to match.

[wtgodbe]

Alright, then we must just not be setting PackageVersion in the node project anymore. There's no strong reason to use that project as far as I know, I'll try using dotnet-user-jwts.

[javiercn]

Related - #53091. @javiercn, is the commented-out portion of the target going to be used anywhere other than in publishing.props? If so we should separate that out into a separate target & name it something else.

I was keeping the structure as close as possible to what was there. I don't feel strongly about it either way.

The previous code was grabbing the version from the functional test project directly, which was a bit random.

I don't know exactly what the version info is being used for, so I just made sure we captured all the versions. In reality we version all the packages simultaneously.

In my view, if we are generating some sort of manifest, we should include the versions for all packages that we ship, just in case we break something and produce the wrong version.

[wtgodbe]

I don't know exactly what the version info is being used for, so I just made sure we captured all the versions. In reality we version all the packages simultaneously.

In my view, if we are generating some sort of manifest, we should include the versions for all packages that we ship, just in case we break something and produce the wrong version.

The comment below isn't entirely accurate:

https://github.com/dotnet/aspnetcore/blame/1c6c34733003e5236315b959d1729be2bf14968d/eng/Publishing.props#L57-L60

The target in which we call _GetPackageVersionInfo will return the PackageVersion only for the project on which we called it - then we use that package version to construct a path for publish files to be dropped in to. We chose an arbitrary nonshipping package for that, because we need a unique path per-build. We can't just use the PackageVersion property directly in publishing.props, because it hasn't been set yet by the time we get there, so we have to do it in a target. Historically the arbitrary nonshipping package we chose was an npmproj - I don't think there's any strong reason to keep trying to use the new nodeproj, hence why I suggested dotnet-user-jwts. Now that I think about it though, I think Microsoft.Aspnetcore.Testing makes more sense. I'm going to update this PR now & try a test internal build.

[javiercn]

The comment below isn't entirely accurate:

https://github.com/dotnet/aspnetcore/blame/1c6c34733003e5236315b959d1729be2bf14968d/eng/Publishing.props#L57-L60

The target in which we call _GetPackageVersionInfo will return the PackageVersion only for the project on which we called it - then we use that package version to construct a path for publish files to be dropped in to. We chose an arbitrary nonshipping package for that, because we need a unique path per-build. We can't just use the PackageVersion property directly in publishing.props, because it hasn't been set yet by the time we get there, so we have to do it in a target. Historically the arbitrary nonshipping package we chose was an npmproj - I don't think there's any strong reason to keep trying to use the new nodeproj, hence why I suggested dotnet-user-jwts. Now that I think about it though, I think Microsoft.Aspnetcore.Testing makes more sense. I'm going to update this PR now & try a test internal build.

Seems that we can rip the entire thing in that case.

[wtgodbe]

Test build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2345984&view=results

Seems that we can rip the entire thing in that case.

Agreed - #53153