11 replies to this topic

[asrinivas]

Hi,

we have prepared patches for our application , but it is not replacing the .DLLS ,.OCX etc if we dont change the component version.
does widows installer consider only the component version for replacing or any other attributes like last modified date ..etc...

this is the problem we are facing.... please help us!

Regards,
A.Srinivas

[Stefan Krueger]

A component doesn't have a version. A DLL or OCX file has a version. All DLL and OCX files should be the key file of their respective component. Overwriting depends on the version of these files.

[m.nouryan]

For every individual file, you may set the "Always Overwrite" flag in the file properties (NOT for dynamic linked files). This would ignore the file version.

[asrinivas]

[m.nouryan]

I’ve had that problem with “Quick Patch”, regular patches work fine for me. Which one are you using?

[asrinivas]

Hi,

thank you very much for your response
we are using quick patch project.......accroding to our requirment we have to go for that only...


regards,
A.Srinivas

[asrinivas]

Hi,

thank you very much for your response
we are using quick patch project.......accroding to our requirment we have to go for that only...


regards,
A.Srinivas

[m.nouryan]

I had to switch to regular patches because of this; if you find the solution please post it here!

Good luck

[Mazrim5]

I'm in the same boat here. I have an MSI I originally created using Visual Studio 2005. I created a Quick Patch InstallShield 11.5 project, because I want to just patch the EXE of my install. I specify the file to upgrade, give it the path to the new one, and just to be safe checked the box to always overwrite the file (although I've tried it without too). But when I install the patch, I still have the old executable. I even tried removing the EXE and installing the patch, and I get the old EXE. It appears that the patch has the old version of the file (1.0.0.0) even though the patch setup says the new version is 1.0.0.1. Any ideas as to what I'm doing wrong (if anything)?

[asrinivas]

[Mazrim5]

Doesn't that essentially mean that a Quick Patch is pointless? Isn't a patch supposed to be used to patch/update/replace one or more (but probably not all) parts of an installation?

Basically here's my situation (maybe someone can tell me the best way to handle this): I'm a developer. Once I create an application (typically in VS2005 using C#), I have to create an MSI and give that MSI to our infrastucture group to install on a production server. When they do this, they typically have to modify the config file to put some username/password in (usually for Oracle) that I'm not allowed to have in production. If I need to do an upgrade, I don't want them to have to copy off the config file, uninstall the old version, install the new version and put the config file back in place (so that they don't have to put that username/password back into the config file). I'd rather create a "patch" that just replaces the EXE or DLL or whatever needs replaced, and not touch the config file. I don't see any way to do a patch with the VS2005 setup projects. I tried to create the initial setup project as an InstallShield project inside VS2005, but when I try to add the project output to it, VS2005 crashes. I thought the Quick Patch was my answer, since it let me choose the original MSI, and then let me choose what file to patch and where the new version is. I don't understand why the interface to the Quick Patch does all of that (it shows the old file version and the new file version, with a message that says the new file will be the one installed when the patch is done), yet the patch doesn't install the new version. To me, that sounds like a bug in Quick Patch.

[Stefan Krueger]