domingo, 25 de março de 2012 14:02
I've read about revising the File Version (and Assembly Version) to ensure that an updated file does replace an older/previous file when a WI update installation is carried out, but I don't understand the four-part construction of the File Version ... and my re-versioned files sometimes refuse to transfer to the target computer.
For example, a .exe I have recently updated had it's File Version set to 184.108.40.206 (it is resident now in my Program Files (x86)/MyApplication folder) and File Date 23/03/2012, but even now with the File Version set to 220.127.116.11 and a File Date of 24/03/2012 when I use WI to install the new program over the original the 18.104.22.168 file remains in place and the new 22.214.171.124 file does not get installed instead. Why?
I read that the protocol is:
Major priority: File Version
2nd priority: File date
3rd priority: Language
My file language is unchanged, the file date is a function of compile time, but what is the relevance or priority of the four elements of the File Version and how should they be used to drive updating in a secure manner? What should I do to my File Version to make the updated file replace the earlier one? The VS Help Viewer says "Highest Version Wins—All other things being equal, the file with the highest version wins, even if the file on the computer has the highest version." So - referring to the four element File Version string, what is higher or lower than what?
Todas as Respostas
terça-feira, 27 de março de 2012 02:48Moderador
terça-feira, 27 de março de 2012 12:44
I have found my mistake - I was simply not careful enough targeting the right build folder when inserting links into my File System. Lesson learned ...
Can I take it then that a "higher" file version is simply detected by reading the four number elements from left to right, with cascaded natural / numeric superiority for precedence?
- Marcado como Resposta Shanks ZenMicrosoft Contingent Staff, Moderator segunda-feira, 9 de abril de 2012 03:16