Windows application deployment

  • Thread starter Thread starter Benny
  • Start date Start date
B

Benny

Hello Experts,

I have created a windows application using vs.net 2002 with C#, and now
I need to deploy the project. The project involves adding string values
to the registry and created text files. The question is how can I create
a uninstaller included in the project which will uninstall the project,
which will delete the registry values create, as well as the text files?


Thanks in advanced,

Benny
 
Hi Benny,

Add a new Setup project to your solution. Right-click on the setup project
in the Solution Explorer, select View, Registry from the context menu, and
add they key you want. The *.msi file produced by the setup project will
take care of installation/uninstallation of the new registry keys.

Joe
 
Hi there,

you can use Windows Installer 2.0, which comes with VS.NET.
With WI, you can create a deployment package (msi), which will add the
values in the registry and upon uninstall will delete them.
About the text file, I'm not sure (for automatic deletion), but you can
always define a custom step in the installer package, in which you can do
whatever you want.

Good luck,
Branimir
 
I have created a windows application using vs.net 2002 with C#, and now
I need to deploy the project. The project involves adding string values
to the registry and created text files. The question is how can I create
a uninstaller included in the project which will uninstall the project,
which will delete the registry values create, as well as the text files?

Use a good installer package that will do this for you. VS.NET 2002
includes support to create Installation projects, which will use the
MS Windows Installer technology and create .MSI installation packages.

If you're looking for something more light-weight, and easier to
understand, I'd strongly recommend the free InnoSetup package (in
conjunction with the ISTool GUI frontend) - it creates stand-alone EXE
installers, which are very easy to send out, and it includes uninstall
suppport.

InnoSetup - free Installer
http://www.jrsoftware.org/isinfo.php

ISTool - free GUI front-end for InnoSetup
http://www.istool.org/

Marc
================================================================
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch
 
It's a bad application that RELIES on text files being there in order to operate. Rewrite it and compile the data into the program, this stops it being altered by meddling users.
 
Beeeeeeeeeeeeves said:
It's a bad application that RELIES on text files being there in order to operate. Rewrite it and compile the data into the
program, this stops it being altered by meddling users.

How do you figure?

A "bad program" would be one that you describe with everything hardcoded into the program. In general, the more stuff hardcoded in,
the less useful the program becomes since it is less flexible.
As far as the meddling users... if the user screws with something and breaks it, then they will learn not to screw with it.
 
Marc Scheuner said:
If you're looking for something more light-weight, and easier to
understand, I'd strongly recommend the free InnoSetup package (in
conjunction with the ISTool GUI frontend) - it creates stand-alone EXE
installers, which are very easy to send out, and it includes uninstall
suppport.

I'll second this opinion. I've used InnoSetup in the past and it is a great installer, very flexible. Covers just about every
feature you need too.
 
Nah. Better for it to be one single exe. Registry if you really MUST, but definitely not a text file. It's ok as long as the application can function and tell the user what's up if the text file isn't there, but needing it to operate, well that's bad.
 
Your advice runs contrary to the .NET framework's use of Config files.

Config files are text files, encoded in XML, used to store common
settings... just what you are suggesting is "bad."

I would disagree with your statement that this is not a good way to design.
It is OK to design the system so that it has reasonable default values in
case it cannot find it's config file. It is equally OK to design the system
to rely upon the config file to provide extensive configuration data.

An EXE uses a DLL, and therefore is not completely self contained. If a
user deletes the DLL, the EXE fails. This is no different than your
objection, yet I don't believe you've expressed any opposition to the idea
of using references, or multiple assemblies. Or is that objection just
waiting to emerge?

If you are using an installer, all of your files, from EXE to DLL to Config,
can be installed and controlled. No reason not to put as many files in the
installation folder as you want and need.

--- Nick

Beeeeeeeeeeeeves said:
Nah. Better for it to be one single exe. Registry if you really MUST, but
definitely not a text file. It's ok as long as the application can function
and tell the user what's up if the text file isn't there, but needing it to
operate, well that's bad.
 
Beeeeeeeeeeeeves said:
Nah. Better for it to be one single exe. Registry if you really MUST, but definitely not a text file. It's ok as long as the
application can function and tell the user what's up if the text file isn't there, but needing it to operate, well that's bad.

Again, why is it bad? You have given other options, but nothing about why it is bad. Personally, I despise the registry and would
rather go with an .ini file or some other configuration file any day.

Of course, we don't actually know what these text files are for, so we can only go so far down that road :)
 
Back
Top