Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Internal Error 2771 while Minor upgrade


4 replies to this topic

aakash.tiwari12@gmail.com

aakash.tiwari12@gmail.com
  • Full Members
  • 34 posts

Posted 04 April 2014 - 07:36

Hi ,

 

i am getting Internal Error 2771 while minor upgrade.

 

Product id and Upgrade id is same for both the setup.

i have changed version to 1.0.0.1 from 1.0.0.0

But still it is giving me error. i have added upgrade guid into upgrade table also.

 

 

Thanks,

Aakash



Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 04 April 2014 - 10:02

From the MSI SDK: "...Note that Windows Installer uses only the first three fields of the product version. If you include a fourth field in your product version, the installer ignores the fourth field."

 

I would set the version to 1.0.1 and try again.

 

Stefan: does this restriction make sense to you? I find it odd and outdated. Many people would benefit from including the 4th digit - to account for daily builds and such. I suppose a change request to the MSI team has been submitted long ago?


Edited by Glytzhkof, 06 April 2014 - 16:04.

Regards
-Stein Åsmul

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 09 April 2014 - 12:05

I wish that Windows Installer would use all four fields of the version number. Personally I don't see any use in ignoring the fourth field. However I'm pretty sure this won't change after so many years.

The version number is most relevant in a Major Upgrade. Your Minor Update should work regardless, even if you don't change the version number at all (which would make it a "Small Update").

However, in a Minor or Small Update, you must follow the update rules. I guess you have removed a component from your setup (or moved the component to a different feature, or changed the component GUID (which sometimes happens with dynamic file links)) - this could also be a merge module you removed.



Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 09 April 2014 - 13:20

This ProductVersion restriction really is an odd construct. Maybe it has to do with the parsing of the Upgrade table? The third version digit is an unsigned integer or short, whereas the two first digits are unsigned bytes. From the SDK:

 

The first field is the major version and has a maximum value of 255. The second field is the minor version and has a maximum value of 255. The third field is called the build version or the update version and has a maximum value of 65,535.

 

 

Whatever the restriction is based on, it isn't great for today's daily build style development where people often seem to standardize on using the fourth digit for "qa only internal builds" whilst still delivering them internally via major upgrades, and then perhaps bumping up the third digit when a full QA is due for the whole product, and not just for new features and changes - an alfa, beta or gold release candidate setup.

 

This kind of release and team conventions are very important for collaboration and awareness in large and small teams alike. Anyone in release and configuration management will experience this, especially when you add to it delivering multiple versions of the product in different languages - then you realize that the version number standardization can be much more important than you first think. You generally also need a setup name that specifies language (and cpu type, and other things): Prod_1.2.3.12345-eng-x64.exe and then sign the setup with certificates when it is ready for public release.

 

 

If I were to chose how the ProductVersion would work I would go for:

255.255.255.65535 - or byte,byte,byte,uint (255.255.65535.65535 - seems excessive)

 

 

But this will never happen since it isn't backwards compatible with older setups. Explaining these version number restrictions to a team of developers is a challenge in and of itself.

 

In any event the "problem" with the three digit version number comes up as a question often enough to be a genuine usability issue with Windows Installer.


Edited by Glytzhkof, 09 April 2014 - 13:52.

Regards
-Stein Åsmul

chrpai

chrpai
  • Full Members
  • 26 posts

Posted 09 April 2014 - 13:48

Good morning my friends....

 

 

I don't like to stay at one company for too long.  I've gotten around over the years and have experience at 14 companies at last count vs 14 years experience at 1 company.  Lord knows how many clients I've had over that time.....  My point is that version schemes are like religious debates.   Asking Microsoft why they chose 0-255.0-255.0-65535 would be like asking God what His name is and expecting more then "I am that I am."   It simply can't be comprehended.   On a side note,  I recently did a project for a customer that had a legacy VB6 application that needed to be added to VSOnline (MSFT hosted TFS)  and I had to use the MSBuild Extension Packs to build the VB6 code.     VB6 only allows you to pass in three fields and the result is x.y.0.z....  Again... who knows why....

 

 My guess is they felt they needed to pick something and that was just the best they could come up with and all agree to.  After all these years it's immutable because if they change it they will break existing behavior.  That and I doubt they have funding to change anything anyways.  

 

 Here's the good news...  you can do it yourself.  Here's what I often do.  I write a row to the Upgrade table with a fake UpgradeCode GUID and set the Detect Only attribute.   Basically I know that FindRelatedProducts will never find anything.   I then author a very simple custom action after FindRelatedProducts that queries MSI and implements whatever business rules that I choose.  If I find a Product I author the ProductCode to the ActionProperty associated with the previous rows.    Then RemoveExistingProducts comes by and takes care of it.      Sure, it's a bit of plumbing  but I bypass the limitation and still use MSI to do the  heavy lifting.   It works for me.... :)


Edited by chrpai, 09 April 2014 - 13:51.

Christopher Painter, MCSE
Author of:
DeploymentEngineering.com
MSI Factory Provider for ADO.NET 2.0 (Work In Progress)
99 Bottles Of Beer - Windows Installer

PM for personal communication only. Please ask questions in the forums.