473,890 Members | 1,722 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Deployment Project/MSI/installer problems

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
programmaticall y, 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 RemovePreviousV ersions 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
Jul 21 '05 #1
5 4935
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 (RemovePrevious Versions), 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=v omus 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.gr oogroo.com> wrote in message
news:uz******** ******@TK2MSFTN GP15.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
programmaticall y, 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 RemovePreviousV ersions 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

Jul 21 '05 #2
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\.DEF AULT\....,
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*******@nosp am.cox.net> wrote in message
news:OX******** ******@TK2MSFTN GP09.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 (RemovePrevious Versions), 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=v omus 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.gr oogroo.com> wrote in message
news:uz******** ******@TK2MSFTN GP15.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
programmaticall y, 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 RemovePreviousV ersions 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


Jul 21 '05 #3
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.Configur ation.Install.I nstaller).

Arun

"Arun Bhalla" <bh****@arun.gr oogroo.com> wrote in message
news:%2******** ********@TK2MSF TNGP15.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\.DEF AULT\...., 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*******@nosp am.cox.net> wrote in message
news:OX******** ******@TK2MSFTN GP09.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 (RemovePrevious Versions), 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=v omus 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.gr oogroo.com> wrote in message
news:uz******** ******@TK2MSFTN GP15.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
programmaticall y, 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 RemovePreviousV ersions 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



Jul 21 '05 #4
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.gr oogroo.com> wrote in message
news:%2******** ********@TK2MSF TNGP15.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\.DEF AULT\....,
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*******@nosp am.cox.net> wrote in message
news:OX******** ******@TK2MSFTN GP09.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 (RemovePrevious Versions), 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=v omus 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.gr oogroo.com> wrote in message
news:uz******** ******@TK2MSFTN GP15.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
> programmaticall y, 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 RemovePreviousV ersions 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
>
>



Jul 21 '05 #5
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\.DEF AULT, but that might be a bad assumption -- it makes too much
sense!

Thanks,
Arun
"Phil Wilson" <pd*******@nosp am.cox.net> wrote in message
news:eE******** ******@TK2MSFTN GP09.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.gr oogroo.com> wrote in message
news:%2******** ********@TK2MSF TNGP15.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\.DEF AULT\....,
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*******@nosp am.cox.net> wrote in message
news:OX******** ******@TK2MSFTN GP09.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 (RemovePrevious Versions), 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=v omus 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.gr oogroo.com> wrote in message
news:uz******** ******@TK2MSFTN GP15.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
> programmaticall y, 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 RemovePreviousV ersions 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
>
>



Jul 21 '05 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
4102
by: T | last post by:
I have a web site i want to deploy using a VS.NEt set up project. I have no problems with that, that is fine and works no problem. But the web application uses a custom event log to log application messages. The asp.net application will not be running under an account with administrative permissions and so this will not be able to create the custom event log.
6
2039
by: Paul | last post by:
Hello everyone: I am developing a VB.Net Windows Application and I am now ready to create the deployment project for it. This application needs to be installable on a different number of users / clients, and the application has an Access DB out on their network. How can I create a deployment routine where I can have a dialog box prompt for the network share (i.e. \\server\dbfolder) at install-time? Once network the share is specified...
10
383
by: Arun Bhalla | last post by:
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...
7
2849
by: dhussong | last post by:
I have created a Setup and Deployment project in Visual Studio.NET 2003. After my installation has completed running I'd like to launch the EXE that I just installed. I've found how to launch the EXE in the Custom Actions area of the Setup and Deployment project. Unfortunately when the EXE is launched it causes the setup program to stay open until the EXE has been exited. Anyone have any ideas how to launch the EXE and get the setup...
3
2487
by: Chris Rennert | last post by:
Hey all, we have a project that we would like to use ClickOnce deployment on, and although it all seems straightforward we are having a few issues concerning SQL Server Express and clickonce. We are using C# for our development language, and the application itself runs fine until we get to a part that accesses the database. When it tries to hit the database it bombs saying it can't find it. We even created a connection string that...
1
1899
by: Gene | last post by:
I would like to know if the following is even possible with the visual studio.net Setup and Deployment project. 1. During the deployment after creation of application directory the setup needs to prompt user to select another location to send a data file elsewhere on target machine (with ability to create this directory). 2. After that this secondary location selected/created by the user,
3
1297
by: SimeonArgus | last post by:
I am using Visual Studio 2005, and I have created a deployment project to distribute the app I've built. Now, I need to add a dialog (which I've done) to collect two prompts. Based on those two prompts, I need to add a line to a config file. Here's my catch: How do I modify the installer to write those two items to a config file... or even better .. how do I execute an SQL command without writing my own installer app? I'm so close that...
1
1507
by: MimiMi | last post by:
I have a deployment project that was originally created in VS2003. Since I don't have VS2003, I now open it in VS2005, but then of course VS2005 has to convert it. Everything seems to work fine. I build the project and an installer.msi - file as well as a setup.exe - file is created. Now to the problem: double-clicking the setup.exe doesn't work! It gives me the error "An error occured while downloading a required file. You may retry...
3
5861
by: KennethLundin | last post by:
Hi, i'm developing a solution in VS9/CSharp. Now I'm constructing a deployment project for my appliation (thick, database driven, winforms, standard, good old type of application). During installation I also install the PostgreSQL database and along with that I need to execute some Custom Actions. I've created a Custom Installer component in CSharp and calls it on Install/Rollback/ uninstall and everything works great (Custom Actions...
0
9812
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
1
10899
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10446
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9614
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
8004
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
7154
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5832
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
6032
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
4255
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.