I've got a small MSI that has an incorrect size reported in Add and Remove Programs. It's reporting the size to be the entire drive when it should be about 2k.

Anyone seen this and know a fix for it? I can't seem to find any KB articles on it.

Also, setting the ARPSIZE property has no effect.
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


I did a little googling and found this interesting tidbit about the whole add/remove "size" thing. Maybe it will help point you in the right direction.How does Add/Remove Programs get the size and other information?

If the program doesn't provide this information itself, Add/Remove Programs is forced to guess.

The problem is that there is no "obvious" way to map an entry in the Add/Remove Programs list to an actual program. Each entry in the list, for those who care about such things, comes from the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall registry key. The only mandatory properties for an uninstallable program are the DisplayName and the UninstallPath. Everything else is optional.

Let's suppose Add/Remove Programs is given a program registration like this:

DisplayName=REG_SZ:"Awesome Program for Windows"
UninstallPath=REG_SZ:"C:\WINDOWS\uninstall.exe -SomeParameters"

In order to get the "Last Used" and "Frequency" values, Add/Remove Programs needs to know the name of the EXE so it can ask the Start menu "Hey, how often did the user run this program, and when was the last time it happened?"

Notice that there are no clues in the registration above as to the identity of this EXE file.

So Add/Remove Programs starts guessing. It goes through all the programs on your Start menu and compares their names with the display name of the uninstallable item. It looks for Start menu items which share at least two words with the words in the DisplayName.

For example, if there were a Start menu item called "Pretty Decent Windows Program", this would count as a two-word match ("Windows" and "Program").

It then takes the one with the most matches and decides, "Okay, I guess this is it." Suppose for the sake of illustration that the best match is indeed "Pretty Decent Windows Program.lnk", which is a shortcut to "C:\Program Files\LitWare\Decent Program\Decent.exe". Add/Remove Programs would decide that "Awesome Program for Windows" should get the icon for "Pretty Decent Windows Program.lnk", that the frequency of use and most-recently-used information for "C:\Program Files\LitWare\Decent Program\Decent.exe" will be displayed for "Awesome Program for Windows".

But wait, there's more. There's also the program size. Add/Remove Programs looks in your "Program Files" directory for directories whose names share at least two words in common with the DisplayName. The best match is assumed to be the directory that the program files are installed into. The sizes are added together and reported as the size of "Awesome Program for Windows".

A program can add some properties to its registration to avoid a lot of this guessing. It can set an EstimatedSize property to avoid making Add/Remove Programs guess how big the program is. It can also set a DisplayIcon property to specify which icon to show for the program in the list.

But if a program omits all of these hints, the guess that Add/Remove Programs ends up making can often be ridiculously wide of the mark due to coincidental word matches. In my experience, Spanish suffers particularly badly from this algorithm, due to that language's heavy use of prepositions and articles (which result in a lot of false matches).

Yes, this is all lame, but when you are forced to operate with inadequate information, lame is the best you can do.

[July 15 2004: Emphasizing that this is done only if the program fails to provide the information itself. For some reason, a lot of people who link to this page fail to notice that little detail.]
posted on Friday, July 09, 2004 7:00 AM by oldnewthing
Note the "EstimatedSize" property. I don't have time to try it myself, but if it works let me know.

Edit: The reason I noticed this thread, is that I have a package doing the same thing. So I am giong to spend a minute or two trying my answer. I'll post back if I have any luck.
Answered 06/13/2005 by: BobTheBuilder
Purple Belt

Please log in to comment
I tested on a package that I have which was doing the same thing. I added the following registry key to the transform and it worked.


That set it to .29 MB

Set it to .70 MB

Set it to .95 MB

So I tried setting a Restricted Public Property
No love... back to the 4gig (where I started on my VM)
I also tried just setting this property
same result (no change).

I did not try setting the property with a custom action. I think I will just settle for hammering it into the registry at installation and be done with it.

Changing the value in the registry after installation did not make a difference to the add remove programs display once the app had been installed. The change was only reflected when I modified the transform and subsequently installed it.
Answered 06/13/2005 by: BobTheBuilder
Purple Belt

Please log in to comment
Thanks Bob. Those docs helped.
I ended up adding the reg key. I also found a thread that claimed increasing the file size to something larger than the drive's cluster size also helps. There is the ARPSIZE property, but that puts a value in a "Size" reg key, not the "EstimatedSize" key. No idea what "Size" is used for, it doesn't seem to do anything that I noticed. Adding an ARPESTIMATEDSIZE property did nothing, so no luck on the undocumented property theory.
Answered 06/14/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
I also have a support call in to Wise about this. If they have anything interesting to say, I'll post it.
Answered 06/14/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment