views:

181

answers:

5

For a testing usage of not very complex WPF applications I often don't make installer - just, after building project, copy Bin>Debug folder content of a VS2008 project folder to a hard drive of a user computer and put an icon to a desktop. No records to windows registry.

Are there any drawbacks of such a way of using windows applications for testing period?

+8  A: 

The only change you might want to make is to build the app in Release rather than Debug and take the files from the Bin>Release folder.

more info: http://haacked.com/archive/2004/02/14/difference-between-debug-vs-release-build.aspx

runrunraygun
release vs debug http://social.msdn.microsoft.com/Forums/en/clr/thread/4de6861f-e723-4def-bcaf-aa717a3e1897
runrunraygun
+10  A: 

There's nothing wrong with this approach at all - it is what's called xcopy deployment. You don't get a few things doing it this way:

  • an entry in the add/remove programs for users to uninstall with
  • the ability to add shortcuts to desktop/start menu/quick launch
  • any changes to the registry for settings etc...

Another benefit is that you can get your application onto a computer by a user who does not need administrative privileges to install.

It really comes down to your requirements. If you don't need any features of an installer, then just copying the files is a good approach.

I'd agree with the other comments about using a release build though - especially if you are deploying for real use and not just testing.

adrianbanks
+3  A: 

When you have multiple files to deploy along with your exe, dll's to register, file associations to set up, then an installer is a neat way to deliver all of that in a reliable manner. If you don't do this with an installer the user could easily screw things up.

In addition to that, the installer is sometimes used as a means to ensure the computer is truly ready for the application. For example, the installers I've written check to ensure the proper version of .NET is installed, and will download & install it if necessary.

However, there are many times when these characteristics are simply not worth it and deploying a standalone application in a single exe is perfectly acceptable. Simple applications that don't need to store a lot of settings on your computer and don't have a lot of prerequisites are perfect examples. The first thing that comes to mind are all the utilities from Sysinternals.

Steve Wortham
+1  A: 

I see only one potencial drawback. There is nowthing wrong in your approach as long as you don't have more than 1 to 3 users and changes during test session are not often. When changes are often and you have to copy library to more than 3 users (hosts etc.) the drawbac I mean is maintenance time. I know what I'm talking about because in place where I work, we have such issue. Last time I've started to more taking care about maintaining our application and copying files from one host to another than coding. :( In my honest opinion sometimes is better to invest your time on the beggining and write an installer than have a lot mainteneance and copy things later.

truthseeker
+1  A: 

To solve the number of users problem, there's a very simple solution that does not require to setup a full installer. Basic setup for multi-users xcopy/.bat deployment:

  1. A shared drive, with one folder for the .bat files, one for the binaries.
  2. Upload the binaries to the shared drive and update the install script if needed.
  3. Have every user run the install script.

By the way, some very complex information systems are ENTIRELY deployed by .bat files (even when not testing!).

Sylvestre Equy