Quote:YOUR installer need do only the things YOu want to to do.

No. YOUR installer needs do only the things YOUR CUSTOMERS want it to do. Which is all of the above things, and then some.

Really, installers these days should use the MSIS (Microsoft Installer Services). This means that your installer creator outputs a .msi archive, and then you let Microsoft actually do the installation using the given API. This ensures that permissions, registry, roll-back, user permissions and all that other stuff has reasonable handling.

In fact, InstallShield and friends, these days, are advanced interfaces on top of the MSI engine, and generate .msi output archives. Only NullSoft doesn't, and there are signs that Microsoft is internally debating whether to break those installers in Longhorn.

Quote:Original post by ace_lovegrove
f its just for me to install a program rudely then i can make it simple.

I pray to the coding gods that I never have to test anything you write.

I agree with hplus0603. If you use MSIS, you get a lot of advanced functionality available to you like Install-On-Demand, integrated patch uninstallation, and the ability to repair an installation.

However, while MSIS is extremely powerful, it has some issues. First, the documentation is as cryptic as a Dennis Miller monologue after drinking absinthe. Second, with the exception of WiX (http://wix.sourceforge.net), most of the decent tools are overpriced. Third, the Windows Installer prerequisites are still 3MB+ for the full set. Finally, installation testing tools are piecemeal at best.

If you're doing something quick and dirty, use NSIS or WiX. For professional installations, use InstallShield or WISE.

I appreciate that you want to learn how to write your own installer (based on your original post), but if you aren't going to learn how to do something right, then don't bother learning how to do it at all.

I'm actually going to debate you on this one.

There are two stated purposes here, both of which are mutually exclusive. One stated purpose is to learn how installers work in order to more fully understand the actions of the production code (refer back to the original post). The other stated purpose is to make something for personal use.

Now when I'm doing something for myself that I know will only ever be run by myself in certain circumstances, I don't mind taking shortcuts. I don't mind hardcoding SQL connection strings in my internal testing tools because I know for a fact that my tools will never exist outside of this network.

However, when I'm writing something to learn, I have to hold myself to a higher standard than that. The focus is not "get it done," it's to make something as functional as possible in order to not only learn the "how," but to also learn the "why" of the project.

Now while none of the "learning" code may ever become public, I have something I can refer back to should I have to write similar code in the future. I can go back and see that I had to shift certain prerequisites to the back of the install chain because their redist didn't have a silent option. I can go back and see that if my patches don't register with MSIS that the uninstaller will leave files and folders behind. I can see why rollback order is so important.

Make no mistake about my intentions...I want people to learn. Learning by doing is not only admirable, but desirable. But building an installer that just copies files without handling these other cases and saying, "Okay, I've learned enough," is like building a miniature cardboard fort and saying that qualifies you to build a skyscraper.