Re: [WiX-users] Custom action sequencing problem
Oki..I could get the systray process killed but the tray icon waits for a mouse over to disapear, because of that the installer throws an icon file in use dialog.Is there a way to avoid this ? Alexander Shevchuk wrote: > > "Files In Use" dialog is shown by InstallValidate action. Schedule your > custom action before InstallValidate. > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Anidil > Sent: Friday, February 22, 2008 3:16 AM > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Custom action sequencing problem > > > I use the following custom action to kill systray process befre the > uninstall. > > > > > > Installed > > > This works fine but i get the Files in Use dialog before the CA actually > runs.How do i be sequencing the CA to run at the start of uninstall? Or is > there any way to sequence 'Files in Use' dialog? Please help > -- > View this message in context: > http://www.nabble.com/Custom-action-sequencing-problem-tp15632069p15632069.html > Sent from the wix-users mailing list archive at Nabble.com. > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- View this message in context: http://www.nabble.com/Custom-action-sequencing-problem-tp15632069p15706899.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Does MSI require JRE?
I noticed when I initially tested MSI on a machine I was asked to install a JRE . I have not experienced this since and am wondering if there is any chance that the installer is dependent on a Jave runtme environment..please clarify. -- View this message in context: http://www.nabble.com/Does-MSI-require-JRE--tp15706815p15706815.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrade Package
Looks like you don't have all required conditions in place: - New Product/@Id, Product/@Version (only first three digits count), and Package/@Id - Product/@Language is listed in Package/@Languages and Product/@Language is the same as in the previous version. - Same Product/@UpgradeCode My understanding of the major upgrade process is here: http://blogs.technet.com/alexshev/archive/2008/02/15/from-msi-to-wix-part-8-major-upgrade.aspx From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geeman Yip Sent: Tuesday, February 26, 2008 3:28 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgrade Package I'm using WIX 3.0.3808 I'm trying to create a package such that if an older version is found, completely uninstall the older version, then install the newer version. It seems like my package is upgrading the bits fine but the old version still shows up in my add/remove programs. I'm currently using the following elements which is doing the upgrade. Any ideas? Thanks -geeman - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Need a custom action with UAC elevated privileges before InstallInitialize
Some of this is probably about ownership. The COM+, IIS, Visual Studio teams own the deployment/configuration for COM+, IIS, C++ redist and so on. It's these teams that need poking to provide infrastructure that integrates with MSI. Similarly, when the MMC team provides managed code classes to install MMC plugins it's the MMC team that needs to be told to provide a MSI-friendly way to install snap-ins, not the MSI team. I'm not boggled that they provided the single transaction install. Unlike other areas, this is one that they do really own and can do something about. Also, it is true that more and more enterprises (including Microsoft) are unhappy with the idea of providing one monolithic MSI (that's the one MSI=one product assumption), and sometimes this is due to organizational boundaries where each group owns their own MSI and they want to keep it that way for testing and maintenance, but marketing wants the result to look like a single product in some way. So making a series of MSIs into one transaction seems worthy to me. What's missing is an actual chainer that provides one UI (instead of one per MSI) and the infrastructure to deal with FilesInUse during the subsequent silent installs, reboots etc. Phil Wilson From: Brian Rogers [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 20, 2008 9:51 AM To: Bob Arnson Cc: Wilson, Phil; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Need a custom action with UAC elevated privileges before InstallInitialize I have seen these types of tools used in the past. Mainly for database migrations and other more challenging configurations. I would agree that it would be best to have tool that ran after the installer or invoked at stages during the installation as the user. At that point the Windows Installer server really just becomes a bootstrapper for tools that work better. It acts like nothing more then a sequencing and file copy device which is how some people are using it now. I understand that Windows Installer offers some features that would be hard to do on your own (upgrades, rollbacks, etc.). Where I am at a loss is, over the years, these are some of the skimpy configuration options MSI offers: 1. Registry 2. INI 3. Services (weakly) 4. COM+ (very, very weakly) I really think the push should be back on the Windows Installer team. Technology has changed, they need to change with it. Advanced installations will just continue to get more complex. Why I went with WIX over other companies such as InstallShield was for these reasons. 1. Better COM+ 2. Better XML config 3. Better IIS config 4. Cheap (nothing is free as we need to support it if unable to get a fix soon enough) But there still needs to be work on most of these features (no offense meant AT ALL, what is there is great!). What about truly returning a machine to clean on an uninstall. Why can't we write to a reserved location of the installed MSI database to keep our configuration changes on the machine instead of going nuts on the registry? Why, after all these years, do they still not support COM+, XML, IIS or invoking COM (MS has or makes the technology for all of these). Why can't we have better UI? Why isn't there an easy way to do data manipulation for text (string values)? How about some Regex? How about multiple codepages per package? Don't get me wrong, GUIDs are great for component association, but isn't there something else that could be used so managing patches and automation was a bit more simple? How about just allowing for a hash value or string of n length so that, we the developers, can control how the key will be updated when we need to change it? If you are going to break component rules, you will more then likely do it with or without GUIDs. I see their use for product, package, upgrade, etc codes... Overall, it just boggles my mind that they give us "chaining" in 4.5 and we are supposed to jump up and down! There are still huge time problems with large installations. You need to change the database schema in order to support more than, what, 32K files? 2GB+ installs can take hours when all you are doing is coping down files. The Vista UAC prompt should happen when the MSI starts for MSI's that have defined they will need it. This comes into play when the installation takes a long time and the users leaves the machine for a while. Some users don't know to wait for UAC prompt and it will timeout and kill the install. Leaving things in a bad state. An MSI is basically a database, why not use it like one instead of writing stuff into the registry? Please don't mistake the fact that I like using Windows Installer as a tool, I just think it needs to become more robust at this point. Installation is challenging, no doubt about it. But it seems like using MSI can make mountains out of ant hills at times. With all the additional tools and custom actions that have been written to fit into Windows Installer, more then
[WiX-users] Adding an ok/cancel popup dialog?
We just recently added the Upgrade Id value to the installer and the testers have complained that it deletes the old version of the program without asking first, so I'm trying to add an ok/cancel popup dialog at the first step of the installer if a previous version is detected to warn them about that. I hooked up the dialog to the "Next" button for the welcome dialog and everything seem to work fine, except that if you hit "OK" it goes back to the welcome dialog and doesn't go on to the next section of the installer until you hit "Next" again. Is there any way to make the Welcome page wait on the results of the spawned dialog before evaluating the next Publish action in the list? Or do I just need to give up and make the warning a standalone dialog page rather than a popup? What I've got currently is: ... 1 1 1 Thanks! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrade Package
I'm using WIX 3.0.3808 I'm trying to create a package such that if an older version is found, completely uninstall the older version, then install the newer version. It seems like my package is upgrading the bits fine but the old version still shows up in my add/remove programs. I'm currently using the following elements which is doing the upgrade. Any ideas? Thanks -geeman - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Cannot create COM components when installed under Vista
Hi,
Quick question. Do you install the app "For all users"? You can du this by
setting the property "ALLUSERS" to 1. This ensures that the COM registry keys
are registered under the HKCR part that is under HKLM and not under HKCU.
Remember, the HKCR key is a "logical" key that is a combination of the
HKLM\Software\Classes and HKCU\Software\Classes keys. When installing without
the ALLUSERS property set to 1 (you should set it to 1 and not 2 to ensure that
everything is registered under HKLM - the value 2 means that HKLM is preffered,
but the install will fall-back to HKCU if the installing user is not
privileged).
I had the same problem last week when I had not set the ALLUSERS property at
all, which means that it defaults to the current user only. You can read about
the ALLUSERS property in the MSI documentation.
Regards,
Arild
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul McLaughlin
Sent: 26. februar 2008 20:59
To: WiX Users
Subject: [WiX-users] Cannot create COM components when installed under Vista
There are several parts to this issue, so I will try to be as clear as possible
with each part.
PROBLEM SUMMARY:
The goal is to install an ActiveX component on a client system (it is strictly
for OLE automation, no UI) and have some JavaScript create it and use methods
on it. It works just fine under Windows XP, but not under Vista.
FAILURE ANALYSIS:
It appears that the .msi package creates the registry keys for the ActiveX
component with insufficient user privileges. Specifically, if I open up
RegEdit.EXE and right-click and choose "Permissions..." on any one of the
registry keys created for the component, I see my exact user name from my
company's network domain. For example, "Paul McLaughlin
(\paulm)". Any time I see my name specifically in the list like
this, the control cannot be created from JavaScript under Vista using "new
ActiveXObject()" as you will see below in the source. Again, XP seems to be OK
with this.
MANUAL FIX:
In order to get the component created in JavaScript under Vista, after install
I have to manually remove the keys from the registry that the .msi created and
manually add them again. I do this by some exported Windows Registry .REG
files that contain the exact same entries and I just double-click on them from
Explorer to put them back. After I do this, and then I right-click on any one
of these registry keys in RegEdit.EXE, I do NOT see my name in the
"Permissions..." dialog, but rather my LOCAL MACHINE's "Users" group. For
example, "Users (LowRiderDevVista\Users)". When this is the case, the
JavaScript is able to create an instance of the COM component and the
JavaScript works!
Obviously, I want Windows Installer via WiX to register the component and have
it all work under Vista as well as XP.
Here are my sources (partial):
WIX:
...
...
JavaScript from an .HTA web application file that is installed.
var oAXM = new ActiveXObject("MSI.AXM.1"); // Will throw() if it cannot be
created.
oAXM.Test();
I have also tried setting the Package/InstallPrivileges attribute to "limited"
to see if for some reason that helped, but it made no difference. I do not see
any other items in the WiX documentation that might suggest other privilege
settings for Vista or install for that matter.
I am using WiX build 3.0.2925.
Thank you for any information about this issue you might have.
-Paul
Need to know the score, the latest news, or you need your Hotmail(r)-get your
"fix". Check it out.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Cannot create COM components when installed under Vista
There are several parts to this issue, so I will try to be as clear as possible
with each part.
PROBLEM SUMMARY:
The goal is to install an ActiveX component on a client system (it is strictly
for OLE automation, no UI) and have some JavaScript create it and use methods
on it. It works just fine under Windows XP, but not under Vista.
FAILURE ANALYSIS:
It appears that the .msi package creates the registry keys for the ActiveX
component with insufficient user privileges. Specifically, if I open up
RegEdit.EXE and right-click and choose "Permissions..." on any one of the
registry keys created for the component, I see my exact user name from my
company's network domain. For example, "Paul McLaughlin
(\paulm)". Any time I see my name specifically in the list like
this, the control cannot be created from JavaScript under Vista using "new
ActiveXObject()" as you will see below in the source. Again, XP seems to be OK
with this.
MANUAL FIX:
In order to get the component created in JavaScript under Vista, after install
I have to manually remove the keys from the registry that the .msi created and
manually add them again. I do this by some exported Windows Registry .REG
files that contain the exact same entries and I just double-click on them from
Explorer to put them back. After I do this, and then I right-click on any one
of these registry keys in RegEdit.EXE, I do NOT see my name in the
"Permissions..." dialog, but rather my LOCAL MACHINE's "Users" group. For
example, "Users (LowRiderDevVista\Users)". When this is the case, the
JavaScript is able to create an instance of the COM component and the
JavaScript works!
Obviously, I want Windows Installer via WiX to register the component and have
it all work under Vista as well as XP.
Here are my sources (partial):
WIX:
...
...
JavaScript from an .HTA web application file that is installed.
var oAXM = new ActiveXObject("MSI.AXM.1"); // Will throw() if it cannot be
created.
oAXM.Test();
I have also tried setting the Package/InstallPrivileges attribute to "limited"
to see if for some reason that helped, but it made no difference. I do not see
any other items in the WiX documentation that might suggest other privilege
settings for Vista or install for that matter.
I am using WiX build 3.0.2925.
Thank you for any information about this issue you might have.
-Paul
_
Need to know the score, the latest news, or you need your Hotmail®-get your
"fix".
http://www.msnmobilefix.com/Default.aspx-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Checking for Widnows 2008 server components?
Thomas, funny you should ask. I just ran across these tools for installing windows components about a week ago: Instaling windows components < Vista or 2008 http://support.microsoft.com/kb/222444 Installing windows components >= Vista or 2008 Command Line Install of IIS http://www.iis.net/articles/onepagearticle.ashx/IIS7/Deploy-an-IIS7-Serv er/Installing-IIS7/Understanding-Setup-in-IIS7 New in Windows Vista and Windows Server Longhorn is the pkgmgr.exe command line tool. Pkgmgr is used to install and uninstall Windows optional features and replaces sysocmgr.exe. The article How to install IIS7 on the Command Line will provide you with a step-by-step walkthrough of installing IIS on Windows Vista or Windows Server Longhorn using the pkgmgr tool. To check for IIS, at least, I check : HKLM\Software\Microsoft\InetStp\ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Tomiczek Sent: Tuesday, February 26, 2008 5:09 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Checking for Widnows 2008 server components? What is the recommended way to check for Windows 2008 server components to be installed? In order to make sure, for example, IIS is installed, PowerShell is installed etc.? If not, is there a recommended standard way to install those? Exchange etc. just break off and let the user install manually. I assume this IS the recommended way then? Thomas Tomiczek - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] ComPlusExtension v3
When using candle and light, what do you link to so it recognizes the ComPlusExtension schema in v3? I'm getting this error: error CNDL0200 : The Component element contains an unhandled extension element 'complus:ComPlusApplication'. Please ensure that the extension for elements in the 'http://schemas.microsoft.com/wix/ComPlusExtension' namespace has been provided. Or am I not defining the namespace correctly? xmlns:complus="http://schemas.microsoft.com/wix/ComPlusExtension"; - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Why be a tiny cocktail sausage, when you can be a mighty wiener.
Travel the world and see more nipples with your longer, thicker passport to sexual happiness.- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Checking for Widnows 2008 server components?
What is the recommended way to check for Windows 2008 server components to be installed? In order to make sure, for example, IIS is installed, PowerShell is installed etc.? If not, is there a recommended standard way to install those? Exchange etc. just break off and let the user install manually. I assume this IS the recommended way then? Thomas Tomiczek - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Two installers for the same component - how?
I have the following problems. I need to install two different components: * ONE is basically a server control application, with a website, possibly a database and definitely a windows service that does all the logic. * TWO is a server control agent that works together with the first server. Now, for some reason naturally the server the server system is installed on also CAN contain the agent. This is not a prerequisite, but it is an "easy" case. In fact, the light version of the server (not licensed) will ONLY use a named pipe transport to talk to an agent locally on the same system. In fact, due to certain operations of the server (tracking memory usage, CPU usage) it makes sense to always install the agent also on the local system. For easy setup I would rather not have the server installer be totally separate from the agent installer. My idea is to have the installers integrated, so that the server ALSO installs the agent, but does so in a way that blocks agent installs. Any way to do so? Or is the only sensible way in the MSI world (in the way MSI is supposed to work) call the agent installer from the server installer then? Please note that maintainability is NOT my concern - as agent and server talk a special protocol and have to be in sync, it makes no sense to patch the agent alone. What is the recommended way to handle this? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Prevent registry key from being removed duringuninstall? AND Only create not existing registry entrieswhile install?
Hello Mike, thank you for your answers! The situation is the following: The version of the msi package will change but the (meanwhile by the user) customized registry settings should not be overwritten by repair/uninstall (same installer version) or by installing a newer version of the msi. In other words: Existing registry settings must not overwritten or deleted by any process... I tried to read out the existing settings by using a property: Then I store the property value into the registry during install: That worked except one point: The "PersonalFolder" will always be replaced so that the path will be appanded on every install: "C:\Documents and Settings\Administrator\My Documents\C:\Documents and Settings\Administrator\My Documents\C:\Documents and Settings\Administrator\My Documents\MyProgTemplates" So I moved "[PersonalFolder]" to the Value attibute of the Property tag: But there the [PersonalFolder] property is not replaced during install so that in the registry the following is stored: "DefaultTemplates"="[PersonalFolder]MyProgTemplates" That's why my idea does not work... Have you any ideas? Thanks Ingo -Ursprüngliche Nachricht- Von: Mike Dimmick [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 26. Februar 2008 02:02 An: Beyer, Ingo; wix-users@lists.sourceforge.net Betreff: RE: [WiX-users] Prevent registry key from being removed duringuninstall? AND Only create not existing registry entrieswhile install? 1) I'm assuming by 'registry key' you mean any value/data pair. The 'key' is strictly a container for values (one of which can be the default value). If the key is empty - contains no values and the default value has no data - then Windows Installer deletes the key. To keep values even after all products installing that value have been uninstalled, mark the component which contains the value as Permanent. This will have the effect of preserving the key path and all the other resources in the component. 2) Declare all the registry values you need. Windows Installer will write all registry values in a Component if the key path for that component needs to be updated. If the key path is a file, the component will be installed if the file is missing, if the file already installed doesn't have a version number and a version number is recorded in the File table, if the file already installed hasn't been modified if no version number is recorded, or if the version in the File table is newer. For registry values, if the key or value is missing or the value data is different from the data in the package, the component is considered out-of-date and Windows Installer will install the whole component (files, registry values, etc, etc). I recommend that you treat registry values that you install as being immutable, changeable only by the next version of your installer. I believe there's a risk that user customizations could be overwritten by repairs or upgrades if installed registry values are edited. Stick to the bare minimum required to allow the components to be located - do the rest in initial program startup. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Beyer, Ingo Sent: 25 February 2008 16:42 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Prevent registry key from being removed duringuninstall? AND Only create not existing registry entrieswhile install? Hi all, I've two questions. I tried to solve them by myself, but I cannot find informations in the net... 1) How can I prevent a registry key from being removed during uninstall? 2) What do I have to do, that a only not existing registry entries (some REG_SZ's) will be create during install. Thanks a lot for help! Greetings Ingo - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
