Visual Studio 2019 catalog: what does packages[].payloads[].size measure?

Question

Visual Studio 2019 catalog: what does packages[].payloads[].size measure?

Mbulelo Dlangamandla 0

Hello,

I am seeking an authoritative explanation of packages[].payloads[].size in the Visual Studio installation catalog.

The recorded observations concern catalog identity VisualStudio/16.11.43+35706.149. For the following four packages, the catalog payload size agrees with the corresponding local _package.json value but differs numerically from the observed length of the complete local payload.vsix file:

Package ID: Microsoft.VisualCpp.CodeAnalysis.ConcurrencyCheck.X64. Package version: 14.29.30156. Catalog and _package.json payload size (unit to be clarified): 1095. Complete local payload.vsix length: 8744 bytes.

Package ID: Microsoft.VisualCpp.CodeAnalysis.Extensions.X64. Package version: 14.29.30156. Catalog and _package.json payload size (unit to be clarified): 1090. Complete local payload.vsix length: 8759 bytes.

Package ID: Microsoft.VisualCpp.Tools.HostX64.TargetX64. Package version: 14.29.30158. Catalog and _package.json payload size (unit to be clarified): 2245. Complete local payload.vsix length: 10145 bytes.

Package ID: Microsoft.VisualCpp.Tools.HostX64.TargetX86. Package version: 14.29.30158. Catalog and _package.json payload size (unit to be clarified): 2283. Complete local payload.vsix length: 10192 bytes.

In all four cases, the calculated SHA-256 of the complete local VSIX file matched the previously recorded catalog payload sha256 value. This hash comparison did not use the catalog size value as a pass criterion.

Could someone clarify the following?

Unit: Is payloads[].size expressed in bytes or another unit?
Referenced object: Does it describe the complete downloadable VSIX file, an unsigned package, selected archive contents, installed content, or another object?
Measurement stage: At which packaging or signing stage is this value calculated, and is it updated when the payload changes?
Expected relationship: Should this value equal the complete local VSIX file length when the file’s SHA-256 matches the catalog payload hash? If exceptions exist, what documented rule applies?

Please provide an authoritative Microsoft schema, documentation reference, or published implementation applicable to this catalog version.

This is a request for clarification of catalog metadata, not a report of a confirmed installation failure. The observations do not establish that the files are corrupted. Package signatures have not been verified, and the catalog’s origin has not been authenticated.

The reference to Visual Studio 2019 identifies the catalog under examination; it does not assert that a particular Visual Studio edition is installed.

Thank you.

0 comments

2 answers

Your answer

Answer 1

Hi @Mbulelo Dlangamandla ,

Thank you for the detailed report. I understand that the catalog payload size matches the corresponding local _package.json value but not the complete VSIX file length, while the SHA-256 value does match the complete VSIX file.

Your question is therefore not about a confirmed installation or corruption issue, but about the metadata contract for payloads[].size: its unit, the object being measured, the stage at which it is calculated, and its expected relationship to the final VSIX file.

However, I could not find any public documentation that defines this field, as it appears to relate to the internal implementation of the Visual Studio setup catalog. Microsoft Q&A is a community-based support platform. While the community can assist with general installation, setup, and troubleshooting questions based on publicly available documentation, it does not provide the same access to internal implementation details as the Visual Studio product team.

For an authoritative explanation of this metadata, I recommend submitting your question directly to the Visual Studio Developer Community, where the relevant product team may review and triage it.

If you have an eligible Visual Studio subscription, you can submit a support ticket for advanced assistance, such as a 1:1 consultation, remote support, or a Teams meeting with a support engineer. This is an effective way to resolve your concern. I hope this helps clarify what can be concluded from the available evidence.

If you have any questions about how to create the Developer Community report or open a support case, please leave a comment here and I will be happy to provide further guidance. Otherwise, I would greatly appreciate it if you could follow this guide. Thank you.

Answer 2

No public Microsoft schema or published Microsoft-maintained implementation in the available documentation defines packages[].payloads[].size for the Visual Studio 2019 16.11 catalog, so it cannot authoritatively be interpreted as the byte length of payload.vsix or assigned to a particular signing stage.

What can be concluded

The four size values are not the complete local VSIX lengths in bytes: the recorded values differ from the filesystem lengths.
Because each SHA-256 matches when calculated over the complete local payload.vsix, the corresponding catalog sha256 identifies the complete byte sequence of that local file.
That hash match does not establish that the adjacent size property measures the same object. Fields within one payload record may have been generated at different pipeline stages or retained for different installer purposes.
Agreement between the catalog and _package.json shows that the value is propagated consistently between those two metadata locations; it does not reveal its unit or semantic definition.
Nothing in these observations establishes corruption. They also do not authenticate the catalog or verify the VSIX signature.

A VSIX is an Open Packaging Conventions package containing binaries, supporting files, [Content_Types].xml, and a VSIX manifest—not merely its installed content.^1^ Microsoft’s signing documentation confirms that signing applies to the VSIX package and protects its contents, but it does not document how Visual Studio setup generates or updates the catalog’s payloads[].size field.^2^

Answers to the four questions

Question	Supported answer
Unit	Not publicly specified for this Visual Studio catalog field. It should not be labelled “bytes” solely because it is an integer named `size`.
Referenced object	Not publicly specified. The data disproves equality with the complete local VSIX byte length for the four examples, but does not distinguish an unsigned artifact, selected archive members, installed content, compressed content, or another internal measure.
Measurement stage	Not publicly specified. The available VSIX signing documentation does not connect this catalog property to a pre-signing or post-signing operation. Therefore, “pre-signing size” remains a hypothesis rather than a documented explanation.
Expected relationship to the hashed file	No documented rule applicable to Visual Studio 2019 16.11 establishes that `payloads[].size` must equal the length of the object covered by `payloads[].sha256`. For these samples, it demonstrably does not, despite the hash match.

The similarly named Microsoft NuGet catalog does explicitly define packageSize as the .nupkg size in bytes,^3^ but that is a different schema and cannot be transferred to the Visual Studio installation catalog. Likewise, Microsoft’s “Product and package schema reference” documents the MSBuild bootstrapper’s XML product/package format, not the Visual Studio Installer catalog JSON containing packages[].payloads[].^4^

Appropriate authoritative next step

Request clarification from the Visual Studio Setup engineering team through a Visual Studio Feedback ticket or Microsoft support case. Include:

Catalog identity VisualStudio/16.11.43+35706.149.
The four package IDs and versions.
The exact catalog payload objects, including fileName, url, size, and sha256.
The matching _package.json records.
Filesystem lengths and independently calculated SHA-256 values.
The precise questions: unit, measured object, generation stage, update rule, and whether Setup treats the field as validation data.

Ask specifically for the Visual Studio Installer catalog schema or the producer/consumer contract applicable to the 16.11 servicing channel. Without that contract or confirmation from the owning engineering team, assigning a pre-signing interpretation would be reverse engineering rather than an authoritative answer.

References