none
Create patch file after copy the whole project RRS feed

  • Question

  • i trying to create a patch to patch .msi from "hello world" to "____ world".

    I follow the example stated in http://www.codeproject.com/KB/install/dotnetpatching.aspx and able to produce the patch(very small size) if i did not change my project folder.

    If i make a copy of the "hello world" project folder and amend the code to "____ world" in copy project folder, when i try to create the patch the following message is encountered "Patch API could not create a small patch; using whole upgraded file." and the patch file is about the same size as the .exe file. As the message suggested, it did not create a patch but it used the whole upgrade file.

    Are there a way to solve this problem?

     

     

    Friday, December 24, 2010 3:44 AM

Answers

  •  

    Hi,

     

    Thanks for your post, but your question is tend to get better support at ClickOnce and Setup & Deployment Projects forum.

     

    Please feel free to let us know if you have any concern.


    Eric Yang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by eryang Thursday, December 30, 2010 12:52 PM
    Monday, December 27, 2010 2:19 AM
  • You need to obey the MSI component rules. For an update (aka) patch you must not

    • remove files
    • rename files
    • remove items (files/registry keys, environment variables) from a component
    • change the destination folder

    All these modifications will break the msi component versioning rules one way or the other. You can only modifiy files and add files.

    There are othe rules as well.

     

    http://robmensching.com/blog/posts/2003/10/18/Component-Rules-101

     

    All in all a quite complex topic.

     

     

    Yours,

      Alois Kraus

     

    • Marked as answer by eryang Thursday, December 30, 2010 12:52 PM
    Tuesday, December 28, 2010 8:30 AM

All replies

  •  

    Hi,

     

    Thanks for your post, but your question is tend to get better support at ClickOnce and Setup & Deployment Projects forum.

     

    Please feel free to let us know if you have any concern.


    Eric Yang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by eryang Thursday, December 30, 2010 12:52 PM
    Monday, December 27, 2010 2:19 AM
  • You need to obey the MSI component rules. For an update (aka) patch you must not

    • remove files
    • rename files
    • remove items (files/registry keys, environment variables) from a component
    • change the destination folder

    All these modifications will break the msi component versioning rules one way or the other. You can only modifiy files and add files.

    There are othe rules as well.

     

    http://robmensching.com/blog/posts/2003/10/18/Component-Rules-101

     

    All in all a quite complex topic.

     

     

    Yours,

      Alois Kraus

     

    • Marked as answer by eryang Thursday, December 30, 2010 12:52 PM
    Tuesday, December 28, 2010 8:30 AM
  • Sorry for posting in the wrong section. Can i move this thread over?
    Friday, December 31, 2010 3:52 AM
  • Yes, most likely is because i did not obey the msi rule. 

    When i checkout the code in different folder and create the msi, the component number is different but the componentId is the same.If i delete the file and checkout back to the original folder, the component number remain the same. I think is because of the different component number that cause the patch to fail.

    If there anyway i can bypass this constraints?

    i try search and replace the component number with the original msi component number but when creating the patch, it complaint that component number can not be found in the cabinet and do not allow me to create the patch. I suspect most likely the cabinet contain the old component  number. Is there a way to edit the component number inside cabinet? Or is there a way that i can know what is the directory that i checkout code for creating the original msi? Thus i can checkout the code into the right folder structure.

     

     

     

     

    Friday, December 31, 2010 5:22 AM
  • I do not know what you mean with component number. What tools are you using to create your msis and patch file?

    If you have a look within the cab files you see the file names are prefixed with a GUID which is indeed the component id. Tampering with the cab files is a topic of its own since msi has the media table where the files are referenced via a sequence number in the file table .

    What does it mean?

    If you alter the ordering of files within in the cab you need also alter the file table and adapt the sequence numbers since the sequence number is in reality an index to the file in the cab file. It is NOT referenced by its name. So if you change the file ordering in the cab file by accident msi will complain that it could not install the file xxxx although it is present in the cab.

    I have not yet seen any useful hints how to make patch files break the component rules. If you skip the msi patch file creation and simply create a new package and obey the rules for minor and major upgrade you are much better off. There are ways to remove a file during a minor upgrade which is explained at John Robbins blog. The tool is called Paraffin which creates wxs files for the WIX toolkit.

     

    Yours,

       Alois Kraus

     

    Friday, December 31, 2010 8:56 AM
  • I using visual studio "setup project" template to create the msi. For the patch creation, i using msiexec from Microsoft Platform SDK. Base on the tutorial from http://www.codeproject.com/KB/install/dotnetpatching.aspx

    For example i checkout hello_world project to c:\folder1\hello_world and c:\folder2\hello_world. I compile and create the msi in both the folder. When i open the msis using orca i see that under the File table, the file column and component column is different for msi in c:\folder1\hello_world\setup1\release\setup1.msi and c:\folder1\hello_world\setup2\release\setup1.msi. For the File name column both msi is the same(HELLO~1.EXE|Hellow World.exe)

    I trying to find a way to keep the file column and component column constant in both msis but without success.

    In order to obey the rules for minor and major upgrade, i must always create the msi in  c:\folder1\hello_world\?

    Sunday, January 2, 2011 3:17 AM
  • I do not think that it is possible to change the install location of a file during a patch. The component id will change when the target folder will change. This would break the file ref counting algo to determine when a file is about to be uninstalled or even worse repair will do the wrong thing like e.g. remove your new file and place the file into the original location again.

     

    Yours,

       Alois Kraus

     

    Monday, January 3, 2011 12:03 AM
  • I am getting confuse with the meaning of install location of the file and target folder.

    The install location of the file does it mean the folder i going to install hello world or the folder of the hello world installer(.msi)?

    The target folder does it mean the folder i going to install hello world or the folder of the hello world installer(.msi)?

     

    I not trying to change the install location of a file during a patch.Maybe i try to explain what is actually happening now.

    Basically, there is a hello world solution store on the server. Let say there is two engineer Ivan and John. Ivan "copy" the whole hello world solution from the server to his deskop (c:\users\ivan\desktop\hello world). He then create the setup1.msi. This setup1.msi is then send to all the customer as an installer for them to install on their PC. Of course the boss also keep a copy of this installer. Now the boss say he want to modify the hello world program (change the text in the program from hello world to beautiful world). Ivan modify his local copy of hello world program and create the patch. This patch have no problem and can be send to the customer for patching.

    But before the patch are pass to the boss to send out to the customer, Ivan decided to quit the company. He destroy everything on his pc. Now the boss call john to his office. He call john to modify the hello world. So john copy the hello world solution from the server to his desktop (c:\user\john\desktop\hello world). He modify the code and created john's setup1.msi.

    He now need to create a patch to patch ivan's setup1.msi (the copy that is send out to the customer) to john's setup1.msi (the copy where text has been change to beautiful world) using msiexec. He found that he can not create the patch.

    Now john is struck. Since is just a change in text, the boss want a patch and do not want to resend the whole hello world to the customer. The boss is concern with the patch, he does not care how john create this patch. Thus John is free to use what ever mean.

    Monday, January 3, 2011 3:48 AM
  • This is not a standard problem. There are several options.

    1. You have the original msi. You can recreate the original folder structure via an administrative installation.

    http://makemsi-manual.dennisbareis.com/msiexec_exe_administrative_install.htm

    http://msdn.microsoft.com/en-us/library/a48h5xkw%28VS.80%29.aspx

     

    From there you have two options.

    a) Recreate the setup project and set the proper product id and if present upgrade code of the original msi.

    b) Download the Wix toolkit and decompile the msi into a wix project. The decompiler is called dark.exe which can take an msi and create "source" wxs files which can be compiiled by candle and light (the wxs compiler and linker of the Wix Toolkit).

    From there it is a manual process to fiddle along in the installer project or the wix toolkit (it let you set the component ids manually so you have much more control) until the "new" msi is binary identical except for the package id which is new for every built msi.

    To check for success you can either export all tables from within orca into text files and use Windiff or Kdiff3 (my favorite because it can do intra line compares) to check for changes or download Super Orca which can also compare msi files.

    Once you have everything up to recreate the msi you are in a save position to create patches and upgrades as you like.

     

    Yours,

      Alois Kraus

     

     

    Monday, January 3, 2011 10:48 PM
  • For step 1, i issue the "msiexec.exe \a c:\testing\setup1.msi" command. A installer pop out and call me to install. I click next all the way. A folder call "default company name" is created at "c:\program file". Inside the "default company name" folder there is the "setup1" folder. Inside the "setup1" folder there is the "hello world.exe" and "setup1.msi"

     

    After step 1,  i have the original "hello world .exe" installed.

    For step number 2a),  are we trying to recreate the original setup1.msi? Why do we need to recreate the original setup1.msi?

    After recreate a msi using the installed "hello world.exe" , i open the new msi using orca and do a compare with the original msi.The file table consist of 8 columns namely File, Component, FileName, FileSize, Version, Language, Attributes, sequence. The vaule of the first column is different for new msi and original msi.

    I might have miss out some of the steps.

     

    At which folder should i save the "setup project?

    Inside the setup project, there is the application folder, user's desktop folder and user's program menu folder. What should i add to this folder?

     

    Thank alot and I really appreciate your help.

     

    Tuesday, January 4, 2011 6:13 AM
  • I choose the path to recreate the original msi to ensure that we have the same component ids.  I have checked that the setup project does choose component ids not based on the source location. When I remove and add the same file it does get the same component id. There was no info how VS does generate the component ids but I think it should be possible to recreate the decompiled msi again.

    I do think it might be easier to use the wix toolkit which allows you to decompile the msi into its pices with one tool call then you can patch the file and recompile it. You only need to update the ProductVersion to e.g. 1.0.1 from 1.0.0 to enable patch creation.

     

    Yours,

      Alois Kraus

     

    Tuesday, January 4, 2011 1:37 PM
  • I agree.
    vnc viewer
    Tuesday, January 4, 2011 11:39 PM
  • I created a setup101.msi using visual studio. I decompile the setup101.msi using wix dark. After which, I recreated the setup101.msi using wix.

    1) I compare the recreated_setup101.msi with setup101.msi using superOrca. This two file are identical.

    2) I use msiInfo.exe to see the attribute of both msi is identical.

    3) I extract the file from both msi and do binary compare to ensure the file inside msi is identical

     

    I try create patch using setup101.msi. It work But for the recreated_setup101.msi the patch still fail. I do a binary compare of both msi, it different. What other stuff did i miss out?

    Monday, January 10, 2011 5:37 AM
  • Problem Resolved. Thank all for the help.

    For the benefit of other that might encounter this problem, the last step is that we need to change the data type of some of the table in msi. This is because some of the table type used by VS and wix is different.

    Tuesday, January 11, 2011 3:02 AM