Software Versioning for Windows Applications (Process NOT Numbering Scheme)

Question

I'm searching for best practices for versioning software from a process (technical) standpoint but can only find conversations on numbering schemes.

Basically, I want to see if my planned update process meets "standard practices".

The application checks an API and compares the result with it's own build number. If the API returns a build greater than it's current version, it flags the program to update. The application downloads the update and spawns a process to run the MSI.

Does this sound feasible? Are there any references for best practices?

• Robert Harvey: I don't really understand what your architecture has to do with this.
• CryptoJones: Sorry, I meant the architecture of the update mechanism.
• kdgregory: I haven't done this, so not an answer, but you might find this page useful.
• Justin Cave: This is going to be highly dependent on your target audience. If you are distributing, say, a piece of software targeted at individual users in the US, what you're describing seems quite reasonable. If you are distributing a piece of software that large enterprises are going to install on hundreds of their machines, they're probably not going to want random pieces of software to be going out, downloading random software, and installing it. If your target is consumers that are paying by the byte for downloads, you may want to ask whether they want to download now or later.
• Robert Harvey: The problem with asking for "standard" ways to do things is that they will all be different 5 years from now. That's the great thing about standards; there are so many of them. As @JustinCave points out, the solution that is best for your particular application may not be the most popular approach, or even a well-known one.

Answer 1

This is a reasonable approach but I don't see any consideration of security. This kind of approach could be hijacked in order to install malicious code on the user's machine. You need to consider what mechanisms you are using to ensure the remote server is authenticated (obvious choice: TLS) and also how you are going to verify that the MSI is offical (obvious choice: signing.)

A lot depends on the circumstances but I think the user should have an option to delay. Automatic updates have a tendency to occur at the most inconvenient times. You also need to realize that if you push a bad build out automatically, it's going to make your users really angry.