Update DiaSymReader.Converter package versions

[ViktorHofer]

These updated packages aren't targeting netstandard1.x anymore and use latest dependencies that don't have any flagged transitive vulnerabilities. That will reduce the number of NuGet Audit warnings in this repo significantly.

Microsoft Reviewers: Open in CodeFlow

Context: Roslyn currently has 672 NuGet Audit warnings in the VMR build: https://gist.github.com/ViktorHofer/0663836156a49e1fc6c6abde17668546

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

This PR updates the centrally-managed NuGet package versions for Microsoft.DiaSymReader.Converter and Microsoft.DiaSymReader.Converter.Xml in Roslyn’s eng/Packages.props, affecting restores for the few internal tool/test projects that reference these packages.

Changes:

• Bump Microsoft.DiaSymReader.Converter from 1.1.0-beta2-26119-01 to 1.1.0-beta2-26372-02.
• Bump Microsoft.DiaSymReader.Converter.Xml from 1.1.0-beta2-26119-01 to 1.1.0-beta2-26372-02.

Show a summary per file

File	Description
eng/Packages.props	Updates the centrally-managed versions of the DiaSymReader converter packages used by internal tool/test projects.

Copilot's findings

• Files reviewed: 1/1 changed files
• Comments generated: 0

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 1

[ViktorHofer]

@jjonescz can we update runtime dependencies from 10.0.8 to 10.0.10 or are the restrictions behind that?

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[Copilot]

Copilot's findings

Comments suppressed due to low confidence (1)

eng/Version.Details.props:17

• The dotnet/dotnet package version bumps in Version.Details.props (e.g., Microsoft.Bcl.AsyncInterfaces 10.0.10, System.* 10.0.10) don't match the corresponding dependencies still pinned in eng/Version.Details.xml (they remain at 10.0.8, including ToolsetDependencies/System.Composition). This leaves the repo in an inconsistent state: MSBuild consumes the props values, while dependency-flow/source-build metadata still references the older versions.

Please align eng/Version.Details.xml with these new versions (or regenerate Version.Details.props so it matches the current Version.Details.xml) so both files agree.

    <MicrosoftBclAsyncInterfacesPackageVersion>10.0.10</MicrosoftBclAsyncInterfacesPackageVersion>
    <MicrosoftExtensionsConfigurationPackageVersion>10.0.1</MicrosoftExtensionsConfigurationPackageVersion>
    <MicrosoftExtensionsDependencyInjectionPackageVersion>10.0.1</MicrosoftExtensionsDependencyInjectionPackageVersion>
    <MicrosoftExtensionsFileSystemGlobbingPackageVersion>10.0.1</MicrosoftExtensionsFileSystemGlobbingPackageVersion>
    <MicrosoftExtensionsLoggingPackageVersion>10.0.1</MicrosoftExtensionsLoggingPackageVersion>

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[jjonescz]

can we update runtime dependencies from 10.0.8 to 10.0.10 or are the restrictions behind that?

Sounds okay to me, although we should probably run a validation vs insertion before merging.

I'm also wondering why these don't update with automatic flow from VMR since they seem to be tracked in Version.Details.xml?

[ViktorHofer]

I'm also wondering why these don't update with automatic flow from VMR since they seem to be tracked in Version.Details.xml?

Version.Details.xml is an input to both Maestro (PCS - product construction service) and the VMR inner dependency flow (msbuild infra inside dotnet/dotnet). Maestro only ever touches Version.Details.xml entries when you have a subscription configured. The file alone doesn't make it do anything.

For the VMR inner dependency flow, those entries are there so that the VMR understands that these are product dependencies. It depends on whether roslyn has a live product dependency on runtime inside the VMR (which it doesn't have for non-source-build but it does for source-build).

• Live dependency: Roslyn builds after runtime and gets the live product assets (via version properties that automatically get imported).
• Non-live-dependency: The hardcoded version in Version.Details.props is used (nothing gets overwritten) unless you are building from source, then the previously-source-built version gets automatically injected (via the same mechanism as the live dependency version).

[Copilot]

Copilot's findings

• Files reviewed: 8/8 changed files
• Comments generated: 0 new

[ViktorHofer]

@tmat can you please dismiss your change request so that we can merge the PR?

[tmat]

@ViktorHofer Did we run val build to confirm the version updates are ok for VS insertion?

[ViktorHofer]

VS main is already on 10.0.10. Isn't that sufficient? I have no idea how to trigger a roslyn specific validation insertion build.

[tmat]

/pr-val

[tmat]

VS main is already on 10.0.10. Isn't that sufficient? I have no idea how to trigger a roslyn specific validation insertion build.

Yes, it should. But it's better to make sure. I kicked off val build.

[github-actions]

View PR Validation Run triggered by @tmat

Parameters

• Validation Type: pr-val
• Pipeline ID: 8972
• Pipeline Version: main
• PR Number: 84614
• Commit SHA: e960df5d0c49f7fa6184e9e5d5b1441891441393
• Source Branch: ViktorHofer-patch-1
• Target Branch: main
• Build ID: 14881259

[ViktorHofer]

Publish using darc failed

[JoeRobich]

Publish using darc failed

I think there was a PAT that got rotated earlier today.

Nope, definitely something new.

[JoeRobich]

Insertion PR: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/766802

[ViktorHofer]

Thanks. I'm not able to interpret the results. I will let you handle the decision and the merge :)

[ViktorHofer]

Gentle ping. Can we merge the PR in? Resolves a bunch of NuGet Audit warnings that show up in the VMR.