<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:admin="http://webns.net/mvcb/"
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
   xmlns:wfw="http://wellformedweb.org/CommentAPI/"
   xmlns:content="http://purl.org/rss/1.0/modules/content/"
   >
<channel>
    <title>Company blog - Development</title>
    <link>http://pushok.com/blog/</link>
    <description>What our employees say (sorry for poor English, they write as they can)</description>
    <dc:language>en</dc:language>
    
    <generator>Serendipity 0.9.1 - http://www.s9y.org/</generator>
    <pubDate>Tue, 04 Jul 2006 13:39:07 GMT</pubDate>

    <image>
        <url>http://pushok.com/blog/templates/default/img/s9y_banner_small.png</url>
        <title>RSS: Company blog - Development - What our employees say (sorry for poor English, they write as they can)</title>
        <link>http://pushok.com/blog/</link>
        <width>100</width>
        <height>21</height>
    </image>
<item>
    <title>MS Installer upgrade policy moot point: what mean small, minor and major modes.</title>
    <link>http://pushok.com/blog/index.php?/archives/3-MS-Installer-upgrade-policy-moot-point-what-mean-small,-minor-and-major-modes..html</link>
<category>Development</category>    <comments>http://pushok.com/blog/index.php?/archives/3-MS-Installer-upgrade-policy-moot-point-what-mean-small,-minor-and-major-modes..html#comments</comments>
    <wfw:comment>http://pushok.com/blog/wfwcomment.php?cid=3</wfw:comment>
    <slash:comments>0</slash:comments>
    <wfw:commentRss>http://pushok.com/blog/rss.php?version=2.0&amp;type=comments&amp;cid=3</wfw:commentRss>
    <author>nospam@example.com (Sergey Korotkov)</author>
    <content:encoded>
&lt;p&gt;The starting point for issue was just the desire to make .msi package which can be installed on user PC with single click not depending on existence of previous version. We use the WIX tool set to build an MSI packages. Without any efforts for upgrade policy every new installer version shows  old version un-install dialog and on second run install dialog. Such behavior confuses users because they click on .msi file of new version but un-install dialog from previous versions are shown up. 

&lt;p&gt;We quickly found the reason and solution of for this issue. It is required to follow upgrade policy for MSI packages: put the UpgradeCode attribute and change correctly GUIDs of Product ID, PackageID and Product Version. Depending on what from above is changed upgrade can be &quot;small&quot;, &quot;minor&quot; and &quot;major&quot;. As described in MSDN:
&lt;br /&gt;* Small updates mean small changes to one or a few files where the change doesn't warrant changing the product version (major.minor.build). You don't have to change the Product GUID, either. Note that you always have to change the Package GUID when you create a new .msi file that is different from the previous ones in any respect. The Installer keeps track of your installed programs and finds them when the user wants to change or remove the installation using these GUIDs. Using the same GUID for different packages will confuse the Installer.
&lt;br /&gt;* Minor upgrades denote changes where the product version will already change. Modify the Version attribute of the Product tag. The product will remain the same, so you don't need to change the Product GUID but, of course, get a new Package GUID.
&lt;br /&gt;* Major upgrades denote significant changes like going from one full version to another. Change everything: Version attribute, Product and Package GUIDs.

&lt;p&gt;So, definitely if we release &quot;minor&quot; (or bugfix) release then we have to use &quot;minor&quot; upgrade. When we release new major version of product then we have to use &quot;major&quot; upgrade. All seems to be smart and clear. But there are one cavern: when new MSI is a &quot;small&quot; or &quot;minor&quot; upgrade .msi file cannot be installed by single click because it asks to explicitly un-install old version. The surprising fact is that &quot;major&quot; upgrade does not ask this and installs silently as required. It is not an issue for us and we can build &quot;major&quot; upgrades each time, but this is the thing that I not understand. Why &quot;minor&quot; upgrade which intended to be a &quot;bug fix&quot; which does not make any serious changes cannot install silently, but &quot;major&quot; upgrade which can break anything is allowed for silent install. 

&lt;p&gt;Even this seems to be a logic breaking behavior nothing understandable can be found from Microsoft. The only thing we have found is: 
&lt;br /&gt;&lt;i&gt;You Need to Uninstall Previous Versions with Add/Remove Programs in some Situations When an administrator installs an application with an .msi file, they can choose whether it is installed &quot;For Everyone&quot; or for &quot;Just Me.&quot; If the administrator chooses &quot;For Everyone&quot; and then you subsequently provide an upgraded version of the installer that specifies earlier versions should be removed (by setting the RemovePreviousVersion property), this setting does not work correctly and instead the installation overwrites files without prompting. This can obviously cause serious problems for your application. As of this writing, there is not a good workaround for this, so users must use the Add/Remove Programs utility to remove the earlier version before installing a later one. 
&lt;/i&gt;
&lt;br /&gt;I cannot understand what they explain here, especially taken into account that major upgrade does work and not require manual de-installation. The work around which make possible silent launch of small/minor upgrades is launch of msiexec with specific parameters: 
&lt;br /&gt;&lt;br /&gt;
&amp;#160;&amp;#160;&amp;#160;msiexec /i SampleUpgrade2.msi REINSTALL=ALL REINSTALLMODE=vomus 
&lt;br /&gt;&lt;br /&gt;
&lt;p&gt;Don't ask me how this would fare with the average user... You'd better start it from an Autorun.inf file or devise an outer Setup.exe shell to launch it. 
&lt;p&gt;May be somebody knows why this works so? I'm appreciate any comments.     </content:encoded>
                
    <pubDate>Tue, 04 Jul 2006 15:01:30 +0400</pubDate>
    <guid isPermaLink="false">http://pushok.com/blog/index.php?/archives/3-guid.html</guid>
    </item>
<item>
    <title>GCC compiler seems to be very smart</title>
    <link>http://pushok.com/blog/index.php?/archives/1-GCC-compiler-seems-to-be-very-smart.html</link>
<category>Development</category>    <comments>http://pushok.com/blog/index.php?/archives/1-GCC-compiler-seems-to-be-very-smart.html#comments</comments>
    <wfw:comment>http://pushok.com/blog/wfwcomment.php?cid=1</wfw:comment>
    <slash:comments>0</slash:comments>
    <wfw:commentRss>http://pushok.com/blog/rss.php?version=2.0&amp;type=comments&amp;cid=1</wfw:commentRss>
    <author>nospam@example.com (Andrey Kosyakow)</author>
    <content:encoded>
&lt;p&gt;Working on integration of ffmpeg library which only can be compiled with GCC compiler I had found that GCC compiler can validate type and number of parameters of printf function. Very smart, in contrast, MS compiler ignores that and program can crash due to this.     </content:encoded>
                
    <pubDate>Thu, 25 May 2006 17:51:22 +0400</pubDate>
    <guid isPermaLink="false">http://pushok.com/blog/index.php?/archives/1-guid.html</guid>
    </item>
</channel>
</rss>
