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
5  4912 
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
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
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
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
>
>
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
>
>
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
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.
|
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...
|
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...
|
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...
|
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...
| | |
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,
|
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...
|
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...
|
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...
|
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,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
| | |
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,...
|
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...
|
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();...
|
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...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
