How do I make my program "patchable"?

Hello. I have recently written a program that interacts heavily with web content, namely HTML code. (The program actually grabs HTML code and then parses out certain content.) In the event that the webmaster changes the HTML pertinent to my program, my program will fail to work any longer. Since I am going to sell this program, this could be a serious problem.

I can think of two options:
1. In the event that my program ceases to work I could simply send my customers a whole new program, updated to match the new HTML. This will be messy if I have lots of customers, not to mention that it will be a hassle for them to download such a large program over and over again.

2. A patch, which would be significantly smaller. The problem is, I don't know how patches work or how exactly existing VB programs are patched. Can someone explain this to me, or at least point me to resources that could get me started? Thanks.

Moved.

IMO it doesn't matter if it's big or small, just create a set of installation files and alert your users that they need to update.

Thanks for the response. Could you expand on this:

"create a set of installation files"

How does this make a program "patchable?"

You use the P& P&D, etc.D Wizard that comes with VB, Inno Setup or some 3rd party tool and create a set of files that you distribute to your users. To them a new installation or a new version of your program looks pretty much the same; they always install from Setup.exe that is in your package that was created by P&D, etc.

simplest way is have your program download the update which is a full install file and install programs will automatically overwrite older file versions, as long as you have versions set on them.

Another way is to separate every core part of your application into DLL files. Whatever needs updating.. just send them that file.

chem

Quote:

---

Originally Posted by Lord Orwell

simplest way is have your program download the update which is a full install file and install programs will automatically overwrite older file versions, as long as you have versions set on them.

---

I'm not so sure this is true for all types of installers. The VSI 1.1 Help says:

Quote:

---

You must be aware of an important Microsoft® Windows® installer consideration whenever you run a changed version of an installer package (.msi) file. This is that the installer, after successfully installing an application, maintains a cached version of the original .msi file on the target machine. This cached copy of the .msi file is an important safeguard for your user, because it maintains the information necessary for any future installation repairs.

However, this cached version of the .msi file can interfere with testing and debugging, because the Windows installer will always run the cached .msi file, unless it is uninstalled. That means, you could make changes to a Microsoft® Visual Studio® Installer project (.wip file), build them into a new version of your installer package (.msi) file, and then run the installer package — and the new installation will not include any of your changes. That's because the Windows installer would run the original, cached version of the .msi file not the newer version you have just built.

To ensure your changes are incorporated into the product installation, you must uninstall any older version of the .msi file before you run the newer version.

---

VSI 1.1 also assigns a Product Code guid and an Upgrade Code guid to a package. The Help also says:

Quote:

---

Use this field to establish the unique code assigned to all updates of this product. For example, suppose your installer package file is the first version (1.0) of your product named MyProduct, which has the product code {99} and the update code {14}.

Once upgrade code {14} has been assigned to MyProduct, you should use it for any upgrades to the product. For example, if you ship version 2.0 of MyProduct, you would give it a new product code (maybe {191}) and the same upgrade code ({14}).

Assigning the same upgrade code to all product versions this way gives the Microsoft® Windows® installer the information it requires to automatically uninstall an older version of a product when a new version is installed.

---

The implication is that a new full-installer should adhere to this protocol in order to have it actually work as expected.

The Installer SDK seems to call this "upgrade code" a "product code" and VSI's "product code" a "package code." Sure sounds confusing!


There are also Windows Installer patch packages that have the extension MSP. This looks even hairier. See Patching and Upgrades.

that merely says that running an installer package will force you to delete the original one. I have actually ran into this problem in the IDE in vb2005. Once i did a publish, it quit updating the executables.

Quote:

---

Originally Posted by razzendahcuben

I have recently written a program that interacts heavily with web content, namely HTML code. (The program actually grabs HTML code and then parses out certain content.) In the event that the webmaster changes the HTML pertinent to my program, my program will fail to work any longer. Since I am going to sell this program, this could be a serious problem.

---

Please do us all a favor and do not sell this application.

First off, you have no way to support your users since you do not own the website in which the content is coming from. This means the webmaster for the website could change their website 50 times in one year requiring 50 patches to your application. This is not only a headache for your users but a headache for you no doubt. What happens if the website goes down? Will you refund all of your customers or abandon them?

Secondly, depending on the content this may be illegal for you to grab it, re-brand it into your application and sell it. Not to mention this notion of grabbing data from someone else's website is just not ethical.

Please, take the time and do it correctly and you won't have this problem. Either provide the content yourself or talk with the web site operators to see about accessing some sort of web service or feed so you'll never need to worry about changing HTML and you're not breaking copyright laws as you'll probably be asked to pay them for access to the web service and/or feed.

Quote:

---

Originally Posted by Lord Orwell

that merely says that running an installer package will force you to delete the original one. I have actually ran into this problem in the IDE in vb2005. Once i did a publish, it quit updating the executables.

---

When I read it, chasing down most of the links as well, it seems to suggest there are ways to cause running the new MSI to remove the old one for you first. It also talks about how patching can be done using Windows Installer.

I won't claim to understand it myself though. It looks like some serious experimentation would be required, because so far I haven't found any good writeups of the process on the Web.

I think most of us would be happy to know how to reliably have installing a new MSI auto-remove the original application for us. That would be a useful start at least, to get around the problem of the cached MSI being re-used without manually uninstalling first.

you could probably have the "patch" version of the program store the msi in a known location (like c:\temp) and do a filedel on that location at the beginning of the install. The sourcecode for the msi installer is available so it shouldn't be too hard to modify it.