部署项目/ MSI /安装程序问题 [英] Deployment Project/MSI/installer problems

问题描述

我正在使用Windows XP SP1上的VS.NET 2003和.NET 1.1（不是SP1）。我的

应用程序正在使用Windows Installer Bootstrap。 （我可能也已经安装了一个检测要求的模块（.NET 1.1 - > MsiNetAssembly

支持。）我有一些关于MSI及其问题的问题和疑问。

属性。


*这可能是我目前最大的烦恼。当安装程序创建

目标目录时，它将它们设置为只读。当应用程序

被卸载时，目标目录不会被删除，虽然它是空的。我

假设这是因为目标目录是只读的，而且安装程序

并没有试图强行删除，但我不是肯定的。为什么这个

发生了，无论如何，我怎么能纠正它。我不确定这是否已经

这个项目对我来说一直是个问题，但它也不是最近的

新问题。


*当用户选择安装Everyone时，我需要为所有用户修改

注册表。我不确定在VS.NET的IDE（或其他？）中有一个合理的方法来做这个

。当Everyone时，User / Machine Hive是

HKLM的别名。被选中，所以没有帮助。 HKEY_USERS似乎只对

有用（曾经）在.DEFAULT树中进行设置，但是当前用户无法处理

。我看过HKEY_PER_USER的引用，好像我想要的是什么，但我不知道如何访问它，而且几乎为零
在线文档，所以也许它是蒸发器。我想我可以通过自定义操作以编程方式处理这个

，但它似乎是一个很常见的

需要，我宁愿让安装程序处理得那么多尽管如此！

另外，自定义动作如何知道它应该为所有

用户设置密钥？ $ s $ b *自定义操作可以访问MSI的运行时属性吗？对于这个问题，我不确定用户的配置是否有好的方法
在升级期间保留，可能我的真正问题是

我将RemovePreviousVersions设置为True。但是如果一个安装程序被认为是b $ b来删除它创建的文件和注册表项，如果安装程序是

应该首先卸载以前的版本（这在我的

case），那么先前的配置应该如何向前迁移？


*似乎没有一种好的方法来定义

解决方案配置条款。例如，我可以在某个解决方案配置（例如Debug）中配置项目

来添加一些条件

编译常量（例如TRACE，DEBUG），我可以使用

中的常量#if块中的代码。如何在

部署项目中执行类似的操作？我听说过的一个解决方案是为每个有自己需求的解决方案配置创建一个不同的

部署项目。

这似乎是一个超越简单案例的管理噩梦！


感谢您提供的任何意见或解答。


Arun

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

推荐答案

一些一般评论：


将这些文件夹标记为只读，这并不罕见，但这不是

你的文件夹没有删除的原因 - 必须有其他的东西

在那里。通常它们会在卸载时被删除，除非

还有程序创建的文件仍在那里。


为所有用户执行注册表项的常用方法是将它们放入HKEY

用户（您可能还需要将它们放入HKCU）。我不知道Visual

Studio是否支持这个通用方案，但是一旦你这样做，当一个新的
用户登录并尝试访问这些注册表他们缺少的条目

为新用户，修复机制启动并安装它们。

这是安装用户特定数据的一般方式每个新的

用户。


保留用户配置部分是设计问题，部分是

维护问题。再一次，其中一些与Visual

Studio鼓励更新（RemovePreviousVersions）的方式有关，但其他工具使得它更容易构建补丁（msp文件）或者做次要升级（使用更新的文件重新安装

相同的MSI文件）。如果你使用完全相同的设置（

保存MSI文件中的ProductCode和内部安装程序Guids），只需用
替换版本较高的现有文件，msiexec / i< ;你的msi>

REINSTALL =所有REINSTALLMODE = vomus应该更新文件。


最后一点，我对什么感觉不太好你想在那里做一个

的具体例子可能会有用。


看起来你正在扩展Visual Studio设置的功能
项目，这就是为什么所有这些其他工具都存在的原因 - 很多都有你能够使用的更多功能。
http://installsite.org/pages/en/msi/authoring.htm


-

Phil Wilson

[微软MVP-Windows安装程序]

Windows权威指南安装程序
http://apress.com/book/bookDisplay.html?bID=280


Arun Bhalla < BH **** @ arun.groogroo.com>在消息中写道

news：uz ************** @ TK2MSFTNGP15.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...

我在工作在Windows XP SP1上使用VS.NET 2003和.NET 1.1（不是SP1）。我的
应用程序正在使用Windows Installer Bootstrap。 （我可能还安装了一个检测需求的模块（.NET 1.1 - > MsiNetAssembly
支持。）我对MSI及其
属性有一些问题和疑问。 *这可能是我目前最大的烦恼。当安装程序创建目标目录时，它将它们设置为只读。当应用程序
已卸载，目标目录不会被删除，虽然它是空的。
我认为这是因为目标目录是只读的并且
安装程序没有不要试图强行拆除，但我不是肯定的。无论如何，为什么会发生这种情况，我怎么能纠正它。我不确定这是否总是如此这个项目对我来说是一个问题，但它也不是最近新问题。

*当用户选择安装Everyone时，我需要修改所有用户的
注册表。我不确定是否有理由在VS.NET的IDE（或其他？）中这样做的方法。当Everyone时，User / Machine Hive是
HKLM的别名。被选中，所以没有帮助。 HKEY_USERS似乎对于在.DEFAULT树中进行设置非常有用（但永远），但是它并没有处理当前用户。我看过HKEY_PER_USER的引用，好像是我想要的，但我不知道如何访问它，而且几乎为零在线文档，所以也许它是蒸发器。我想我可以通过自定义操作以编程方式处理这个
，但这似乎是一个很常见的需求，我宁愿尽可能多地使用安装程序，<无论如何！
另外，自定义动作怎么知道它应该为所有
用户设置密钥？自定义操作可以访问MSI的运行时属性吗？

*就此而言，我不确定用户'
配置是否有好的方法在升级期间保留，可能我的真正问题是

我将RemovePreviousVersions设置为True。但是如果安装程序应该删除它创建的文件和注册表项，并且安装程序是否应该首先卸载以前的版本（这在我的
情况下是有意义的），那么如何以前的配置是否应该向前迁移？

*在解决方案配置方面，似乎没有一种很好的方法来定义部署项目。例如，我可以在某个解决方案配置（例如Debug）中配置
项目以添加一些
条件
编译常量（例如TRACE，DEBUG），我可以使用这些常量
在#if块中的代码中。如何在
部署项目中执行类似的操作？我听说过的一个解决方案是为每个有自己需求的解决方案配置创建一个不同的部署项目。
这似乎是一个超出简单案例的管理噩梦！
感谢您提供的任何意见或答案。

Arun

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

Hi Phil，


感谢您的评论。


好​​像有什么事情阻止了TARGETDIR的删除，

但是我无法理解。当我用MsiExec记录所有内容（* v）时，我不会看到任何错误。它说安装/删除成功发生了

没有错误。 TARGETDIR中没有隐藏或未隐藏的文件。一个

可能告诉我的事情是，我没有看到MsiExec尝试移除TARGETDIR的任何迹象，但我无法解释为什么会发生这种情况。 br />

我不明白你描述的修理机制是如何工作的。如果你暗示如果我将一个密钥添加到HKEY_USERS \ .DEFAULT \ ....，

，当用户登录时，某些软件（例如IE）检测到一个新密钥<在.DEFAULT中的
不在HKCU中但应该然后在那里安装密钥，

似乎并非如此。除非有人另有说法，否则VS.NET 2003似乎没有能力为所有用户安装密钥

而不使用自定义操作。
>

谢谢，

Arun


" Phil Wilson" < PD ******* @ nospam.cox.net>在消息中写道

新闻：OX ************** @ TK2MSFTNGP09.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...

一些一般性评论：<这些文件夹被标记为只读，这并不罕见，但这并不是你的文件夹没有删除的原因 - 必须有一些东西
别的去那里。通常它们会在卸载时被删除，除非有程序创建的文件仍在那里。

为所有用户执行注册表项的常用方法是将它们放在HKEY中用户（您可能还需要将它们放在HKCU中）。我不知道Visual
Studio是否支持这个通用方案，但是一旦你这样做，当一个
的新用户登录并尝试访问这些注册表项时，他们就会丢失
对于新用户，修复机制启动并安装它们。
这是为每个新用户安装用户特定数据的一般方式。

保留用户配置部分是设计问题，部分是维护问题。同样，其中一些与Visual
Studio鼓励更新（RemovePreviousVersions）的方式有关，但其他工具使
更容易构建补丁（msp文件）或进行小幅升级（重新安装
具有更新文件的相同MSI文件）。如果您使用完全相同的设置（以保留MSI文件中的ProductCode和内部安装程序Guids）和
只需用更高版本的文件替换现有文件，msiexec / i< your msi>
REINSTALL = ALL REINSTALLMODE = vomus应该更新文件。

最后一点，我对你想要做的事情感觉不太好，
具体的例子可能会有用。

看起来你正在扩展Visual Studio设置项目的功能，这就是为什么所有这些其他工具都存在的原因 - 很多都有更多的功能您可以使用。
http：// installsite.org/pages/en/msi/authoring.htm

-
Phil Wilson
[Microsoft MVP-Windows Installer]
权威指南到Windows Installer
http：// ap ress.com/book/bookDisplay.html?bID=280

Arun Bhalla < BH **** @ arun.groogroo.com>在消息中写道
新闻：uz ************** @ TK2MSFTNGP15.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...

我正在使用VS.NET 2003和Windows XP SP1上的.NET 1.1（不是SP1）。
我的应用程序正在使用Windows Installer Bootstrap。 （我可能还安装了一个检测要求的模块（.NET 1.1 - >
MsiNetAssembly支持。）我对MSI及其
属性有一些问题和疑问。 />
*这可能是我目前最大的烦恼。当安装程序创建目标目录时，它将它们设置为只读。当
时应用程序已卸载，目标目录不会被删除，虽然它的
为空。我认为这是因为目标目录是只读的而且
安装程序没有不要试图强行拆除，但我不是肯定的。无论如何，为什么会发生这种情况，我怎么能纠正它。我不确定这是否总是如此这个项目对我来说是一个问题，但它也不是最近新问题。

*当用户选择安装Everyone时，我需要为所有用户修改
注册表。我不确定这是否合理你可以在VS.NET的IDE（或其他？）中做到这一点。当Everyone时，User / Machine Hive是HKLM的别名
。被选中，所以没有帮助。 HKEY_USERS只有
似乎对.DEFAULT树中的设置有用（曾经），但是它并没有处理当前用户。我看过HKEY_PER_USER的引用，好像是我想要的，但我不知道如何访问它，而且几乎为零在线文档，所以也许它是蒸发器。我想我可以通过自定义操作以编程方式处理这个
，但这似乎是一个很常见的需求，我宁愿尽可能多地使用安装程序，<无论如何！
另外，自定义动作怎么知道它应该为所有
用户设置密钥？自定义操作可以访问MSI的运行时属性吗？

*就此而言，我不确定用户'
配置是否有好的方法在升级期间保留，可能我的真正问题是

我将RemovePreviousVersions设置为True。但是如果一个安装程序是
应该删除它创建的文件和注册表项，如果安装程序
应该首先卸载以前的版本（这在我的
情况下是有意义的），那么如何以前的配置是否应该向前迁移？

*在解决方案配置方面，似乎没有一种很好的方法来定义部署项目
。例如，我可以在某个解决方案配置（例如Debug）中配置
项目以添加一些
条件
编译常量（例如TRACE，DEBUG），我可以使用这些常量
在#if块中的代码中。如何在
部署项目中执行类似的操作？我听说过的一个解决方案是为每个具有自己的
需求的解决方案配置创建一个不同的部署项目。这似乎是一个超越简单案例的管理噩梦！

感谢您提供的任何意见或答案。

Arun

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

好吧，如果我能以某种方式使用自定义操作添加注册表项

检测部署属性，例如ALLUSERS在我的安装程序中自定义

操作（类型为System.Configuration.Install.Installer）。


Arun


Arun Bhalla < BH **** @ arun.groogroo.com>在留言中写道

新闻：％2 **************** @ TK2MSFTNGP15.phx.gbl ...

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...

我不知道我不明白你描述的修复机制是如何工作的。如果你暗示如果我将一个键添加到
HKEY_USERS \.DEFAULT \ ....，当用户登录并且某些软件（例如IE）检测到一个新密钥
时.DEFAULT不在HKCU，但应该然后在那里安装密钥，
似乎并非如此。除非有人另有说法，否则VS.NET 2003似乎无法为所有用户安装密钥而无需使用自定义操作。

谢谢，< Arun

Phil Wilson < PD ******* @ nospam.cox.net>在消息中写道
新闻：OX ************** @ TK2MSFTNGP09.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

else

继续。通常它们确实会在卸载
时被删除，除非有程序仍在其中创建文件。

为所有用户执行注册表项的常用方法是将它们放入$ b $中b HKEY用户（您可能还需要将它们放入HKCU）。我不知道Visual
Studio是否支持这个通用方案，但是一旦你这样做，当一个

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

新的

用户登录并尝试为新用户访问那些

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

缺少

的注册表项，并且修复机制启动并安装它们。
这是一般方式为每个新用户安装了特定于用户的数据。

保留用户配置部分是设计问题，部分是维护问题。同样，其中一些与Visual
Studio鼓励更新（RemovePreviousVersions）的方式有关，但其他工具使

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

它

更容易构建补丁（msp文件）或进行小的升级（用更新的文件重新安装
相同的MSI文件）。如果您使用完全相同的设置（以保留MSI文件中的ProductCode和内部安装程序Guids）和

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

只需

用更高版本的文件替换现有文件， msiexec / i<你的msi>
重新安装=所有REINSTALLMODE = vomus应该更新文件。

最后一点，我对你想要做的事情感觉不太好在那里，
a具体示例可能会有用。

看起来你正在扩展Visual Studio设置项目的功能，这就是为什么所有这些其他的原因工具存在 - 许多
有更多的功能你可以使用。
http://installsite.org/pages/en/msi/authoring.htm

-
Phil Wilson
[微软MVP-Windows Installer]
Windows Installer权威指南
http://apress.com/book/bookDisplay.html?bID=280

Arun Bhalla < BH **** @ arun.groogroo.com>在消息中写道
新闻：uz ************** @ TK2MSFTNGP15.phx.gbl ...

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...

我正在使用VS.NET 2003和Windows XP SP1上的.NET 1.1（不是SP1）。

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

我的应用程序正在使用Windows Installer Bootstrap。 （我可能还安装了一个检测需求的模块（.NET 1.1 - > MsiNetAssembly支持。）我对MSI及其
属性有一些问题和疑问。

*这可能是我目前最大的烦恼。当安装程序创建目标目录时，它将它们设置为只读。当卸载应用程序时，目标目录是没有删除，虽然它是空的。我认为这是因为目标目录是只读的而且
安装程序没有试图强行删除，但是我不是积极的。无论如何，为什么会发生这种情况，我怎么能纠正它。我不确定这个
对我这个项目是否一直是个问题，但它'''也不是最近的新问题。

*当用户选择安装Everyone时，我需要修改所有人的
注册表用户。我不确定是否有合理的方式来做
th是在VS.NET的IDE（或其他？）内。当Everyone时，User / Machine Hive是HKLM的别名。被选中，所以没有帮助。 HKEY_USERS在.DEFAULT树中设置似乎很有用（但永远不会），但是它并没有处理当前用户。我看过对HKEY_PER_USER的引用，看起来像我想要的那样是b $ b，但我不知道如何访问它，并且几乎为零在线文档，所以也许它是蒸发器。我想我可以通过自定义操作以编程方式处理这个
，但它似乎是一个常见的
足够的需求，我宁愿尽可能多地使用安装程序，<无论如何！
另外，自定义动作怎么知道它应该为所有
用户设置键
？自定义操作可以访问MSI的运行时属性吗？

*就此而言，我不确定用户'
配置是否有好的方法在升级期间保留，可能我的真正问题是

我将RemovePreviousVersions设置为True。但是如果安装程序应该删除它创建的文件和注册表项，并且安装程序应该首先卸载以前的版本（这在我的
情况下是有意义的），那么以前的配置应该如何迁移
forward？
*在解决方案配置方面，似乎没有一种好方法可以定义部署项目。例如，我可以在某个解决方案配置（例如Debug）中配置
项目以添加一些
条件
编译常量（例如TRACE，DEBUG），我可以使用在#if块中我的代码中的那些
常量。如何在
部署项目中执行类似的操作？我听说过的一个解决方案是为每个有自己需求的解决方案配置创建一个不同的部署项目。这似乎是一个超越简单案例的管理噩梦！

感谢您提供的任何意见或答案。

Arun

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

这篇关于部署项目/ MSI /安装程序问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！