Hmm, I just built an installer and ran it per-machine ("Everyone") with it
installing entries in HKCU. It didn't carry over to the test user account I
had created earlier this week.
I assume that new users' registry hives are initalized with
HKEY_USERS\.DEFAULT, but that might be a bad assumption -- it makes too much
sense!
Thanks,
Arun
"Phil Wilson" <pdjwilson@nospam.cox.net> wrote in message
news:eEdlogRuEHA.3860@TK2MSFTNGP09.phx.gbl...[color=blue]
> I didn't describe it accurately - it's actually HKCU where you install the
> registry entries, even for a per-machine install. When a different user[/color]
(the[color=blue]
> non-installing user) logs on, an entry point (typically a shortcut) causes[/color]
a[color=blue]
> check that those entries are present, and of course they will not be there
> for that user. The repair then installs those entries - you'd see a brief
> Windows Installer dialog box with a progress bar. The scheme requires
> ensuring that the registry entries are a keypath of the component, and
> Visual Studio doesn't have a lot of control in that area. This article is[/color]
a[color=blue]
> general one that refers to repair in Office, and mentions keypaths and
> repairs, the idea being that missing files or registry entries get[/color]
repaired,[color=blue]
> and therefore is often used to install registry entries for new users.
>
http://support.microsoft.com/default...b;en-us;290526
>
> It's very difficult to install registry keys for all users because of the
> requirement to enumerate all the users in the registry, and that design[/color]
also[color=blue]
> fails to take account of new users who log on after you install the[/color]
product.[color=blue]
> I suggest you do a test - it wouldn't take long to build an MSI with some
> registry entries in HKCU, install it per-machine, log in as another user[/color]
and[color=blue]
> see if the entries get installed as I described.
> --
> Phil Wilson
> [Microsoft MVP-Windows Installer]
> Definitive Guide to Windows Installer
>
http://apress.com/book/bookDisplay.html?bID=280
>
> "Arun Bhalla" <bhalla@arun.groogroo.com> wrote in message
> news:%239hEswHuEHA.3872@TK2MSFTNGP15.phx.gbl...[color=green]
> > Hi Phil,
> >
> > Thanks for your comments.
> >
> > It seems like there's something going on blocking the removal of
> > TARGETDIR,
> > but I can't figure it out. When I log everything (*v) with MsiExec, I
> > don't
> > see any errors. It says that installation/removal occurred successfully
> > with no errors. There are no files, hidden or not, in TARGETDIR. One
> > possibly telling thing is that I don't see any indication that MsiExec
> > tries
> > to remove TARGETDIR, but I can't explain why that would happen.
> >
> > I don't understand how the repair mechanism you describe is supposed to
> > work. If you are implying that if I add a key to
> > HKEY_USERS\.DEFAULT\....,
> > and when a user logs on and some software (e.g. IE) detects that a new[/color][/color]
key[color=blue][color=green]
> > in .DEFAULT isn't in HKCU but should be and then installs the key there,
> > that doesn't seem to be the case. Unless someone says otherwise, it[/color][/color]
seems[color=blue][color=green]
> > that VS.NET 2003 doesn't have the capability to install keys for all[/color][/color]
users[color=blue][color=green]
> > without using a custom action.
> >
> > Thanks,
> > Arun
> >
> > "Phil Wilson" <pdjwilson@nospam.cox.net> wrote in message
> > news:OXyTGQGuEHA.4040@TK2MSFTNGP09.phx.gbl...[color=darkred]
> >> Some general comments:
> >>
> >> It's not unusual for those folders to be marked read-only, but that's[/color][/color][/color]
not[color=blue][color=green][color=darkred]
> >> the reason your folders are not being removed - there must be something[/color]
> > else[color=darkred]
> >> going on there. Normally they do really get removed on an uninstall
> >> unless
> >> there are files created by programs still in there.
> >>
> >> The usual way to do registry entries for all users is to put them in[/color][/color][/color]
HKEY[color=blue][color=green][color=darkred]
> >> users (you might need to put them in HKCU too). I don't know if Visual
> >> Studio has support for this general scheme, but once you do that, when[/color][/color][/color]
a[color=blue][color=green]
> > new[color=darkred]
> >> user logs on and attempts to access those registry entries they are[/color]
> > missing[color=darkred]
> >> for the new user, and the repair mechanism kicks in and installs them.
> >> That's the general way that user-specific data is installed for each[/color][/color][/color]
new[color=blue][color=green][color=darkred]
> >> user.
> >>
> >> Preserving user configurations is partly a design issue, and partly a
> >> maintenance issue. Again, some of this is related to the the way Visual
> >> Studio encourages updates (RemovePreviousVersions), but other tools[/color][/color][/color]
make[color=blue][color=green]
> > it[color=darkred]
> >> easier to build patches (msp files) or do minor upgrades (reinstalling
> >> the
> >> same MSI file with updated files). If you use the exact same setup (to
> >> preserve ProductCode and internal installer Guids in the MSI file) and[/color]
> > just[color=darkred]
> >> replace existing files with higher versioned ones, msiexec /i <your[/color][/color][/color]
msi>[color=blue][color=green][color=darkred]
> >> REINSTALL=ALL REINSTALLMODE=vomus should update the files.
> >>
> >> That final point, I don't get a good feel for what you want to do[/color][/color][/color]
there,[color=blue][color=green][color=darkred]
> >> a
> >> concrete example might be useful.
> >>
> >> It looks like you're stretching the capabilities of Visual Studio setup
> >> projects, and there's a reason why all these other tools exist - many
> >> have
> >> more capabilties that you might be able to use.
> >>
http://installsite.org/pages/en/msi/authoring.htm
> >>
> >> --
> >> Phil Wilson
> >> [Microsoft MVP-Windows Installer]
> >> Definitive Guide to Windows Installer
> >>
http://apress.com/book/bookDisplay.html?bID=280
> >>
> >> "Arun Bhalla" <bhalla@arun.groogroo.com> wrote in message
> >> news:uzpCtq8tEHA.2820@TK2MSFTNGP15.phx.gbl...
> >> > I'm working with VS.NET 2003 and .NET 1.1 (not SP1) on Windows XP[/color][/color][/color]
SP1.[color=blue][color=green]
> > My[color=darkred]
> >> > application is using the Windows Installer Bootstrap. (I may have[/color][/color][/color]
also[color=blue][color=green][color=darkred]
> >> > installed a module which detects requirements (.NET 1.1 ->[/color]
> > MsiNetAssembly[color=darkred]
> >> > Support.) I have a few issues and questions regarding the MSI and its
> >> > properties.
> >> >
> >> > * This may be my biggest annoyance at the moment. When the installer
> >> > creates
> >> > the target directory, it's setting them as read-only. When the[/color]
> > application[color=darkred]
> >> > is uninstalled, the target directory is not deleted, although it's[/color]
> > empty.[color=darkred]
> >> > I
> >> > presume this is because the target directory is read-only and the
> >> > installer
> >> > doesn't try to force the removal, but I'm not positive. Why is this
> >> > happening, anyway, and how can I correct it. I'm not certain if this
> >> > has
> >> > always been a problem for me with this project, but it's also not a
> >> > recently
> >> > new problem.
> >> >
> >> > * When the user opts to install for "Everyone," I need to modify the
> >> > registry for all users. I'm not sure there's a reasonable way to do
> >> > this
> >> > within VS.NET's IDE (or otherwise?). The User/Machine Hive is an[/color][/color][/color]
alias[color=blue][color=green]
> > for[color=darkred]
> >> > HKLM when "Everyone" is selected, so that's no help. HKEY_USERS only[/color]
> > seems[color=darkred]
> >> > useful (ever) for setting within the .DEFAULT tree, but that doesn't
> >> > handle
> >> > current users. I've seen a reference to HKEY_PER_USER, which seems[/color][/color][/color]
like[color=blue][color=green][color=darkred]
> >> > what
> >> > I'd want, but I don't know how to access it, and there's almost zero
> >> > documentation online, so maybe it's vaporware. I suppose I could[/color][/color][/color]
handle[color=blue][color=green][color=darkred]
> >> > this
> >> > programmatically, in a custom action, but it seems like a common[/color][/color][/color]
enough[color=blue][color=green][color=darkred]
> >> > need, and I'd rather have the installer handle as much as possible,
> >> > anyhow!
> >> > Plus, how can the custom action know that it's supposed to set keys[/color][/color][/color]
for[color=blue][color=green][color=darkred]
> >> > all
> >> > users? Can the custom actions access the MSI's runtime properties?
> >> >
> >> > * For that matter, I'm not sure there's a good way for users'
> >> > configurations
> >> > to be retained during an upgrade, and possibly my real problem here[/color][/color][/color]
is[color=blue][color=green][color=darkred]
> >> > that
> >> > I have RemovePreviousVersions set to True. But if an installer is[/color]
> > supposed[color=darkred]
> >> > to remove its files and registry keys it created, and if the[/color][/color][/color]
installer[color=blue][color=green]
> > is[color=darkred]
> >> > supposed to first uninstall previous versions (which makes sense in[/color][/color][/color]
my[color=blue][color=green][color=darkred]
> >> > case), then how are previous configurations supposed to migrate
> >> > forward?
> >> >
> >> > * There doesn't seem to be a good way for defining deployment[/color][/color][/color]
projects[color=blue][color=green]
> > in[color=darkred]
> >> > terms of solution configurations. For instance, I can configure the
> >> > project
> >> > within a certain solution configuration (e.g. Debug) to add some
> >> > conditional
> >> > compilation constants (e.g. TRACE, DEBUG), and I can use those
> >> > constants
> >> > in
> >> > my code within #if blocks. How can I do something similar within a
> >> > deployment project? One solution I've heard is to create a different
> >> > deployment project for each solution configuration that has its own[/color]
> > needs.[color=darkred]
> >> > That seems like a management nightmare beyond the simple case!
> >> >
> >> > Thanks for any comments or answers you might provide.
> >> >
> >> > Arun
> >> >
> >> >
> >>
> >>[/color]
> >
> >[/color]
>
>[/color]
