templating
templating copied to clipboard
dotnet
Update the nuget version to the latest and update STJ to the in-product one that's being used already in most of the build here
I tried just updating to 8.0.5 but I found that much of the build was already implicitly targeting 9.0.3. So instead, I just retargeted to that. Not sure if this will have negative impact on SDK or VS though so will need to consult on that.
I could just move the edge assembly as that was the only one flagged by CG or I could get nuget to fix their reference.
@dotnet/source-build-internal another case where I have to add a bunch of items to SBRP? Annoying to have to do this with each nuget update.
See https://aka.ms/dotnet/prebuilts for guidance on what pre-builts are and how to eliminate them. Package IDs are: NuGet.Common.6.12.4 NuGet.Configuration.6.12.4 NuGet.Credentials.6.12.4 NuGet.Frameworks.6.12.4 NuGet.Packaging.6.12.4 NuGet.Protocol.6.12.4 NuGet.Versioning.6.12.4 System.IO.Pipelines.9.0.3 System.Text.Encodings.Web.9.0.3 System.Text.Json.9.0.3
@dotnet/source-build-internal another case where I have to add a bunch of items to SBRP? Annoying to have to do this with each nuget update.
Yes, the NuGet packages need to be added to SBRP. I understand the frustration. Unfortunately, the VMR isn't configured for the templating repo to depend on the nuget-client repo, which means that there's no live version of NuGet to flow in. No live flow means that these packages must be defined in SBRP.
Yes, the NuGet packages need to be added to SBRP. I understand the frustration. Unfortunately, the VMR isn't configured for the templating repo to depend on the nuget-client repo, which means that there's no live version of NuGet to flow in. No live flow means that these packages must be defined in SBRP.
Would it be feasible for templating to depend on the live version for source-build? e.g. can a V.D.xml dependency be declared on NuGet but not have a darc subscription for it?
Yes, the NuGet packages need to be added to SBRP. I understand the frustration. Unfortunately, the VMR isn't configured for the templating repo to depend on the nuget-client repo, which means that there's no live version of NuGet to flow in. No live flow means that these packages must be defined in SBRP.
Would it be feasible for templating to depend on the live version for source-build? e.g. can a V.D.xml dependency be declared on NuGet but not have a darc subscription for it?
This would change the build order, so as long as nuget-client doesn't require packages from repos downstream of templating, I think it would be okay. I can test in the VMR.
This would change the build order, so as long as nuget-client doesn't require packages from repos downstream of templating, I think it would be okay. I can test in the VMR.
I am not proposing that a project dependency be added in SB. If the V.D.xml dependency is added and the project is built before nuget, it will pickup the n-1 version. I am assuming these don't get bundled because of the use of SBRP packages today so this should be fine.
This would change the build order, so as long as nuget-client doesn't require packages from repos downstream of templating, I think it would be okay. I can test in the VMR.
I am not proposing that a project dependency be added in SB. If the V.D.xml dependency is added and the project is built before nuget, it will pickup the n-1 version. I am assuming these don't get bundled because of the use of SBRP packages today so this should be fine.
I completely forgot about PSB artifacts for a moment. You're right, this should work. I'll update version details
I completely forgot about PSB artifacts for a moment. You're right, this should work. I'll update version details
That change really should be validated in the context of the VMR as well. You could easily do that in the 9.0 branch of the VMR by opening a PR with only that change.
The only thing I'm not sure if is if updating V.D.xml will impact the flow to sdk. The SDK repo ends up on the same sha nuget but it's an unstable version rather than stable version. I don't know if we'll end up with downgrade errors (as they are technically preview versions so "older") when trying to flow to sdk or if CPM will handle that.
@ellahathaway were you going to try updating V.D.xml or want me to do it? I don't want to add the extra subscription as that adds to our build graph for releases but I can update that manually after release day for future nuget msrcs
@ellahathaway were you going to try updating V.D.xml or want me to do it?
Testing in https://github.com/dotnet/dotnet/pull/1135
@marcpopMSFT - the VMR validation passed. These are the changes you need. The prebuilts will continue to pop up in repo-level build (eg in this current PR), so you'll also have to add exclusions to the prebuilt baseline for those. Let me know if you'd me to port these changes over for you. Thanks :)
@ellahathaway I copied your changes exactly but I noticed it includes some extra System.* version changes beyond STJ. Are those needed?
Asked another way, were the SystemIOPipelinesVersion SystemTextEncodingsWebVersion changes needed as those are now in the prebuilt list as well? I was making sure this built without the prebuild exclusions first and was now going to update that list but wanted to ensure I had the right list.
@ellahathaway I copied your changes exactly but I noticed it includes some extra System.* version changes beyond STJ. Are those needed?
Asked another way, were the SystemIOPipelinesVersion SystemTextEncodingsWebVersion changes needed as those are now in the prebuilt list as well? I was making sure this built without the prebuild exclusions first and was now going to update that list but wanted to ensure I had the right list.
Yes, all those changes are needed and the existing prebuilts should be added to the prebuilt baseline file.
Ok, updated based on the feedback. Let's see if it passes the checks and can merge for next month