Visual studio setup project and MSBuild (again)

Question

Visual studio setup project and MSBuild (again)

AdamS 0

Hi,

We're trying to get rid of VS from Jenkins and use MSBuild exclusively, but we have an installer project. I know MSBuild doesn't support .vdproj, so there's no way to make it work. We have a custom UI and a lot of custom actions, so switching to Wix would be quite a challenge. Instead, I wrote a tool to parse vdproj file and populate the schema.msi. The only problem is that I can't figure out how the "ComponentId" in the "Component" table is calculated. Ideally, I'd like to get the same value on both builds: local (installer) and Jenkins (msbuild). It looks it's a combination of the upgrade code, path, and filename, but I've tried different order/hash implementations but can't get the same value.

Could you provide some details how it's calculated and which hash function i should use?

Jay Pham (WICLOUD CORPORATION) 3,905 Reputation points Microsoft External Staff Moderator

2026-07-22T01:05:11.13+00:00

We are currently investigating the issue and will provide an update soon. Thank you for your patience.

2 answers

Your answer

Jay Pham (WICLOUD CORPORATION) 3,905 Reputation points Microsoft External Staff Moderator

2026-07-22T01:05:11.13+00:00

We are currently investigating the issue and will provide an update soon. Thank you for your patience.

Answer 1

kagiyama yutaka 4,835

I think Windows Installer keeps ComponentId as the GUID in the MSI Component table, and Visual Studio’s vdproj already stores that GUID for each component. So matching VS and Jenkins just means reading that ComponentId from the vdproj and using the same GUID when you build ur MSI. Visual Studio does not compute ComponentId during the build; it simply copies the GUID already stored in the vdproj into the MSI Component table.

0 comments

Answer 2

Nancy Vo (WICLOUD CORPORATION) 7,985 Microsoft External Staff Moderator

Hello @AdamS ,

Thanks for your question.

It appears that the specific algorithm and hash function Visual Studio uses to calculate the ComponentId in a .vdproj file is an internal implementation detail. This formula does not seem to be publicly documented.

I recommend not trying to reverse-engineer these internal IDs, as they may change over time.

You can refer to these following approaches:

Although there are efforts to move away from this approach, invoking devenv.exe from the command line on a Jenkins server may still be a practical option for building .vdproj files, since it is designed to handle the associated ID generation processes. For a longer-term approach, while switching to WiX may be challenging due to your custom UI requirements, it is often recommended for teams that want to use MSBuild exclusively.

I hope this addresses your question. If this response was helpful, please consider following the guidance to provide feedback. Thank you.

Nancy Vo (WICLOUD CORPORATION) 7,985 Reputation points Microsoft External Staff Moderator

2026-07-27T02:31:45.94+00:00

Hi @AdamS ,

I wonder if there is any update on this post. If you have any question, feel free to reach out. I'm happy to support you.
AdamS 0 Reputation points

2026-07-27T10:34:16.79+00:00

Hi @Nancy Vo (WICLOUD CORPORATION) We are getting rid of devenv.com to reduce the cost, so using it is not an option. This setup project was finished and tested, so would need a good business case to rewrite in wix. If this is crc32 I could reverse engineer it, but with 128 I would need to know the algo. If this is internal implementation I'm assuming you are not going to share the details. So my only option is to use md5 in my "tool". If I understand correctly the only downside is that will force all files reinstallation on next upgrade.
Nancy Vo (WICLOUD CORPORATION) 7,985 Reputation points Microsoft External Staff Moderator

2026-07-28T06:22:03.3333333+00:00

Hi @AdamS ,

You're on the right track, but a forced reinstallation on the next upgrade isn't the only downside. Once you switch to your own ID scheme, patch updates (.msp files) will no longer be possible, since Windows Installer requires Component IDs to stay identical between versions. If any files are shared with other applications, changing the Component IDs will also break Windows reference counting, which may remove files still needed by other programs or leave orphaned files behind. This change is also effectively one-way - reverting later would trigger the same upgrade behavior again.
Nancy Vo (WICLOUD CORPORATION) 7,985 Reputation points Microsoft External Staff Moderator

2026-07-30T02:18:50.2766667+00:00

Hi,

I wonder if there is any update on this post. If you have any question, feel free to reach out. I'm happy to support you.
Nancy Vo (WICLOUD CORPORATION) 7,985 Reputation points Microsoft External Staff Moderator

2026-08-03T02:13:15.52+00:00

Since I haven’t received any recent updates, I’ll go ahead and close this thread for now. If you still need assistance, please feel free to reach out at any time. I’ll be happy to help.

Thank you.