On 6/1/2012 2:37 PM, The Devils Jester wrote:
> Or do you expect the average Windows user to manually create a
> folder in the Program Files folder and copy your files in it? Then
> he should double click your program so that it can create an entry
> in the start menu?
>
> No, I expect them to extract it to their home folder and run it there.
I used to do that - the majority of my users couldn't do it. They did
understand running a .msi file.
> If they don't like that, they are free to use another program.
>
> Again, why should you waste time reinventing the wheel, since all
> installers can do it for free?
>
> I do not understand your comment, as the code required to do this is
> only a few lines, and takes much less time to do once, than to create an
> installer application, of which you will have to update with each new
> version of your app. It seems like you waste a lot more time than I do.
>
> Moreover installer writers have more experience so they are likely
> to handle in a better way unexpected situations or new versions of
> the operating system.
>
> I find the opposite to be true. Since all of my data, and dependencies,
> even were I to use an installer app, are in my programs directory, there
> is nothing for an installer to do except copy the folder and make a menu
> entry. No chance for unexpected situations, its installers that cause
> these situations, no chance for OS version issues,
I disagree there - The installer can prevent a package from installing
on an OS I don't support (for instance, anything before XP)
> since its run
> directly from the folder you extract it to, and no chance for other
> applications to install binary incompatible versions of 3rd party
> libraries you use, breaking your program (this was always fun to deal
> with).
Using an installer doesn't expose you to incompatible 3rd party software
any more than this method. (Personally, I static link to avoid the whole
runtime distribution issue)
> I find a single, self contained package to be a better design choice. I
> may not have the option in the future for Windows users (who knows what
> future Windows versions will do) but for now, I like this best.
I went to a preview about Win8 - Metro apps will ONLY be able to be
distributed via the Windows Store. So you won't need to author a .msi
anymore, but you can't author your own distribution either. (Let's just
say I was a little underwhelmed about the whole Metro thing -
considering I'm the type of person who usually has at least 5 programs
actively running and usually a few more simply open)
> But I did not reply to the OP to start an argument about design choices.
> I just wanted him to know that I do the same thing, and that the two
> big things mentioned in this topic about why an installer is needed, are
> easily done in code.
Hijacking of threads... :-) (BTW, to derail it further, Win8 release
preview just came out, along with Visual Studio 2012 RC (VS11 had been
renamed) - I'm just compiling WX in that now, 32bit done, 64bit running
[using makefiles])
The main reason I package my program in an installer is ease-of-install
by my users (most of whom are in the class "what OS are you on? Internet
Explorer." sigh.) And that it puts itself in expected locations (Program
Files, menus, etc) automatically so all users on a machine can use it
(and all UAC issues are handled by MSI). Yes, my program is happy
without an installer, by my users are happier with.
Dave
(I worked exclusively on MSI projects for 3 yrs at my previous job)