Hey David,

Welcome back :)  Hopefully going back to work after a 2 week vacation is not
too stressful on you :)


On 9/25/07, davidacoder <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> back from holiday, and boy is it cool to see all these checkins :)
>
> > > - Make sure everything is removed at uninstall, in
> > >   particular data directories created by the apps
> >
> > I'm not sure I agree with this... I kinda like leaving the data stuff,
> > or at least giving the option of removing it or not.
>
> I guess an option would be best, but it might be tricky to do, considering
> the nightmare MSI is... I'll have a look.


Hmm, leaving all of the Alchemi Executor's temporary files laying around?  I
think when you uninstall Alchemi, at least everything in /dat/ should
be deleted, if not just completing eliminating C:\Program Files\Alchemi
altogether.
In what situation would you want to keep those files/directories/logs
around?

I believe there are three key points with regards to removing data
> directories:
>
> 1) The version I last used (pre the new checkins) did not delete the
> downloaded apps after they were done running and accumulated a lot of disc
> space. Glancing over the checkins, this might be remedied, but if not I
> think it would not be good to have an uninstall that might leave GBs of
> stuff somewhere hidden in the user profiles where "normal" users would
> never
> find them. What about making sure that the downloaded app directories are
> always deleted, i.e. to make sure that we never leave large amounts of
> data
> behind?


I don't think any of us did any substantial changes to the WiX code that you
added.  I've been doing some code cleanup and have started writing the
User's Guide and Developer's Guide documentation CHM files.  Anton's been
doing some code cleanup and there were a few bugs fixed by Dusty.

2) I fully understand why one would want to leave configuration files
> existing, but I think we should only do that if we at the same time commit
> to always read old schemas of the configuration files in new builds. I
> think
> what would really be not nice is if a situation could arise where someone
> uninstalls an old version, installs a new one and that then crashes on
> first
> run because it cannot read the format of the old config file. What do you
> think?



I don't know how everyone else feels, but supporting old schemas of the
config files will be more hassle than it's worth.  The XML config files are
directly deserialized into an object (XML elements get mapped to the
properties with the same name, as per the default XML deserialization, etc),
and having multiple versions of the configuration classes sitting around
will be hard to deal with.

So....I think that the config files should be deleted and replaced with new
ones from the new version so they're guaranteed to be readable.

3) Is all of this maybe mitigated if we actually get updates to work
> properly, i.e. make sure that config and data gets preserved when one
> updates the app but gets deleted with a full uninstall? In that case we
> could also enforce a certain update order and would not have to make sure
> that every new version can read any old config format.
>
> > > -          Fix some strange shortcut stuff with dbsetup
> >
> > Can you be specific? There are probably a few problems but if I know
> > what you have found it will be easier...
>
> There are some strange rules with regard to advertised shortcuts, key
> paths
> of components, per user settings and stuff I all once knew about MSI but
> which I have to look up again. This is more a point where I would like to
> be
> sure that I have done things right than an actual problem.
>
> > Thanks again, it's a lot more user-friendly now!
>
> So I guess some people have tried the installer and it works? Glad to hear
> :)


I've been able to build it just fine but haven't had a chance to install
it.  It's on my TODO list for the next few days, but classes just started
again and I'm even busier than I was (d'oh!).  I really need to, though,
because I want to push it out to my 30-node cluster (it's still using
1.0.5on there).  The new MSI GUI (where you can select packages, etc)
is
great.....but one thing I'm running into is how to deploy it from the
command line.  Like, I'd just like to be able to run msiexec remotely using
psexec with some command-line switches to only install the executor service,
for example.  Guess I'll have to read up on MSI and MST's.  I'll let
everyone know what I find.

-Matt
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Alchemi-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/alchemi-developers

Reply via email to