You're exactly right about users needing the installation. Most users don't know what to do with the program otherwise. "Where do I put it?" "Why isn't it on the Start Menu?" "How do I make a shortcut?"

Even more importantly, the installation will add the program to the Add/Remove Programs list.

Oh right *I* have to keep my dependancies to a minimum - you mean things like the .net framework, dll's for necessary shell extensions etc. Well here's a clue, if MS let us link these things into our .exe's we wouldn't need to have such complex installs.

When working within a LAN environment the bet model I always used was to keep the application file on a network server... As I developed in delphi this was generally Limited to one Exe file.
If local storage was (ever) necessary the Exe file setup and checked this on first run. (including installing its own shortcut to the desktop).

Deployment simple involved sending a mail to the new user with the appropriate file:/// link.

Personally I never had any touble with delphi win32 deployment, The program file was always stored and updated centrally, and startup latency on a 100mbit LAN was almost nil, even for a 10MB exe.

With delphi it was always possible to statically link everything into on EXE (yes even DB access)

http://www.componentace.com/bde_replacement_database_delphi_absolute_database.htm

Sybase :http://www.geocities.com/ctlibcomps/ctlibcomps.htm (CTLIB Dependent)

We just used to laugh at at the VB guys suffering in DLL Hell while we sat back in delphi heaven.

Its interesting to speculate that with the arrival of broadband to the home user whether this becomes an atractive option over the internet.

Heres a question I always asked myself. If it hadnt been for DLL HELL would Web (browser) applications have been even half as popular.

HTTP enabled rich clients may still be yet to have their day.

> Deployment simple involved sending a mail to the new user with the appropriate file:/// link.

In .NET, EXEs launched from any remote computer do not have full trust-- whether it's a http:// href or a network drive path. Only EXEs launched from the *local computer* have full trust.

Jeff: If your app runs from one Exe file how much local file access and resources are ya gonna need ???

The .NET runtime will pull down any referenced assemblies; this is done on-demand as they are referenced. The app doesn't have to be a single .exe.

What you can't have, however, is an unmanaged dependency!

> Even more importantly, the installation will add the program to the Add/Remove Programs list.

Doh. The main reason you need that stupid list is because most applications can't be removed by simply dragging the exe file to the trash.

You're talking about a microsoft solution to a microsoft-created problem. What are all these VB6 dependencies? Oh yeah, you're dealing with an interpreted language! We've been using various tools and created executable files with XCopy'able deployment. Heck, we even but the exe on a file-server (Linux/Samba) which is kept up to date using yum. Nothing ever has to be done to the thousands of client-machines when we roll out a new version.

Ugh installers. Still needed, still despised. Still another poor microsoft implementation.

>do you really think your program would end up in the Program Files folder if you left it up to the user

isn't this the whole point of xcopy? make a shell script that copies everything automatically to right place so the user doesn't have to think about it. Just double click on the batch file and that's it, just like we used to do with application installs in dos.
And for the uninstall part: just make another script that uninstalls everything. Just like applications in linux, it works great

I don't see why the user wouldn't be ready for xcopy

I've been using xcopy deployment for years for applications written in C++ that are built as single self-contained .exe files. It does work great (and, in fact, is much-appreciated by end-users who are computer-literate and don't want junk in their registry or system paths). Applications that are targetted for the masses, however, do need to provide something that resembles an install wizzard (even if the only thing it does is copy one file, create one shortcut, and add the add/remove programs entry to the registry). Without a traditional installer, the less-computer-literate users will complain loudly that it isn't a "real" application. In fact, some of them seem to think that any install that completes too quickly must mean that the application isn't large enough to be worth spending money on ... for them it would probably help to add a progress bar and a timer that makes it slowly creep towards "done" (while creating and deleting a bunch of bogus files to make the hard-drive LED flicker, of course :o)

For the computer-literate, xcopy deployment is great! Maybe the masses will eventually get used to it?

I must admit that the biggest issue with xcopy deployment is the start menu shortcut (or cluttered desktop), though. Even I get lazy sometimes and just want a program to automatically put its shortcut in a pre-defined location within my start menu without making me think about it. Although running an install wizzard to do this does negate some benefits of xcopy deployment, the other benefits (freedom from dependency issues) are still there. Thus a varient of "xcopy deployment" that uses a wizzard to set up a shortcut and an add/remove programs entry is still very close to true "xcopy deployment" in my mind (at least it avoids the "versioning hell" of the pre-.net installs that were encumbered by COM and OCX components).

lady and gentlemen, experiment window. Yes, this blog was exactly experiment and nothing more.