Deployment Project/MSI/installer problems

[Arun Bhalla]

I'm working with VS.NET 2003 and .NET 1.1 (not SP1) on Windows XP SP1. My
application is using the Windows Installer Bootstrap. (I may have also
installed a module which detects requirements (.NET 1.1 -> MsiNetAssembly
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 application
is uninstalled, the target directory is not deleted, although it's empty. 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 alias for
HKLM when "Everyone" is selected, so that's no help. HKEY_USERS only seems
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 like 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 handle this
programmatically, in a custom action, but it seems like a common enough
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 for 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 is that
I have RemovePreviousVersions set to True. But if an installer is supposed
to remove its files and registry keys it created, and if the installer is
supposed to first uninstall previous versions (which makes sense in my
case), then how are previous configurations supposed to migrate forward?

* There doesn't seem to be a good way for defining deployment projects in
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 needs.
That seems like a management nightmare beyond the simple case!

Thanks for any comments or answers you might provide.

Arun

[Phil Wilson]

Some general comments:

It's not unusual for those folders to be marked read-only, but that's not
the reason your folders are not being removed - there must be something else
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 HKEY
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 a new
user logs on and attempts to access those registry entries they are missing
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 new
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 make it
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 just
replace existing files with higher versioned ones, msiexec /i <your msi>
REINSTALL=ALL REINSTALLMODE=vomus should update the files.

That final point, I don't get a good feel for what you want to do there, 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" <bh****@arun.groogroo.com> wrote in message
news:uz**************@TK2MSFTNGP15.phx.gbl...

I'm working with VS.NET 2003 and .NET 1.1 (not SP1) on Windows XP SP1. My
application is using the Windows Installer Bootstrap. (I may have also
installed a module which detects requirements (.NET 1.1 -> MsiNetAssembly
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 application
is uninstalled, the target directory is not deleted, although it's empty.
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 alias for
HKLM when "Everyone" is selected, so that's no help. HKEY_USERS only seems
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 like
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 handle
this
programmatically, in a custom action, but it seems like a common enough
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 for
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 is
that
I have RemovePreviousVersions set to True. But if an installer is supposed
to remove its files and registry keys it created, and if the installer is
supposed to first uninstall previous versions (which makes sense in my
case), then how are previous configurations supposed to migrate forward?

* There doesn't seem to be a good way for defining deployment projects in
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 needs.
That seems like a management nightmare beyond the simple case!

Thanks for any comments or answers you might provide.

Arun

[Arun Bhalla]

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 key
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 seems
that VS.NET 2003 doesn't have the capability to install keys for all users
without using a custom action.

Thanks,
Arun

"Phil Wilson" <pd*******@nospam.cox.net> wrote in message
news:OX**************@TK2MSFTNGP09.phx.gbl...

Some general comments:

It's not unusual for those folders to be marked read-only, but that's not
the reason your folders are not being removed - there must be something else 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 HKEY
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 a new user logs on and attempts to access those registry entries they are missing 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 new
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 make it 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 just replace existing files with higher versioned ones, msiexec /i <your msi>
REINSTALL=ALL REINSTALLMODE=vomus should update the files.

That final point, I don't get a good feel for what you want to do there, 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" <bh****@arun.groogroo.com> wrote in message
news:uz**************@TK2MSFTNGP15.phx.gbl...

I'm working with VS.NET 2003 and .NET 1.1 (not SP1) on Windows XP SP1. My application is using the Windows Installer Bootstrap. (I may have also
installed a module which detects requirements (.NET 1.1 -> MsiNetAssembly 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 application is uninstalled, the target directory is not deleted, although it's empty. 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 alias for HKLM when "Everyone" is selected, so that's no help. HKEY_USERS only seems 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 like
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 handle
this
programmatically, in a custom action, but it seems like a common enough
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 for
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 is
that
I have RemovePreviousVersions set to True. But if an installer is supposed to remove its files and registry keys it created, and if the installer is supposed to first uninstall previous versions (which makes sense in my
case), then how are previous configurations supposed to migrate forward?

* There doesn't seem to be a good way for defining deployment projects in 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 needs. That seems like a management nightmare beyond the simple case!

Thanks for any comments or answers you might provide.

Arun

[Arun Bhalla]

Well, I'd add registry entries using a custom action if I could somehow
detect deployment properties such as ALLUSERS within my installer custom
action (of type System.Configuration.Install.Installer).

Arun

"Arun Bhalla" <bh****@arun.groogroo.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

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 key
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 seems
that VS.NET 2003 doesn't have the capability to install keys for all users
without using a custom action.

Thanks,
Arun

"Phil Wilson" <pd*******@nospam.cox.net> wrote in message
news:OX**************@TK2MSFTNGP09.phx.gbl...

Some general comments:

It's not unusual for those folders to be marked read-only, but that's not

the reason your folders are not being removed - there must be something

else

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 HKEY 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 a

new

user logs on and attempts to access those registry entries they are

missing

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 new
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 make

it

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

just

replace existing files with higher versioned ones, msiexec /i <your msi>
REINSTALL=ALL REINSTALLMODE=vomus should update the files.

That final point, I don't get a good feel for what you want to do there, 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" <bh****@arun.groogroo.com> wrote in message
news:uz**************@TK2MSFTNGP15.phx.gbl...

I'm working with VS.NET 2003 and .NET 1.1 (not SP1) on Windows XP SP1.

My application is using the Windows Installer Bootstrap. (I may have also
installed a module which detects requirements (.NET 1.1 -> MsiNetAssembly 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 application is uninstalled, the target directory is not deleted, although it's empty. 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 alias for HKLM when "Everyone" is selected, so that's no help. HKEY_USERS only seems 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 like 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 handle this
programmatically, in a custom action, but it seems like a common enough 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 for 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 is
that
I have RemovePreviousVersions set to True. But if an installer is supposed to remove its files and registry keys it created, and if the installer is supposed to first uninstall previous versions (which makes sense in my
case), then how are previous configurations supposed to migrate forward?
* There doesn't seem to be a good way for defining deployment projects in 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 needs. That seems like a management nightmare beyond the simple case!

Thanks for any comments or answers you might provide.

Arun

[Phil Wilson]

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 (the
non-installing user) logs on, an entry point (typically a shortcut) causes a
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 a
general one that refers to repair in Office, and mentions keypaths and
repairs, the idea being that missing files or registry entries get repaired,
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 also
fails to take account of new users who log on after you install the product.
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 and
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" <bh****@arun.groogroo.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

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 key
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 seems
that VS.NET 2003 doesn't have the capability to install keys for all users
without using a custom action.

Thanks,
Arun

"Phil Wilson" <pd*******@nospam.cox.net> wrote in message
news:OX**************@TK2MSFTNGP09.phx.gbl...

Some general comments:

It's not unusual for those folders to be marked read-only, but that's not
the reason your folders are not being removed - there must be something

else

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 HKEY
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 a

new

user logs on and attempts to access those registry entries they are

missing

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 new
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 make

it

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

just

replace existing files with higher versioned ones, msiexec /i <your msi>
REINSTALL=ALL REINSTALLMODE=vomus should update the files.

That final point, I don't get a good feel for what you want to do there,
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" <bh****@arun.groogroo.com> wrote in message
news:uz**************@TK2MSFTNGP15.phx.gbl...

> I'm working with VS.NET 2003 and .NET 1.1 (not SP1) on Windows XP SP1. My > application is using the Windows Installer Bootstrap. (I may have also
> installed a module which detects requirements (.NET 1.1 -> MsiNetAssembly > 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 application > is uninstalled, the target directory is not deleted, although it's empty. > 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 alias for > HKLM when "Everyone" is selected, so that's no help. HKEY_USERS only seems > 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 like
> 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 handle
> this
> programmatically, in a custom action, but it seems like a common enough
> 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 for
> 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 is
> that
> I have RemovePreviousVersions set to True. But if an installer is supposed > to remove its files and registry keys it created, and if the installer is > supposed to first uninstall previous versions (which makes sense in my
> case), then how are previous configurations supposed to migrate
> forward?
>
> * There doesn't seem to be a good way for defining deployment projects in > 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 needs. > That seems like a management nightmare beyond the simple case!
>
> Thanks for any comments or answers you might provide.
>
> Arun
>
>

[Arun Bhalla]

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" <pd*******@nospam.cox.net> wrote in message
news:eE**************@TK2MSFTNGP09.phx.gbl...

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 (the non-installing user) logs on, an entry point (typically a shortcut) causes a 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 a general one that refers to repair in Office, and mentions keypaths and
repairs, the idea being that missing files or registry entries get repaired, 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 also fails to take account of new users who log on after you install the product. 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 and 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" <bh****@arun.groogroo.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

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 key 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 seems that VS.NET 2003 doesn't have the capability to install keys for all users without using a custom action.

Thanks,
Arun

"Phil Wilson" <pd*******@nospam.cox.net> wrote in message
news:OX**************@TK2MSFTNGP09.phx.gbl...

Some general comments:

It's not unusual for those folders to be marked read-only, but that's not the reason your folders are not being removed - there must be something

else

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 HKEY 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 a

new

user logs on and attempts to access those registry entries they are

missing

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

new 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 make it

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

just

replace existing files with higher versioned ones, msiexec /i <your

msi> REINSTALL=ALL REINSTALLMODE=vomus should update the files.

That final point, I don't get a good feel for what you want to do there, 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" <bh****@arun.groogroo.com> wrote in message
news:uz**************@TK2MSFTNGP15.phx.gbl...
> I'm working with VS.NET 2003 and .NET 1.1 (not SP1) on Windows XP SP1. My

> application is using the Windows Installer Bootstrap. (I may have

also > installed a module which detects requirements (.NET 1.1 ->

MsiNetAssembly

> 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

application

> is uninstalled, the target directory is not deleted, although it's

empty.

> 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 alias for

> HKLM when "Everyone" is selected, so that's no help. HKEY_USERS only

seems

> 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

like > 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 handle > this
> programmatically, in a custom action, but it seems like a common enough > 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 for > 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 is > that
> I have RemovePreviousVersions set to True. But if an installer is

supposed

> to remove its files and registry keys it created, and if the installer is

> supposed to first uninstall previous versions (which makes sense in

my > case), then how are previous configurations supposed to migrate
> forward?
>
> * There doesn't seem to be a good way for defining deployment

projects in

> 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

needs.

> That seems like a management nightmare beyond the simple case!
>
> Thanks for any comments or answers you might provide.
>
> Arun
>
>