The problem with your suggestion is that there will not be a "first run"
ever. Since this is an Excel add-in (a DLL), it is loaded by Excel only
if the proper keys are placed in the registry for the current user.
Therefore, there isn't a chance to check whether those keys exist and
add them if not...
Another related question, for the same Excel add-in. As I stated, I want
this add-in to be available to all users. It seemed obvious to me that a
good place to install it would be under "Program Files/MyApp/". This
seemed to work well, at least for XP. Now, there are two types of files
that will show up under that directory that will be modified by my Excel
add-in:
* Log files, which could be unique per user and, therefore, could
be moved with no problems under "<USER>/Application Data/MyApp".
* DB files, updated remotely, of which there should be one
instance for all users in the machine.
The question is, specially for Vista, where do I put these changing
files (particularly the DB)? I want non-privileged users to be able to
use the add-in; for this, they must be able to read the DB files and,
more importantly, update them. Where should the SINGLE copy of these
files reside?
* Not under "Program Files/MyApp", because unprivileged users
cannot write there.
* Not under "All Users/Application Data/MyApp", because
unprivileged users cannot write there (or am I wrong)?
* Not under "<USER>/Application Data/MyApp", because I only want
one instance of this file to exist.
It looks like the only correct place would be to create a stand-alone
directory hanging from the root of the disk ("C:/MyApp/") and put
everything there. But I find this hateful and unprofessional.
Any ideas? Perhaps I am totally off the mark here? Thanks and best
regards.
On Mon, 2007-11-12 at 19:16 -0800, Bob Arnson wrote:
> Gonzalo Diethelm wrote:
>
> > I am using wix 2.0 to install an Excell add-in. The structure of
> > these add-ins is such that they require adding stuff in the registry
> > trees for Excel under both LOCAL_MACHINE (for the generic
> > configuration) and CURRENT_USER (for the user-specific
> > configuration). I can do this now without problems with a
> > CustomAction (and am in the process of switching it to be deferred,
> > to properly work under Vista), but just realized I am only correctly
> > handling the installation for ONE user in the machine (the actual
> > current user). I really would like to know what the proper way is to
> > handle the installation for ALL users in the machine:
>
>
> Move it out of the installer. You cannot reliably access all the HKCU
> hives for every user, only those who are logged in and running your
> app. So take a "first run" approach and offer to configure the HKCU
> data from the existing HKLM data if it's not present.
>
>
> --
> sig://boB
> http://joyofsetup.com/
--
Gonzalo Diethelm
[EMAIL PROTECTED]
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
