Re: [WiX-users] New Entry in Add/Remove Program when upgrade
You have to know the number of instances you will support before-hand and
generate an instance transform for each instance you will ever have. I
understood your requirement to have an open-ended number of instances,
each of a different build of your product. The multiple instance pattern
allows them to all be the same build, just installed in different locations
with (possibly) different feature (or even component) sets.
-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Tuesday, November 17, 2009 2:58 AM
To: Blair; General discussion for Windows Installer XML toolset.
Subject: AW: [WiX-users] New Entry in Add/Remove Program when upgrade
Hi Blair,
I found an article from MSDN, which is talking about multiple instance. I
think my requirement is similiar like multiple instance, although the
software version could be different.
The link is here
http://msdn.microsoft.com/en-us/library/aa369528(VS.85).aspx
It says:
The easiest way to initiate a maintenance installation, and reinstall an
instance, is to reference the product code of the instance. If you initiate
the maintenance installation by using the package path, you must also
specify the product code of the instance. From the command line, use the /n
{Product Code} option. From code or script, use the MSIINSTANCEGUID
property.
And example:
The following example reinstalls an instance without re-caching the package.
The instance is referred to by its product code
{0001-0002---624474736554}.
msiexec /I {0001-0002---624474736554} REINSTALL=ALL
REINSTALLMODE=omus /qb
Does it mean that retrieving the installed ProductID, then using command
line to pass it the install package. Does it meet my requirement that update
the user selected installed software by minor upgrade, but does not know the
ProductID ahead?
Regards,
Chunyan
-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com]
Gesendet: Freitag, 13. November 2009 18:24
An: Jiang, Chunyan (GE Healthcare); 'General discussion for Windows
Installer XML toolset.'
Betreff: RE: [WiX-users] New Entry in Add/Remove Program when upgrade
As far as I know, no, it does not work.
-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Friday, November 13, 2009 2:46 AM
To: General discussion for Windows Installer XML toolset.
Cc: os...@live.com
Subject: AW: [WiX-users] New Entry in Add/Remove Program when upgrade
Hi Blair,
I am sorry to confuse you on this issue. I think my requirement has been
changed. I want to install multiple versions to different paths
simultaneously. At the same time, there is requirement to update the
specific installation. It must be minor upgrade, because there are some
files should not be removed.
So I think it is better to use two MSI to fulfill the task. And use
bootstraper.exe to decide new install or upgrade. It makes things easy.
However, I have a question for the minor upgrade MSI. Since there are
mutliple versions installed, and user chooses which one to upgrade, the
minor upgrade MSI doesn't know the Product ID. If I set a new Product ID to
this minor upgrade MSI, is it possible to set it to another Product ID to
this minor upgrade MSI when the installed version is selected by user?
Does it work? value
=::MsiSetPropertyW(hInstaller,LProductID,PreviousProduct);
Best regards,
Chunyan
-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com]
Gesendet: Donnerstag, 12. November 2009 18:26
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] New Entry in Add/Remove Program when upgrade
Only when you drop your requirement to install multiple versions to
different paths simultaneously.
-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Thursday, November 12, 2009 2:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] New Entry in Add/Remove Program when upgrade
Hi,
Since my requirement is special, which includes both new install and update,
I would like to design my package as this:
* One MSI(installation package) to do the new install
* One MSP (patchwork) to do the update
* One MSM (merge module) to contain the common part of new install and
update
Both MSI and MSP refer to MSM for the common part. And there is no duplicate
files in the whole installation CD.
The Bootstraper.exe has UI and decides when to do new install (call MSI),
when to do update (call MSP).
Do you think it is a possible solution for my issue?
Regards,
Chunyan
-Ursprüngliche Nachricht-
Von: Jiang, Chunyan (GE Healthcare)
Gesendet: Donnerstag, 12. November 2009 10:06
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] New Entry in Add/Remove Program when upgrade
Hi Blair,
Thanks a lot for your suggestion.
Here I would like to summarize the workflow:
Bootstraper.exe should do the following
Re: [WiX-users] to get last upgrade information
(wix-user-request is used for adding/removing yourself from the mail list. It isn't used for sending messages to the list itself). Open your MSI in Orca, apply your last patch to it (in Orca), read from your Property table. -Original Message- From: BSR PHANI [mailto:bsrphani...@gmail.com] Sent: Tuesday, November 17, 2009 4:04 AM To: wix-users-requ...@lists.sourceforge.net; wix-users@lists.sourceforge.net Subject: [WiX-users] to get last upgrade information hi all, i've a product and i'm delivering the minor upgrades(patches), i've a requirement like i need last upgrade(patch) information to use that info in the current upgrade(patch). can any one help me on how to get the last upgrade(patch) information like product version? please help me. Thanks, Phani -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] While installation, Restrict the error message without 'Ignore' button and stop then rollback the installation
fail to register. Could you please elaborate? How are you registering, and what exactly is the error message that the user is able to ignore? -Original Message- From: Selvakumar B [mailto:selvakuma...@realimage.com] Sent: Tuesday, November 17, 2009 5:04 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] While installation, Restrict the error message without 'Ignore' button and stop then rollback the installation Hi Kalev, I already set that element Vital=Yes, Still I get the message with ignore, ok and cancel buttons. If I click ignore installer ignore the filter without register. What I want is when error occurs I need to restrict buttons like ok only button. Is it possible? Thanks Selva -Original Message- From: Kalev Lember [mailto:ka...@smartlink.ee] Sent: Monday, November 16, 2009 6:24 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] While installation, Restrict the error message without 'Ignore' button and stop then rollback the installation On 11/16/2009 12:31 PM, Selvakumar B wrote: I don't want to allow the installation to proceed, if any of the filters fail to register. Users just click ignore and proceed with the installation only to find out that they have a broken installation. Can we restrict the error message without 'Ignore' button and stop then rollback the installation. Hi, File element's Vital=yes property should do exactly what you want. Try something like this: Component Id=filter.dll Guid=* File Source=filter.dll Vital=yes / /Component -- Kalev -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users The contents of this email and any attachment(s) are confidential and intended for the named recipient(s) only. This email shall not attach any liability on the originator or Real Image Media Technologies Pvt. Ltd. or its affiliates. Any views or opinions expressed in this email are solely those of the author and may not necessarily reflect the views or opinions of Real Image Media Technologies Pvt. Ltd. nor its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this email, without the prior written consent of the author, is strictly prohibited. If you have received this email in error, please delete it and notify the sender immediately. Before opening any mail and attachments, please check them for viruses and defects -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Help with building patch
There were schema changes between 2.0 and 3.0 which would make the authoring look a little different, and tool changes which affect the way we get to our output files. For WiX, PCP is just another Windows Installer file format. For Windows SDK, it is a driver file for msimsp/patchwiz. The other inputs didn't change, they just were explained differently (happens when others complained they didn't understand the 2.0 docs). PatchWiz.dll does the file comparisons when using that method of patching. Pyro does the file comparisons when using the pure-WiX method. -Original Message- From: Schmitz, John [mailto:jschm...@mediacy.com] Sent: Monday, November 16, 2009 9:04 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Help with building patch Pally, Thanks for clarifying. This example in the 3.0 documentation is so completely unlike the documentation for 2.0 that I assumed that they were entirely different processes! I don't know from this documentation what the sample.txt files have to do with anything - I want to compare two ADMIN installs, one of the original 1.0 product release (the Target in MS terminology), and one of the new 1.0.1 release. The 2.0 process does that, but this does not use any reference to uncompressed folders of the two installs. And there's no reference to any MSI files at all. I've probably caused enough uproar, or I would enter a MAJOR bug on the 3.0 documentation, because even though the 2.0 documentation has a major error in it (mislabeling the WSX source file you must hand-create as a PCP file), this 3.0 documentation does not in any way help me to understand how to do this. Maybe that's just me! :-) BR, John From: Pally Sandher [pally.sand...@iesve.com] Sent: Monday, November 16, 2009 11:55 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Help with building patch I think you misunderstand me. Look at the v2.0 guide for making patches then look at the *equivalent* v3.0 guide (as in the one I linked on my first reply to this thread which deals with using PCP files). You will see there are some differences. The differences are small but they exist. I use the PCP method for creating patches using WiX v3.0 previously used it for WiX v2.0 too, I tried using the pyro.exe method in WiX v3.0 but decided to stick with the PCP method as it is what I'm comfortable with. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Schmitz, John [mailto:jschm...@mediacy.com] Sent: 16 November 2009 16:33 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Help with building patch The way I understand a previous comment from Blair, there was no intention to deprecate the 2.0 approach to patches. Unless I am misunderstanding something, the 2.0 approach is much, much more useful for an automated build than the 3.0 approach. From: Pally Sandher [pally.sand...@iesve.com] Sent: Monday, November 16, 2009 10:52 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Help with building patch Rob he's trying to use v2.0 how-to guide with the v3.5 toolset. I'd wait for someone else to verify this is an actual bug as it works completely fine in v3.0. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 16 November 2009 15:32 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Help with building patch Yes, please open a bug on v3.5. That is under development and bugs help us quickly find what was recently broken. On Mon, Nov 16, 2009 at 7:12 AM, Schmitz, John jschm...@mediacy.com wrote: I installed and switched to using WIX 2.0 (stable). This clarified two things: 1) SOME of the changes that I specify in my bug are indeed only needed to adapt the WSX file to version 3.5. The original code in the page works with 2.0 IF you know to save it as a WSX file and use it as the source for the compilation. 2) 3.5 does NOT work and 2.0 DOES work. Should I enter a bug on 3.5? Thanks, John From: Schmitz, John Sent: Sunday, November 15, 2009 8:36 AM To:
Re: [WiX-users] Help with building patch
We had a build process that ran from a service account in a build lab of
over a thousand machines. We discovered that msimsp.exe/patchwiz.dll will
sometimes pop up a dialog box if we didn't do a good enough job catching all
the possible error conditions and stall waiting for its OK button to be
pressed, which was an absolute disaster in our build environment.
Pyro/torch/et al proved to be a savior for us to be able to build MSPs as a
routine development activity instead of only 3-4 times per public release at
the most.
Further, if you suppress ICE validation (since ICE validation requires
either an interactive login or administrative privileges) you can use wixpdb
files and build MSP files without having to grant your build process any
admin privilege (makes network admins happier). You can't do that with admin
installs that will eventually require administrator's privs to install.
-Original Message-
From: Schmitz, John [mailto:jschm...@mediacy.com]
Sent: Monday, November 16, 2009 8:33 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Help with building patch
The way I understand a previous comment from Blair, there was no intention
to deprecate the 2.0 approach to patches. Unless I am misunderstanding
something, the 2.0 approach is much, much more useful for an automated build
than the 3.0 approach.
From: Pally Sandher [pally.sand...@iesve.com]
Sent: Monday, November 16, 2009 10:52 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Help with building patch
Rob he's trying to use v2.0 how-to guide with the v3.5 toolset. I'd wait
for someone else to verify this is an actual bug as it works completely
fine in v3.0.
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 16 November 2009 15:32
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Help with building patch
Yes, please open a bug on v3.5. That is under development and bugs help
us quickly find what was recently broken.
On Mon, Nov 16, 2009 at 7:12 AM, Schmitz, John jschm...@mediacy.com
wrote:
I installed and switched to using WIX 2.0 (stable). This clarified two
things:
1) SOME of the changes that I specify in my bug are indeed only needed
to adapt the WSX file to version 3.5. The original code in the page
works with 2.0 IF you know to save it as a WSX file and use it as the
source for the compilation.
2) 3.5 does NOT work and 2.0 DOES work. Should I enter a bug on 3.5?
Thanks,
John
From: Schmitz, John
Sent: Sunday, November 15, 2009 8:36 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Help with building patch
I'm using 3.5.
Message Sent with NotifySync
-Original Message-
From: os...@live.com
Sent: Sat, 14 Nov 2009 19:33:06 America/New_York
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Help with building patch
Version 3.0 supports both the version 2 method (msimsp.exe/PatchWiz)
and the pure WiX method (torch/pyro). Version 3.5 retains that
support.
Each of those two methods in the version 3 docs are described on two
different pages.
Not sure on the error message (although I haven't looked at the code
yet).
The TargetImages probably refers to the table itself, but with a path
to the MSI file itself in the error message as being the missing
symbol seems like something isn't quite right. Which version/build of
the toolset are you actually using?
-Original Message-
From: Schmitz, John [mailto:jschm...@mediacy.com]
Sent: Saturday, November 14, 2009 1:20 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Help with building patch
Hi,
I have worked my way through understanding most of the things left out
of or incorrect in the Patch Building page of Authoring (at
http://wix.sourceforge.net/manual-wix2/patch_building.htm). (I've
entered a bug on the page with what I've found along the way.)
I just noticed that this is a version 2 page, and the version 3 page
takes a totally different and (for me useless) approach. So I don't
actually know if what I'm trying to do is possible in 3.5 or not.
I'm down to just one error, which only cropped up after modifying the
WSX code to use the TargetImage attribute of the PatchSequence. Here's
the
error:
Patch.wsx(39) : error LGHT0094 : Unresolved reference to symbol
'TargetImages:full path to my target MSI file'' in section
'PatchCreation:{C42BF9ED-EDDA-46C0-97E3-BE0EC2D0750E}'.
I've doubled checked the
Re: [WiX-users] How to use MsiGetProductInfo function?
Hi,
The problem has been resolved. It is because of the setting. I set it again as:
setting Project, Properties, General, Character set. Select unicode (wchar_t)
or MBCS (char)
Now including atlstr.h has no error. So I can use CStrBufW for setting string.
Regards,
Chunyan
-Ursprüngliche Nachricht-
Von: Jiang, Chunyan (GE Healthcare)
Gesendet: Freitag, 20. November 2009 08:52
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to use MsiGetProductInfo function?
Hi Peter,
Sorry, I didn't post all the code here. Actually, my code is:
TCHAR szProductName[100] = {0};
DWORD length(0);
uiStatus =
MsiGetProductInfoW(szProductCode,LInstalledProductName,L,length);
if(uiStatus == ERROR_MORE_DATA)
{
// TCHAR name[length+1];
uiStatus =
MsiGetProductInfoW(szProductCode,LInstalledProductName,szProductName,length);
}
Here uiStatus is always ERROR_MORE_DATA.
If I set DWORD length(50); It will break and have access violation error.
I want the way that Blair told me before, like:
uiStatus =
MsiGetProductInfoW(szProductCode,LInstalledProductName,L,length);
if(uiStatus == ERROR_MORE_DATA)
{
length += 1; // We have to tell MsiGetProperty that the buffer has
space for the null terminator.
uiStatus =
MsiGetProductInfoW(szProductCode,LInstalledProductName,CStrBufW(szProductName,
length, CStrBufW::SET_LENGTH),length);
}
However, it must include header
#include atlstr.h
In my case, include atlstr.h will cause many errors, like:
1D:\Program Files\Microsoft Visual Studio
8\VC\atlmfc\include\atlchecked.h(93) : error C2664: 'errno_t strcpy_s(char
*,rsize_t,const char *)' : cannot convert parameter 1 from 'TCHAR *' to 'char *'
1 Types pointed to are unrelated; conversion requires reinterpret_cast,
C-style cast or function-style cast
Therefore, I don't know how to deal with this problem.
Could you please give me some hint?
Regards,
Chunyan
-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Gesendet: Donnerstag, 19. November 2009 17:35
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to use MsiGetProductInfo function?
You are passing 0 as the size of the buffer in the length argument which is
too small.
Try
DWORD length = sizeof(szProductName)/sizeof(TCHAR);
-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: 19 November 2009 16:12
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How to use MsiGetProductInfo function?
Hi,
I tried to retrieve some information about installed Product, as bellow:
TCHAR szProductName[100] = {0};
DWORD length(0);
MsiGetProductInfoW(szProductCode,LInstalledProductName,szProductName,
length);
However, it always return ERROR_MORE_DATA. It sounds like that TCHAR
szProductName[100] is not enough. Actually, length is only 42 in my case. I
would like to use
CStrBufW(szProductName, length, CStrBufW::SET_LENGTH)
instead of TCHAR. However, #include atlstr.h causes many errors, like:
1D:\Program Files\Microsoft Visual Studio
8\VC\atlmfc\include\atlchecked.h(93) : error C2664: 'errno_t strcpy_s(char
*,rsize_t,const char *)' : cannot convert parameter 1 from 'TCHAR *' to 'char *'
1 Types pointed to are unrelated; conversion requires reinterpret_cast,
C-style cast or function-style cast
Is there anyway to use MsiGetProductInfo function?
Regards,
Chunyan
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with Crystal
Reports now. http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires
that you delete it without acting upon or copying any of its contents, and we
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY,
UK.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with Crystal
Reports now. http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to force to launch application in silent install mode?
If your MSI was installed via group policy, and you succeeded in launching your application, it is possible that no user would ever see it to know that it needed upgrading. You could try adding a custom action in your MSI that runs your upgrade-check and if there is a newer version you fail the installation with a message that there is a newer version. Or, you wait around (after quiet installations) until the user finally decides that they are going to use your application and then find out that there is a newer version. Of course, if they run an interactive installation, you could simply remove the checkbox, leave the property, and always launch then (since you know that there is a real user there) and alert the user to your upgrade when the product launches. -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Thursday, November 19, 2009 11:33 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to force to launch application in silent install mode? Thanks Sascha. Rebooting doesn't fit our requirement. I've made a workaround in our bootstrapper to launch the app after silent installation. It's not nice as our MSI users won't have this functionality. But this seems the best we could do so far. From: Sascha Beaumont sascha.beaum...@gmail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wednesday, November 18, 2009 4:10:56 PM Subject: Re: [WiX-users] How to force to launch application in silent install mode? Best solution I've used in the past was to schedule a reboot, it really depends on your app and your deployment requirements as to what will work for you. On Thu, Nov 19, 2009 at 10:13 AM, little.forest little.for...@ymail.com wrote: Thanks Sascha. I see your points. It looks like there is no any other workarounds, correct? From: Sascha Beaumont sascha.beaum...@gmail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wednesday, November 18, 2009 2:35:26 PM Subject: Re: [WiX-users] How to force to launch application in silent install mode? Hi, With regards to the quicklaunch shortcut, the checkbox is just setting a property, no different to setting the property on the command line. The property is set when InstallExecuteSequence runs, and you most likely have a condition on your quicklaunch component that checks the property. With regards to launching the application, you're tying the launch to the Finish button in the InstallUiSequence rather than to something that happens during InstallExecuteSequence. The following page might help explain the sequence: http://blogs.msdn.com/rflaming/archive/2006/09/21/765452.aspx Sascha On Thu, Nov 19, 2009 at 6:00 AM, little.forest little.for...@ymail.com wrote: Thanks Sascha. It's good to know that the InstallUISequence is never executed in quite mode. But in another case, I set a property in command line argument, it seems working. I mean, we have a checkbox called Install Quick Launch shortcut. By default it's off. So the quick launch shortcut isn't created by default. In command line, I added this 'INSTALLQUICKLAUNCHSHORTCUT=1' in command line, then in quite installation, the quick launch shortcut was created. So it seems working. I wonder why the similar case for Launch application on the final page would be different? I thought it's supposed to work the same way as the quick launch shortcut, right? Let me know if you know the reason. By the way, the reason we need to launch the application in quite installation is because these: we have an auto-update mechanism. The idea is, the application will periodically check if there is any new build available in our provisioning server. If there is any new version, then ask the end user if she wants to download it and install it. If the end user says yes, then we'll download it and install it. After installation of the new version, we'd like to automatically launch the application, because the previous status of the application was in running state. This is just like when you update your browser like Firefox or Chrome. I think it's okay if the application isn't launched by default in quite mode. But by setting some kind of property, the application will be launched in quite mode. This will satisfy both the network admin scenario as what you mentioned, and our case. Anyways, since it's not supported, I'll think about if I can schedule this launching action in our bootstrapper - we have a bootstrapper for the installer. Thanks again. From: Sascha Beaumont sascha.beaum...@gmail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tuesday, November 17, 2009 8:06:13 PM Subject: Re: [WiX-users] How to force to launch application in silent install
Re: [WiX-users] Launch Condition on Unistall or Remove
Always add OR Installed to all of your LaunchConditions. If the product is already installed, you want to allow repairs and removals, including upgrades. -Original Message- From: spsingam [mailto:siva.poobalasin...@gmail.com] Sent: Tuesday, November 17, 2009 8:13 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Launch Condition on Unistall or Remove hi, how do i make sure that the Launch Condition only executes only on Installed ??? for now, my installer executes the Launch Condition on uninstall. Anyone here with suggestions ? -- View this message in context: http://n2.nabble.com/Launch-Condition-on-Unistall-or-Remove-tp4023317p402331 7.html Sent from the wix-users mailing list archive at Nabble.com. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how to prevent uninstalling MSI using msiexec with Guid
My understanding is that patching always has REINSTALL set. Try msiexec
/update mypatch.msp /l*vx patch.log and examine the properties to see what
is and isn't set when you attempt to apply your patch.
Also I ask, you will never support a major upgrade? I wish I had that kind
of confidence in the future.
Oh, and remind me to ask you what your product is so I can avoid ever
installing it on anything I ever control.
-Original Message-
From: Lian Jiang [mailto:lji...@microsoft.com]
Sent: Wednesday, November 18, 2009 2:42 PM
To: General discussion for Windows Installer XML toolset.
Cc: r...@snsys.com
Subject: Re: [WiX-users] how to prevent uninstalling MSI using msiexec with
Guid
Hi Rob,
Please believe we have right reason to block uninstalling.
With this launch condition I can repare using msiexec /f my.msi but cannot
patch using msiexec /update mypatch.msp.
Condition Message=Uninstall is not supportedREINSTALL or Not
Installed/Condition
Is there a way to block uninstalling while still enable patching?
Appreciate your help.
Thanks
Lian
-Original Message-
From: Rob Hamflett [mailto:r...@snsys.com]
Sent: Tuesday, November 17, 2009 12:09 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] how to prevent uninstalling MSI using msiexec with
Guid
Why are you preventing people from uninstalling your product? You're never
going to be able to
upgrade your installation or repair it.
Rob
Lian Jiang wrote:
This one worked for me:
Condition Message=Uninstall is not supportedREINSTALL or Not
Installed/Condition
Thanks
Lian
-Original Message-
From: Lian Jiang [mailto:lji...@microsoft.com]
Sent: Monday, November 16, 2009 11:59 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] how to prevent uninstalling MSI using msiexec with
Guid
Hi,
If necessary, is it possible to prevent users from uninstalling an
installed MSI by using guid in command line (e.g. msiexec /x {Guid})?
Appreciate any advice.
Thanks
Lian
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to create main and sub installer?
Say hello to MSI 4.x and embedded chainers. -Original Message- From: akihiro.shib...@jp.yokogawa.com [mailto:akihiro.shib...@jp.yokogawa.com] Sent: Tuesday, November 17, 2009 5:29 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to create main and sub installer? Hi, All, A: main installer B: sub installer 1. A is installed. 2. When A is installed, B is copied onto a local disk together. 3. B install if necessary. 4. When A is uninstalled, B is automatically uninstalled. Is it possible though I wants to make two installers of such a composition with WiX ? Thanks, Akihiro -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] ProductLanguage property not included in transformation (created using Torch.exe)
Hi all I have problem that is described on: http://sourceforge.net/tracker/?func=detailatid=642714aid=2887011group_id=105970 In short: Language transformation created using command: torch.exe -t language Package_EN.msi Package_DE.msi -out 1031.mst does not contain the ProductLanguage property. I have received following answer: you need to add the PropertyRef to the PatchFamily element for a patch to include it in the patch. PatchFamily is a filter (and defines a patch family for the resulting MSP). The answer results in another question: I do not want to create the MSP file. I want to create the MST transformation that will (after applying to MSI) change the ProductLanguage property (and all the texts). Is it possible using torch.exe? Thanks Stefan -- Stefan Pavlik | stefan.pav...@gmail.com Lietavska 14 | 851 06 Bratislava | Slovak Republic -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How do I configure ALL WIX temp files' locations?
I haven't looked into the code yet, but would TEMP (or even TMP) move the remaining locations? -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Thursday, November 19, 2009 8:22 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How do I configure ALL WIX temp files' locations? Hmm, bummer. Thanks for finding and reporting this issue. 2009/11/18 Matti Hägerlund matti.hagerl...@gmail.com Hi Rob and thanks for the tip. I tried the -cc switch but light still writes the temp-file in C:\Documents and Settings\user\Local Settings\Temp :-( I'll file a bug report. /M4tti 2009/11/18 Rob Mensching r...@robmensching.com: Hmm, I would have thought %WIX_TEMP% would move everything. Please do file a bug. In the meantime, I think the cab cache switch (light.exe -cc path) will move the cabinet building for you. 2009/11/18 Matti Hägerlund matti.hagerl...@gmail.com Hi all. When using WIX to create large MSI's, it would be convenient to redirect the storing of temp files created by WIX to some other storage media. As I understand, this is done by setting WIX_TEMP environment variable. And yes, it does redirect some of the temp files, but not ALL. Some still end up in C:\Documents and Settings\user\Local Settings\Temp. What light does: 1) Create directory called something like xvnt3tm8. This directory contains a directory called cab_0_WixUIExtension and a file called cab_0_WixUIExtension.cab. The location of this dierctory can be configured with WIX_TEMP. 2) Create temp file(s), called something like 0003.1188 in C:\Documents and Settings\user\Local Settings\Temp. These files are the CAB files, I think, so they can be up to 2 GB each. 3) Copy temp files (e.g. 0003.1188) from C:\Documents and Settings\user\Local Settings\Temp to xvnt3tm8. 4) Remove 0003.1188 from C:\Documents and Settings\user\Local Settings\Temp Here is the question: How do I configure WIX NOT to store the temp file 0003.1188 in C:\Documents and Settings\user\Local Settings\Temp? I would like to store it elsewhere, as there is more space on other disks. To summarize: I know, that I can use envoronment variable WIX_TEMP, to set where some temp files end up. The problem is the CAB-temp-files. /M4tti -- __o__o__o _`\,_ _`\,_ _`\,_ (_)/ (_) (_)/ (_) (_)/ (_) -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- __o__o__o _`\,_ _`\,_ _`\,_ (_)/ (_) (_)/ (_) (_)/ (_) -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free
Re: [WiX-users] Supplemental shell extensions installation
Aaron's blog will help you with building your two MSIs (32- 64-bit) using the exact same sources. On a 64-bit OS, explorer.exe will be a 64-bit app, so you won't need the 32-bit mirrored installation. However, if you feel you really need them, you could use the ?foreach? preprocessor command and duplicate the components. As I understand your issue regarding the shell-extension registration, it is that you don't know what file types/extensions you support until such time as you are installing, correct? Or do you just need to only install into those filetypes you do support if they already existed in the system? Could you please clarify? Once we know what your intended process is (as Chad seems to be saying), we can then coach with ideas, with both how-to-implement as well as this-other-might-be-better styles of responses. -Original Message- From: Jan Wester [mailto:happyhon...@gmail.com] Sent: Thursday, November 19, 2009 1:04 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Supplemental shell extensions installation On Thu, Nov 19, 2009 at 9:25 PM, Michael Clark mcl...@fullarmor.com wrote: a) Objectively, is WiX the right option, or should I look at other installers for this purpose? [Michael] It's a great tool for this purpose and its free! b) Are there any samples of scripts that install shell extensions? I have looked around, but found nothing. Reinventing the wheel is something I will probably be pretty crappy at. [Michael] I think this is what your looking for http://stackoverflow.com/questions/138550/how-to-register-file-types-ext ensions-with-a-wix-installer c) Likewise, are there any samples dealing with such specific requirements for as far the platform goes? Again, my wheel would likely not be all that round. [Michael] Checkout this link for 32/64 bit installs http://blogs.msdn.com/astebner/archive/2007/08/09/4317654.aspx -Michael 2243 Michael, The file extension stuff seems wrong for me. I don't have an application to hang on the Open verb, or whatever other choice. I just have shell extensions that need to play ball with any existing settings of the computer without disrupting anything else. So far, I have thumbnail and property handlers for my first file format, but a preview is on my plans. Basically, think of stuff that spruces stuff up in Explorer. I had seen that link on 32-bit and 64-bit installations. It is somewhat old though, and I had read older versions of WiX were different in some ways, so I figured there might be actual samples out there demonstrating the kind of thing I am looking for. (Something to be put besides an article like the one you linked - such articles are a great resource, but for a wix beginner like me, nearly everything implies a lot of searching and studying where a simple example document would clarify more in a simpler glance.) Jan Wester -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What does Foreign mean here in log?
Which version/build of Windows Installer? Much of what ends up in Windows Installer logs is itself undocumented and sometimes doesn't seem to continue in the next released build of MSI. As to folders not being removed: folders won't ever be removed if any files (that the MSI doesn't own) are left behind. Empty folders can sometimes be left behind in some circumstances. Many of those can be dealt with by adding RemoveFolder/ elements to your authoring. -Original Message- From: william lee [mailto:wele...@gmail.com] Sent: Monday, November 16, 2009 4:31 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] What does Foreign mean here in log? Hi, When I uninstall a product, the folders are not removed. I checked the log, and found following info: MSI (s) (E4:60) [23:48:41:812]: Executing op: FolderRemove(Folder=C:\ProgramData\Microsoft\Windows\Start Menu\Programs\MyCompany\Prod3\,Foreign=0) MSI (s) (34:80) [04:03:38:633]: Executing op: FolderRemove(Folder=C:\ProgramData\Microsoft\Windows\Start Menu\Programs\ MyCompany\Tools\,Foreign=1) Sometime it's 1, sometime it's 0. What does the Foreign mean here? :) Thanks William L. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patching: weird numbers for Media.DiskId and File.Sequence
Hello WiX Community, I have been analyzing the log file of my patch installation, and faced with a weird numbers I don't know the origin of. Here's the snippet: ... TRANSFORM: The minimum 'Media.DiskId' value inserted by a patch transform is 100 TRANSFORM: The maximum 'Media.DiskId' value inserted by a patch transform is 99 TRANSFORM: The minimum 'File.Sequence' or 'Patch.Sequence' value inserted by a patch transform is 1 TRANSFORM: The maximum 'File.Sequence' or 'Patch.Sequence' value inserted by a patch transform is . ... Googling this stuff proved that it is not only specific to my installation, but can be seen in many others. My question is where those numbers come from??? The Media/@Id value of my patch is 200. When I apply the patch manually in Orca, I can see another row being correctly added to the Media table with 200 in DiskId column. But when I query that table from my immediate custom action like this SELECT DISTINCT `PatchPackage`.`PatchId`, `Media`.`LastSequence` FROM `PatchPackage`, `Media` WHERE `PatchPackage`.`Media_` = `Media`.`DiskId` ORDER BY `LastSequence` (according to Heath Stewart blog entry) it returns 10001 as last sequence. I assume this is somehow related to the strange numbers above. Can anyone suggest where to look for the explanation? Please, help... Thank you, -- Yan -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Supplemental shell extensions installation
I was looking at sharing file extension registrations between
applications only yesterday. This page and its related content were most
useful
http://msdn.microsoft.com/en-us/library/bb166183(VS.80).aspx
-Original Message-
From: Happy Hondje [mailto:happyhon...@gmail.com]
Sent: 19 November 2009 20:08
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Supplemental shell extensions installation
Hello WiXers,
I am new to Windows Installer and WiX, and thus have been pouring over
documentation. tutorials, samples and google the last few days. I see a
lot of basic information which is nice, but sadly, my needs aren't all
that typical. (This might become a rather long posting, so I will
apologize in advance for that.)
The reason is that my 'application' is fully compromised out of shell
extensions, the purpose being to give a more seamless experience in
using the applicable documents in every day use. (I have one
production-ready at this point, so I figured I'd look into getting a
basic installer ready that meets my requirements.) I foresee the
following big problems:
1. Architecture. Basically, there are two (or technically three)
possible scenario's:
* 32-bit shell extension on 32-bit platform.
* 64-bit shell extension on 64-bit platform. For maximum compatibility,
I would want the 32-bit shell extension installed as well.
From what I understand based on some older posts on this mailing list,
WI/WiX sincerely dislikes mixed-architecture installations. Sadly, this
is a matter that can't be avoided. Paths, registry, they're both things
to be careful of. And ideally, there would be a single .msi and no
chance for user-error.
2. File extension ownership is an issue. Whereas dedicated applications
can simply take ownership of a file-extension, define their own
progid's, verbs and all that magic. This would be a supplemental package
that has no external dependancies, so the extensions it registers to may
be registered to ProductA, ProductB or even nothing at all. This means
the -target- ProgID for these registrations is flexible, falling down to
a default where nothing was hooked up just yet. And in the case
overwriting something IS unavoidable, it would be nice to be able to
restore these values upon uninstallation.
3. Making points 1 and 2 meet eye-to-eye, which would probably be the
most difficult.
For as far solutions go, let me first explain how I imagine the setup.
The entire application configuration experience would be done from a
feature tree in the setup. Think of something along the lines of:
[ ] .XYZ support.
[x] .DEF support.
[x] .DEF2 support.
Afterwards, the Change feature in the Installed Programs list could be
used to change or repair these shell extensions.
I was thinking of solving one of the architecture problems using the
bootstrapper burn. (I might be getting that one wrong, the fire-related
names are all one big blur after all this reading...) It could activate
the proper MSI for the proper platform.
The 32-bit support for 64-bit platforms is tricky. I thought about
having it optional, but I decided my users would only be confused if I
offered them a bitness option, so I want to have it turned on by
default. I recall reading somewhere that it is possible to do hidden
installs of other .msi packages, having no entries pop up in Installed
Programs etc. Assuming I understood that right, and assuming I can
somehow feed the 'installed features' from the 64-bit .msi to the 32-bit
.msi, I could avoid having two entries pop up in the Installed Programs
applet ('MyApp 32-bit', 'MyApp 64-bit').
At this point, it is kind of obvious to me that I will probably not want
to make the installable directory configurable, but have the setup copy
to 'C:\Program Files\MyApp' and 'C:\Program Files (x86)\MyApp' as
appropriate. If I did not and would let the user pick a location, they
might very will pick one of those places only to have half of the
functionality disappear on them depending on whether my shell extensions
were to be utilized from the native Explorer or a 32-bit application
using an Open File dialog.
The file extension ownership issues, and how to deal with different
ProgID's, are mysteries to me. I could probably figure out how to
install to a fixed ProgID with no regard of the users current installed
affairs, but that is not what I want. The concept of installing
extensions for files you don't actually own seems to be like a rare
occurrance. Who'd have guessed! :)
If anyone read this far, I commend you.
Now my questions are as follows, maybe not too specific, but still:
a) Objectively, is WiX the right option, or should I look at other
installers for this purpose?
b) Are there any samples of scripts that install shell extensions? I
have looked around, but found nothing. Reinventing the wheel is
something I will probably be pretty crappy at.
c) Likewise, are there any samples dealing with such specific
requirements for as far the platform goes? Again, my
Re: [WiX-users] Errors using performance counters after installing with PerformanceCounter/PerformanceCounterCategory
The wxs effectively does what is described on the following page: http://msdn.microsoft.com/library/aa371878.aspx, which produces a registration in the system registry of the performance counter. A quick search for me didn't reveal what the implementation of the PerformanceCounterInstaller class does. I must admit that while I have written and read performance counters, it was all pre-.Net, so I don't know the interop (except that there apparently is one). Maybe you could as in some .net forum what relationship there is between the PerformaceCounterInstaller and the MSDN page I found, and how to interoperate those together. -Original Message- From: Rich Daniel [mailto:rdan...@microsoft.com] Sent: Thursday, November 19, 2009 9:51 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Errors using performance counters after installing with PerformanceCounter/PerformanceCounterCategory I'll give you the wix, the installer code, and the usage all side by side: .wxs fragment: Component Id=MyApp Guid=---- KeyPath=yes File Name=$(var.MyApp.TargetFileName) Source=$(var.MyApp.TargetPath) DiskId=1 / File Name=$(var.MyApp.TargetName).pdb Source=$(var.MyApp.TargetDir)$(var.MyApp.TargetName).pdb DiskId=1 / util:PerformanceCategory Id=MyAppCategory Name=My Application Help=Custom performance counters for my application. MultiInstance=yes util:PerformanceCounter Name=My First Counter Help=The first custom counter for my application. Type=numberOfItems64 / /util:PerformanceCategory /Component .cs fragment (installer): PerformanceCounterInstaller category = new PerformanceCounterInstaller(); category.CategoryName = My Application; category.CategoryHelp = Custom performance counters for my application.; category.CategoryType = PerformanceCounterCategoryType.MultiInstance; CounterCreationData counter = new CounterCreationData(); counter.CounterName = My First Counter; counter.CounterHelp = The first custom counter for my application.; counter.CounterType = PerformanceCounterType.NumberOfItems64; counterInstaller.Counters.Add(counter); .cs fragment (usage): PerformanceCounter counter = new PerformanceCounter(); counter.CategoryName = MyApp.CounterCategoryName; counter.CounterName = MyApp.FirstCounterName; counter.InstanceName = newInstanceName; counter.InstanceLifetime = PerformanceCounterInstanceLifetime.Process; counter.ReadOnly = false; counter.Increment(); // This throws InvalidOperationException -Original Message- From: Sebastian Brand (Instyler Software) [mailto:wix+us...@instyler.com] Sent: Wednesday, November 18, 2009 9:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Errors using performance counters after installing with PerformanceCounter/PerformanceCounterCategory Can you give us the corresponding .wxs code? Best regards, Sebastian Brand Deployment consultant E-Mail: sebast...@instyler.com Instyler Setup - Creating WiX-based MSI installations, elegantly. http://www.instyler.com On 18.11.2009, at 21:13, Rich Daniel wrote: I'm in the process of migrating my app installation to wix. It's a .NET 2.0 app that currently uses installutil to add some custom performance counters and event log sources. Seeing as how I noticed that WixUtilExtension.dll supplies this functionality from the installer, I thought I'd give it a try instead. I'm rubbing up against an issue, however. The installation completes just fine, but the moment my app attempts to modify a counter, it goes bang with the following exception: System.InvalidOperationException: PerformanceCounterInstanceLifetime.Process is not valid in the global shared memory. If your performance counter category was created with an older version of the Framework, it uses the global shared memory. Either use PerformanceCounterInstanceLifetime.Global, or if applications running on older versions of the Framework do not need to write to your category, delete and recreate it. If I believe that error, the way I've defined the counters in my wxs file installs them in the global shared memory (or uses the .NET 1.* approach to install them). Is there a way to tell it to do things the new way instead of the old or should I give up for now and just have some custom actions call installutil once the bits land on the box? Thanks - Rich Daniel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Supplemental shell extensions installation
On Thu, Nov 19, 2009 at 11:00 PM, Chad Petersen chad.peter...@harlandfs.com wrote: Aren't shell extensions either a DLL or OCX file as the entry point? Think about what you have to do to manually deploy your shell extensions and write down the steps (if it helps). These are the steps that you would then author in WiX to automate the process through an MSI. A simple outline with things that are common 1. Confirm it is a Windows OS 2. Confirm it is one of the version(s) of Windows you support 3. Detect where Windows is installed if needed 4. Copy extension to proposed folder (your own, or perhaps System32) 5. Register the extension with the system 6. Restart Windows if needed Hello Chad, Aye, shell extensions are all DLLs. I believe I know the requirements of my shell extensions, but I am unsure as to the best installing habits. For example, you recommend system32, but I recall reading that starting with Vista I believe it was, Microsoft is advising against installing stuff into System32. I have no real need for backwards compatibility (thankfully), so I focusing fully on Windows 7 compatibility and guidelines in this matter. But to me, this also means I should be getting it mostly right at my first try, rather than mostly wrong. :) Regards, Jan Wester -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Supplemental shell extensions installation
On Fri, Nov 20, 2009 at 10:22 AM, Blair os...@live.com wrote: Aaron's blog will help you with building your two MSIs (32- 64-bit) using the exact same sources. On a 64-bit OS, explorer.exe will be a 64-bit app, so you won't need the 32-bit mirrored installation. However, if you feel you really need them, you could use the ?foreach? preprocessor command and duplicate the components. As I understand your issue regarding the shell-extension registration, it is that you don't know what file types/extensions you support until such time as you are installing, correct? Or do you just need to only install into those filetypes you do support if they already existed in the system? Could you please clarify? Once we know what your intended process is (as Chad seems to be saying), we can then coach with ideas, with both how-to-implement as well as this-other-might-be-better styles of responses. Hello Blair, Sadly, I -do- need the 32-bit installation side-by-side. When using a 32-bit application (which is the majority of the stuff out there), it will use the 32-bit explorer components rather than the 64-bit ones. Since a good part of the focus lies with making metadata available in explorer and its components (think of having a 32-bit application going File-Open, using details view and sorting on some of this custom metadata), both 32-bit and 64-bit are necessary on 64-bit computers for a seamless experience. The support for each filetype is fully optional to allow the user to opt out. A filetype may either not be registered at all (application using it hasn't registered it) or it may be registered to a (from our point of view) random application. Suppose you have .XYZ: * If there is no traces of a .XYZ registration, we make our custommade ProgID called XYZHandler (I'm not all that original) and register the appropriate stuff there. In the end, these files would still be useless for doubleclicking and such, but that is not something I could change either way as it is beyond the scope of my installation. (Not installing anything in this case is not preferable - a surprising amount of people/programs open everything through File-Open dialogs in programs which don't register filetypes that I have noticed, so there is most definitely added value by having these registrations.) * If there is a trace of a .XYZ registration using a 'Xylophone.Zing' ProgID, we make our modifications to that ProgID, and leave everything we don't need to change alone. So stuff like open handlers, drop targets, and whatever other fancy stuff... it remains. Registering some thumbnail, property and preview handlers is all that is needed. The point is to supplement the user in his/her daily activities, not to take control of them. Either way, my apologies for another long-winded email, and thank you for your valuable insights. Regards, Jan Wester -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What does Foreign mean here in log?
Thank you Blair, I'm using Vista with 4.5. Hopefully the RemoveFile table will solve the problem. :) Thanks, William L. On Fri, Nov 20, 2009 at 5:24 PM, Blair os...@live.com wrote: Which version/build of Windows Installer? Much of what ends up in Windows Installer logs is itself undocumented and sometimes doesn't seem to continue in the next released build of MSI. As to folders not being removed: folders won't ever be removed if any files (that the MSI doesn't own) are left behind. Empty folders can sometimes be left behind in some circumstances. Many of those can be dealt with by adding RemoveFolder/ elements to your authoring. -Original Message- From: william lee [mailto:wele...@gmail.com] Sent: Monday, November 16, 2009 4:31 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] What does Foreign mean here in log? Hi, When I uninstall a product, the folders are not removed. I checked the log, and found following info: MSI (s) (E4:60) [23:48:41:812]: Executing op: FolderRemove(Folder=C:\ProgramData\Microsoft\Windows\Start Menu\Programs\MyCompany\Prod3\,Foreign=0) MSI (s) (34:80) [04:03:38:633]: Executing op: FolderRemove(Folder=C:\ProgramData\Microsoft\Windows\Start Menu\Programs\ MyCompany\Tools\,Foreign=1) Sometime it's 1, sometime it's 0. What does the Foreign mean here? :) Thanks William L. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Supplemental shell extensions installation
On Fri, Nov 20, 2009 at 10:59 AM, Peter Shirtcliffe pshirtcli...@sdl.com wrote: I was looking at sharing file extension registrations between applications only yesterday. This page and its related content were most useful http://msdn.microsoft.com/en-us/library/bb166183(VS.80).aspx That is an interesting post, but (correct me if I am wrong) it seems quite different from my situation. 1) I am supplementing with extra information, not writing a product to compete with the registration for the filetypes. 2) I have no 'open' action attached to my application and installation at all. 3) Minimum change is my goal for installation - I don't know how other applications act/deal with their file registrations. I can imagine quite a few applications will have a check for the progid and pop up a 'ProductA is no longer configured to handle .XYZ files. Do you wish to repair the file associations?' dialog... which would most likely break the few things I need in the registrations. This is one of THE reasons I want to modify existing ProgIDs rather than take ownership of the extension and copy any existing configuration in the old ProgID to my new one. Thank you for the link however, it is an interesting resource on how to deal with that facet of filetype associations. Regards, Jan Wester -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Supplemental shell extensions installation
Ah you are right. I misunderstood the part where you were talking about *other* applications sharing file type registrations. Apologies for any confusion. -Original Message- From: Jan Wester [mailto:happyhon...@gmail.com] Sent: 20 November 2009 12:03 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Supplemental shell extensions installation On Fri, Nov 20, 2009 at 10:59 AM, Peter Shirtcliffe pshirtcli...@sdl.com wrote: I was looking at sharing file extension registrations between applications only yesterday. This page and its related content were most useful http://msdn.microsoft.com/en-us/library/bb166183(VS.80).aspx That is an interesting post, but (correct me if I am wrong) it seems quite different from my situation. 1) I am supplementing with extra information, not writing a product to compete with the registration for the filetypes. 2) I have no 'open' action attached to my application and installation at all. 3) Minimum change is my goal for installation - I don't know how other applications act/deal with their file registrations. I can imagine quite a few applications will have a check for the progid and pop up a 'ProductA is no longer configured to handle .XYZ files. Do you wish to repair the file associations?' dialog... which would most likely break the few things I need in the registrations. This is one of THE reasons I want to modify existing ProgIDs rather than take ownership of the extension and copy any existing configuration in the old ProgID to my new one. Thank you for the link however, it is an interesting resource on how to deal with that facet of filetype associations. Regards, Jan Wester -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] One MSI with CAB files in different directories
I basically want a one file setup, but my content is way above 2 GByte. Thus I will have something like my_product.exe, my_product2.cab, my_product3.cab, ... The EXE contains the MSI, the my_product1.cab, and some other stuff. When executed the content of the EXE is copied to a temp directory and then the installation is launched from there. Of course now the Installer doesn't find the other CABs as they are in a different directory. The obvious, easy, but not very elegant, solution is to modify the launcher EXE to copy the CABs into the temp dir, but this has a few drawbacks, like filling the disk with another few GByte and making the user wait for the copying. I was hoping that I could get the installer to use the CABs from their original directory. I could pass the original directory as property to the MSI, but I have no idea what to do with that information. Any hints? -- View this message in context: http://n2.nabble.com/One-MSI-with-CAB-files-in-different-directories-tp4038374p4038374.html Sent from the wix-users mailing list archive at Nabble.com. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Help with building patch
Sounds interesting, but I don't understand how I would do that from the help page. It talks about two text files - are those supposed to represent the hundreds of files in my installation? Can you point me towards any sort of tutorial using pyro, etc., because as I stated earlier, I have no idea what they do. My apologies on that point, but I got WIX as part of a setup/installer building software, and their emphasis is on using their software, which effectively hides all the use of WIX under the hood. This might be exactly what I need to fix my problems, because right now, my application does not work when I install the original release and patch it to the .0.1 version with the patch, while it works perfectly if I install the full .0.1 setup that I have to build as the reference for the MSIMSP build process. Thanks, John Media Cybernetics From: Blair [os...@live.com] Sent: Friday, November 20, 2009 3:23 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Help with building patch We had a build process that ran from a service account in a build lab of over a thousand machines. We discovered that msimsp.exe/patchwiz.dll will sometimes pop up a dialog box if we didn't do a good enough job catching all the possible error conditions and stall waiting for its OK button to be pressed, which was an absolute disaster in our build environment. Pyro/torch/et al proved to be a savior for us to be able to build MSPs as a routine development activity instead of only 3-4 times per public release at the most. Further, if you suppress ICE validation (since ICE validation requires either an interactive login or administrative privileges) you can use wixpdb files and build MSP files without having to grant your build process any admin privilege (makes network admins happier). You can't do that with admin installs that will eventually require administrator's privs to install. -Original Message- From: Schmitz, John [mailto:jschm...@mediacy.com] Sent: Monday, November 16, 2009 8:33 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Help with building patch The way I understand a previous comment from Blair, there was no intention to deprecate the 2.0 approach to patches. Unless I am misunderstanding something, the 2.0 approach is much, much more useful for an automated build than the 3.0 approach. From: Pally Sandher [pally.sand...@iesve.com] Sent: Monday, November 16, 2009 10:52 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Help with building patch Rob he's trying to use v2.0 how-to guide with the v3.5 toolset. I'd wait for someone else to verify this is an actual bug as it works completely fine in v3.0. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 16 November 2009 15:32 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Help with building patch Yes, please open a bug on v3.5. That is under development and bugs help us quickly find what was recently broken. On Mon, Nov 16, 2009 at 7:12 AM, Schmitz, John jschm...@mediacy.com wrote: I installed and switched to using WIX 2.0 (stable). This clarified two things: 1) SOME of the changes that I specify in my bug are indeed only needed to adapt the WSX file to version 3.5. The original code in the page works with 2.0 IF you know to save it as a WSX file and use it as the source for the compilation. 2) 3.5 does NOT work and 2.0 DOES work. Should I enter a bug on 3.5? Thanks, John From: Schmitz, John Sent: Sunday, November 15, 2009 8:36 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Help with building patch I'm using 3.5. Message Sent with NotifySync -Original Message- From: os...@live.com Sent: Sat, 14 Nov 2009 19:33:06 America/New_York To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Help with building patch Version 3.0 supports both the version 2 method (msimsp.exe/PatchWiz) and the pure WiX method (torch/pyro). Version 3.5 retains that support. Each of those two methods in the version 3 docs are described on two different pages. Not sure on the error message (although I haven't looked at the code yet). The TargetImages probably refers to the table itself, but with a path to the MSI file itself in the error message as being the missing symbol seems like something isn't quite right. Which version/build of the
Re: [WiX-users] How can I pass values between dialog boxes
In article bay112-w17f0787cea4f94922e1829c7...@phx.gbl, Uday Kumar uda...@hotmail.com writes: In wix-msi how can I pass the values between two dialog boxes. I will select one item from combo box of first screen/dialog, based on the selection, secon d screen combo box should populate. How can i pass the values of screen one to second screen. If your choices for the second combobox are fixed for each choice in the first combobox, then I would create N comboboxes on the second dialog, one for each of the N choices on the first dialog. Have all the comboboxes on the second dialog initially hidden and show the one based on the choice on the first dialog. That way you avoid having to write custom code to dynamically populate the second combobox based on the choice made for the first one. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/ Legalize Adulthood! http://legalizeadulthood.wordpress.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Errors using performance counters after installing with PerformanceCounter/PerformanceCounterCategory
After diffing the registry changes between the WiX and Installer setups, I think I found the difference. In the installer, there is an extra CategoryOptions key that is set to 3. After some digging, I found this article (http://blogs.msdn.com/bclteam/archive/2005/03/16/396856.aspx) explaining what exactly that means. Turns out that this is exactly how you set the global vs. private shared memory for counters in version 2 and later. I think I'll be able to hack this registry key into my installer for now, but this might be a good candidate for an update to the utility extension. -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, November 20, 2009 2:15 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Errors using performance counters after installing with PerformanceCounter/PerformanceCounterCategory The wxs effectively does what is described on the following page: http://msdn.microsoft.com/library/aa371878.aspx, which produces a registration in the system registry of the performance counter. A quick search for me didn't reveal what the implementation of the PerformanceCounterInstaller class does. I must admit that while I have written and read performance counters, it was all pre-.Net, so I don't know the interop (except that there apparently is one). Maybe you could as in some .net forum what relationship there is between the PerformaceCounterInstaller and the MSDN page I found, and how to interoperate those together. -Original Message- From: Rich Daniel [mailto:rdan...@microsoft.com] Sent: Thursday, November 19, 2009 9:51 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Errors using performance counters after installing with PerformanceCounter/PerformanceCounterCategory I'll give you the wix, the installer code, and the usage all side by side: .wxs fragment: Component Id=MyApp Guid=---- KeyPath=yes File Name=$(var.MyApp.TargetFileName) Source=$(var.MyApp.TargetPath) DiskId=1 / File Name=$(var.MyApp.TargetName).pdb Source=$(var.MyApp.TargetDir)$(var.MyApp.TargetName).pdb DiskId=1 / util:PerformanceCategory Id=MyAppCategory Name=My Application Help=Custom performance counters for my application. MultiInstance=yes util:PerformanceCounter Name=My First Counter Help=The first custom counter for my application. Type=numberOfItems64 / /util:PerformanceCategory /Component .cs fragment (installer): PerformanceCounterInstaller category = new PerformanceCounterInstaller(); category.CategoryName = My Application; category.CategoryHelp = Custom performance counters for my application.; category.CategoryType = PerformanceCounterCategoryType.MultiInstance; CounterCreationData counter = new CounterCreationData(); counter.CounterName = My First Counter; counter.CounterHelp = The first custom counter for my application.; counter.CounterType = PerformanceCounterType.NumberOfItems64; counterInstaller.Counters.Add(counter); .cs fragment (usage): PerformanceCounter counter = new PerformanceCounter(); counter.CategoryName = MyApp.CounterCategoryName; counter.CounterName = MyApp.FirstCounterName; counter.InstanceName = newInstanceName; counter.InstanceLifetime = PerformanceCounterInstanceLifetime.Process; counter.ReadOnly = false; counter.Increment(); // This throws InvalidOperationException -Original Message- From: Sebastian Brand (Instyler Software) [mailto:wix+us...@instyler.com] Sent: Wednesday, November 18, 2009 9:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Errors using performance counters after installing with PerformanceCounter/PerformanceCounterCategory Can you give us the corresponding .wxs code? Best regards, Sebastian Brand Deployment consultant E-Mail: sebast...@instyler.com Instyler Setup - Creating WiX-based MSI installations, elegantly. http://www.instyler.com On 18.11.2009, at 21:13, Rich Daniel wrote: I'm in the process of migrating my app installation to wix. It's a .NET 2.0 app that currently uses installutil to add some custom performance counters and event log sources. Seeing as how I noticed that WixUtilExtension.dll supplies this functionality from the installer, I thought I'd give it a try instead. I'm rubbing up against an issue, however. The installation completes just fine, but the moment my app attempts to modify a counter, it goes bang with the following exception: System.InvalidOperationException: PerformanceCounterInstanceLifetime.Process is not valid in the global shared memory. If your performance counter category was created with an older version of the Framework, it uses the global shared memory. Either use PerformanceCounterInstanceLifetime.Global, or if applications running on older versions of the Framework do not need to write to your category, delete and recreate it. If I believe that error, the way I've
Re: [WiX-users] So much space requires on C drive
Here's what I recall from memory - the MSI is cached under [Windows]\Installer folder, which takes up space. Space is also required on the drive that Windows is installed on in order to unpack local copies of files/cabs before they're placed in their final destinations. If you review the MSI documentation on MSDN, it will explain it in more detail. Working around this issue will be difficult. Wendell Joost On Thu, Nov 19, 2009 at 10:58 PM, rahul.ekb...@sungard.com wrote: Hi All, When we installs our product, though we choose other drive like d: or e: still it checks the space of c: drive. It asks minumn 700MB empty space on c: drive. I tried to change the temp location to d:\ but no use and I think we not force user to change his temp folder location. Please let me know if there is any solution for this. Thanks, Rahul. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Some people come visit Europe and are really let down when they find out it's not like a credit-card commercial; others really get into meeting all the quirky people and careening along narrow mountain roads in rickety cabs driven by suicidal, gap-toothed Carpathians. I guess it's pretty obvious which one you are... - Justin Crevier, May '01 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] AppSecInc. MSI Extensions Open-Sourced
I am pleased to announce the open-sourcing of AppSecInc. MSI Extensions under the Eclipse Public License. http://msiext.codeplex.com/ This is a collection of MSI custom actions and WIX extensions, originally developed for a large enterprise product, and now open-sourced under the Eclipse Public License. The project grew incrementally implementing everything that wix didn't have out of the box. Code is fully unit-tested. Wix Extensions * System Tools: deals with copying, moving, deleting files out of sequence, compare versions, execute commands, process template files, copy registry keys, etc. * Java Tools: deals with jar and unjar. * Data Sources: deals with generic ODBC and specific MSAccess and MSSQL databases, SQL files, etc. * User Privileges: deals with local users and groups. * Common UI: dialogs for installing Windows services and databases with credentials. Immediate Custom Actions * Manipulating files, folders, registry, services. * String template and regex processing. * Active Directory functions. * ODBC and DMO functions. * Local users, groups, security and privileges. * Encryption, decryption, signing. * Xml file manipulation. * TcpIp functions. Additional Features * Supports impersonation in all custom actions. Hope this helps. Please contribute. cheers dB. dB. @ dblock.orghttp://www.dblock.org/ Moscow|Geneva|Seattle|New York -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Feature selection and CustomAction commandline
No. No its not working. I tried different ways. Let me copy the code here and show what exactly I changed. This is the custom dialog code Property Id=SERVERVALUE Value=0/ UI Dialog Id=InstallDlg Width=370 Height=270 Title=!(loc.SetupTypeDlg_Title) NoMinimize=yes Control Id=Next Type=PushButton X=236 Y=243 Width=56 Height=17 Default=yes Text=!(loc.WixUINext) Publish Property =SERVERVALUE Value=0INSTALLTYPE =CompleteServer/Publish Publish Property =SERVERVALUE Value=0INSTALLTYPE =CompleteDatabaseServer/Publish Publish Property =SERVERVALUE Value=3INSTALLTYPE=CompleteWorkstation/Publish Publish Event=AddLocal Value=CompleteServer![CDATA[(INSTALLTYPE =CompleteServer)]]/Publish Publish Event=Remove Value=CompleteServer![CDATA[NOT(INSTALLTYPE=CompleteServer)]]/Publish Publish Event=AddLocal Value=CompleteDatabaseServer![CDATA[(INSTALLTYPE =CompleteDatabaseServer)]]/Publish Publish Event=Remove Value=CompleteDatabaseServer![CDATA[NOT(INSTALLTYPE=CompleteDatabaseServer)]]/Publish Publish Event=AddLocal Value=CompleteWorkstation![CDATA[(INSTALLTYPE=CompleteWorkstation)]]/Publish Publish Event=Remove Value=CompleteWorkstation![CDATA[NOT(INSTALLTYPE=CompleteWorkstation)]]/Publish /Control Am I doing something wrong here This is the custom action CustomAction Id=ExecuteTools FileKey=caAutoCreateUpdateDB.exe ExeCommand=[SERVERVALUE] Execute=immediate Impersonate=no Return=asyncWait HideTarget=no/ I even tried to display the SERVERVALUE using a message box it shows blank. CustomAction Id=ShowProperty Script=vbscript Execute=deferred ![CDATA[ MsgBox Session.Property(SERVERVALUE) ]] /CustomAction InstallExecuteSequence Custom Action=ShowProperty Before=InstallFinalizeNot Installed/Custom Custom Action=ExecuteTools After=InstallFinalize/ ScheduleReboot After='InstallFinalize' / /InstallExecuteSequence Please help. Also, I have another problem with the BootStrapper I have to install the following pre-requisite in the same order 1. Windows Installer 4.5 2..NET 3.5 SP1 3. SQL 2008 4. Crystal Reports runtime basic But, on a Pristine Windows XP, Crystal Reports starts to install first and Installer fails because it has no W Installer 45 and .NET 35 Where do I set the sequence of which installation should start first? Thanks, Arun Perregattur -Original Message- From: Sebastian Brand (Instyler Software) [mailto:wix+us...@instyler.com] Sent: Friday, November 20, 2009 2:39 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Feature selection and CustomAction commandline Well yes, does it work? Best regards, Sebastian Brand Deployment consultant E-Mail: sebast...@instyler.com Blog: www.sebastianbrand.com -Original Message- From: Arun Perregatturv [mailto:aperregatt...@napcosecurity.com] Sent: Thursday, November 19, 2009 21:23 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Feature selection and CustomAction commandline I tried as you said Publish Property =SERVERVALUE Value=1INSTALLTYPE=CompleteServer/Publish Publish Property =SERVERVALUE Value=2INSTALLTYPE=CompleteDatabaseServer/Publish Publish Property =SERVERVALUE Value=3INSTALLTYPE=CompleteWorkstation/Publish And CustomAction Property Id=CAAUTOCREATEUPDATEDB Value=[#caAutoCreateUpdateDB.exe] / CustomAction Id=ExecuteTools Property=CAAUTOCREATEUPDATEDB Directory=APPLICATION_TOOLS_DIRECTORY ExeCommand=[SERVERVALUE] Return=asyncWait / This is right? Arun Perregattur -Original Message- From: Sebastian Brand (Instyler Software) [mailto:wix+us...@instyler.com] Sent: Thursday, November 19, 2009 10:27 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Feature selection and CustomAction commandline The INSTALLTYPE property will contain the values CompleteServer, CompleteDatabaseServer or CompleteWorkstation after the selection was made. You can either change these values to 1,2,3 or create three SetProperty control events, one for each install type: Publish Property=NEWPROP Value=1INSTALLTYPE=CompleteServer/Publish Put these Publish elements before the first Publish element of the Next- Button. Then use the [NEWPROP] in your ExeCommand attribute for running the custom action. Best regards, Sebastian Brand Deployment consultant E-Mail: sebast...@instyler.com Blog: www.sebastianbrand.com On 19.11.2009, at 14:57, Arun Perregatturv wrote: Dialog
Re: [WiX-users] How to retrieve ProductCode outside MSI
http://dotnetinstaller.codeplex.com does this via MsiEnumProducts. http://dotnetinstaller.codeplex.com/sourcecontrol/changeset/view/34925?projectName=dotnetinstaller#640592 http://dotnetinstaller.codeplex.com/sourcecontrol/changeset/view/34925?projectName=dotnetinstaller#640586 Hope this helps, dB. dB. @ dblock.org Moscow|Geneva|Seattle|New York -Original Message- From: Sebastian Brand (Instyler Software) [mailto:wix+us...@instyler.com] Sent: Thursday, November 19, 2009 7:29 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to retrieve ProductCode outside MSI Untested but'll you get the idea: Set installer = Wscript.CreateObject(WindowsInstaller.Installer) Set database = installer.OpenDatabase(c:\path\toyour\msifile.msi, 0) query = SELECT 'Value' FROM Property WHERE Property='ProductCode' Set view = database.OpenView(query) view.Execute Set record = view.Fetch WScript ProductCode is record.StringData(1) Best regards, Sebastian Brand Deployment consultant E-Mail: sebast...@instyler.com Instyler Setup - Creating WiX-based MSI installations, elegantly. http://www.instyler.com On 19.11.2009, at 11:42, Jiang, Chunyan (GE Healthcare) wrote: Hi Rob, Thanks for your reply. I got some information for other person that I can use MsiOpenDatabase/MsiViewExecute But I have no idea how to use it. Could you please give me some example? Regards, Chunyan -Ursprüngliche Nachricht- Von: Rob Mensching [mailto:r...@robmensching.com] Gesendet: Donnerstag, 19. November 2009 07:19 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] How to retrieve ProductCode outside MSI Outside the MSI you need to use the SQL statements to query the Property table. On Wed, Nov 18, 2009 at 7:26 AM, Jiang, Chunyan (GE Healthcare) chunyan.ji...@ge.com wrote: Hi, I developed one app.msi to intall one app. And I need to develop one bootstraper.exe to retrieve the ProductCode of previously installed app. Since it is multiple instance installation, there will be more than one ProductCode. I have used some MSI functions to retrieve the property when developing the installer with WiX, like: ::MsiGetPropertyW(hInstaller, LPREVIOUSFOUND, ProductIDbuffer , length1); It is one custom action dll in WiX project. Here, MSIHANDLE hInstaller will pass the handle to the function. It is inside the MSI project. So it is easy. But how to get such handle outside the MSI project? I found there is one function: UINT MsiGetProductCode( LPCTSTR szComponent, LPTSTR lpProductBuf ); It uses component code to retrieve product code. I have the component code in hand. However, there will be more installation, which use the same component code. Which one will be returned? Could some one help me? Chunyan -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net
Re: [WiX-users] FIXED: Errors using performance counters after installing with PerformanceCounter/PerformanceCounterCategory
The MSI works with this new fragment: Component Id=MyApp Guid=---- KeyPath=yes File Name=$(var.MyApp.TargetFileName) Source=$(var.MyApp.TargetPath) DiskId=1 / File Name=$(var.MyApp.TargetName).pdb Source=$(var.MyApp.TargetDir)$(var.MyApp.TargetName).pdb DiskId=1 / util:PerformanceCategory Id=MyAppCategory Name=My Application Help=Custom performance counters for my application. MultiInstance=yes util:PerformanceCounter Name=My First Counter Help=The first custom counter for my application. Type=numberOfItems64 / /util:PerformanceCategory !-- This is the secret sauce to light up per-process .NET counters. The My Application subkkey needs to match the category name. -- RegistryKey Root=HKLM Key=SYSTEM\CurrentControlSet\services\My Application\Performance RegistryValue Name=CategoryOptions Type=integer Value=3 / /RegistryKey /Component Thanks - Rich -Original Message- From: Rich Daniel [mailto:rdan...@microsoft.com] Sent: Friday, November 20, 2009 10:31 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Errors using performance counters after installing with PerformanceCounter/PerformanceCounterCategory After diffing the registry changes between the WiX and Installer setups, I think I found the difference. In the installer, there is an extra CategoryOptions key that is set to 3. After some digging, I found this article (http://blogs.msdn.com/bclteam/archive/2005/03/16/396856.aspx) explaining what exactly that means. Turns out that this is exactly how you set the global vs. private shared memory for counters in version 2 and later. I think I'll be able to hack this registry key into my installer for now, but this might be a good candidate for an update to the utility extension. -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, November 20, 2009 2:15 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Errors using performance counters after installing with PerformanceCounter/PerformanceCounterCategory The wxs effectively does what is described on the following page: http://msdn.microsoft.com/library/aa371878.aspx, which produces a registration in the system registry of the performance counter. A quick search for me didn't reveal what the implementation of the PerformanceCounterInstaller class does. I must admit that while I have written and read performance counters, it was all pre-.Net, so I don't know the interop (except that there apparently is one). Maybe you could as in some .net forum what relationship there is between the PerformaceCounterInstaller and the MSDN page I found, and how to interoperate those together. -Original Message- From: Rich Daniel [mailto:rdan...@microsoft.com] Sent: Thursday, November 19, 2009 9:51 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Errors using performance counters after installing with PerformanceCounter/PerformanceCounterCategory I'll give you the wix, the installer code, and the usage all side by side: .wxs fragment: Component Id=MyApp Guid=---- KeyPath=yes File Name=$(var.MyApp.TargetFileName) Source=$(var.MyApp.TargetPath) DiskId=1 / File Name=$(var.MyApp.TargetName).pdb Source=$(var.MyApp.TargetDir)$(var.MyApp.TargetName).pdb DiskId=1 / util:PerformanceCategory Id=MyAppCategory Name=My Application Help=Custom performance counters for my application. MultiInstance=yes util:PerformanceCounter Name=My First Counter Help=The first custom counter for my application. Type=numberOfItems64 / /util:PerformanceCategory /Component .cs fragment (installer): PerformanceCounterInstaller category = new PerformanceCounterInstaller(); category.CategoryName = My Application; category.CategoryHelp = Custom performance counters for my application.; category.CategoryType = PerformanceCounterCategoryType.MultiInstance; CounterCreationData counter = new CounterCreationData(); counter.CounterName = My First Counter; counter.CounterHelp = The first custom counter for my application.; counter.CounterType = PerformanceCounterType.NumberOfItems64; counterInstaller.Counters.Add(counter); .cs fragment (usage): PerformanceCounter counter = new PerformanceCounter(); counter.CategoryName = MyApp.CounterCategoryName; counter.CounterName = MyApp.FirstCounterName; counter.InstanceName = newInstanceName; counter.InstanceLifetime = PerformanceCounterInstanceLifetime.Process; counter.ReadOnly = false; counter.Increment(); // This throws InvalidOperationException -Original Message- From: Sebastian Brand (Instyler Software) [mailto:wix+us...@instyler.com] Sent: Wednesday, November 18, 2009 9:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Errors using performance counters
Re: [WiX-users] FIXED: Errors using performance counters after installing with PerformanceCounter/PerformanceCounterCategory
Rich Daniel wrote: Component Id=MyApp Guid=---- KeyPath=yes You should consider making the executable file the keypath for the component; patching and upgrades work a lot better if there's a versioned file as keypath. !-- This is the secret sauce to light up per-process .NET counters. The My Application subkkey needs to match the category name. -- RegistryKey Root=HKLM Key=SYSTEM\CurrentControlSet\services\My Application\Performance RegistryValue Name=CategoryOptions Type=integer Value=3 / /RegistryKey Please consider contributing a fix to WixUtilExtension so others can benefit too. -- sig://boB http://joyofsetup.com/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] So much space requires on C drive
rahul.ekb...@sungard.com wrote: When we installs our product, though we choose other drive like d: or e: still it checks the space of c: drive. It asks minumn 700MB empty space on c: drive. http://blogs.msdn.com/heaths/archive/2008/07/24/why-windows-installer-may-require-so-much-disk-space.aspx -- sig://boB http://joyofsetup.com/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install files side-by-side with a patch
Yan Sklyarenko wrote: FileA.txt.patched (the one installed by the patch) I'm not a patching guru, but I highly doubt that's going to be possible. The resource (file) would no longer represent how it's defined in the component. -- sig://boB http://joyofsetup.com/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] One MSI with CAB files in different directories
Alexander Miseler wrote: I basically want a one file setup, but my content is way above 2 GByte. Thus I will have something like my_product.exe, my_product2.cab, my_product3.cab, ... The EXE contains the MSI, the my_product1.cab, and some other stuff. When executed the content of the EXE is copied to a temp directory and then the installation is launched from there. Of course now the Installer doesn't find the other CABs as they are in a different directory. Extract the .msi and .cabs to the same directory. -- sig://boB http://joyofsetup.com/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Help with building patch
Since several of you have suggested trying the torch/pyro method of creating a patch, I am trying that. Sorry to be a pain, but I'm stuck on the pyro step. Gabor's tutuorial uses the word Sample in a LOT of places and no matter what I try in my actual example, I get a PYRO0252 error. The text of the error message doesn't give me a lot of clues as to what I'm doing wrong. Specifically, I have no idea exactly what transform it is looking for. None of the other tools up to that point report any error, but then I can see that pyro is the one that ties it all together. Any help or clues or pointers to other tutorials that use more descriptive names would be EXTREMELY appreciated. I'm already two weeks late getting this patch out! Thanks, John From: Schmitz, John Sent: Friday, November 20, 2009 11:57 AM To: Schmitz, John Subject: RE: [WiX-users] Help with building patch I found Gábor DEÁK JAHN's tutorial, and I'm trying to figure out how to apply the pyro/torch method to my setups, which involve multiple .WSX and .WIXOBJ files. Thanks, John Media Cybernetics From: Schmitz, John Sent: Friday, November 20, 2009 10:54 AM To: General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] Help with building patch Sounds interesting, but I don't understand how I would do that from the help page. It talks about two text files - are those supposed to represent the hundreds of files in my installation? Can you point me towards any sort of tutorial using pyro, etc., because as I stated earlier, I have no idea what they do. My apologies on that point, but I got WIX as part of a setup/installer building software, and their emphasis is on using their software, which effectively hides all the use of WIX under the hood. This might be exactly what I need to fix my problems, because right now, my application does not work when I install the original release and patch it to the .0.1 version with the patch, while it works perfectly if I install the full .0.1 setup that I have to build as the reference for the MSIMSP build process. Thanks, John Media Cybernetics From: Blair [os...@live.com] Sent: Friday, November 20, 2009 3:23 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Help with building patch We had a build process that ran from a service account in a build lab of over a thousand machines. We discovered that msimsp.exe/patchwiz.dll will sometimes pop up a dialog box if we didn't do a good enough job catching all the possible error conditions and stall waiting for its OK button to be pressed, which was an absolute disaster in our build environment. Pyro/torch/et al proved to be a savior for us to be able to build MSPs as a routine development activity instead of only 3-4 times per public release at the most. Further, if you suppress ICE validation (since ICE validation requires either an interactive login or administrative privileges) you can use wixpdb files and build MSP files without having to grant your build process any admin privilege (makes network admins happier). You can't do that with admin installs that will eventually require administrator's privs to install. -Original Message- From: Schmitz, John [mailto:jschm...@mediacy.com] Sent: Monday, November 16, 2009 8:33 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Help with building patch The way I understand a previous comment from Blair, there was no intention to deprecate the 2.0 approach to patches. Unless I am misunderstanding something, the 2.0 approach is much, much more useful for an automated build than the 3.0 approach. From: Pally Sandher [pally.sand...@iesve.com] Sent: Monday, November 16, 2009 10:52 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Help with building patch Rob he's trying to use v2.0 how-to guide with the v3.5 toolset. I'd wait for someone else to verify this is an actual bug as it works completely fine in v3.0. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 16 November 2009 15:32 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Help with building patch Yes, please open a bug on v3.5. That is under development and bugs help us quickly find what was recently broken. On Mon, Nov 16, 2009 at 7:12 AM, Schmitz, John jschm...@mediacy.com wrote: I installed and switched to using
[WiX-users] Patch registry problem
Hi, I've created a patch from 2 MSI files (unfortunately I don't have the original wix object files so have to use MSIs) using the following, which all seemed to go fine: msiexec /a orig\Installer.msi TARGETDIR=c:\src\patch\orig\admin msiexec /a new\Installer.msi TARGETDIR=c:\src\patch\new\admin torch -p -ax diff -xo orig\admin\Installer.msi new\admin\Installer.msi -out diff.wixout candle.exe Patch.wxs light.exe Patch.wixobj -out Patch.WixMsp pyro patch.wixmsp -out Patch.msp -t IE8 diff.wixout using the following for the patch.wxs file ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Patch AllowRemoval=yes Manufacturer=Kickstone Technologies Ltd MoreInfoURL=http://www.pricegoblin.co.uk/; DisplayName=IE8 Patch Description=IE8 Patch Classification=Update Media Id=5000 Cabinet=IE8.cab PatchBaseline Id=IE8/ /Media PatchFamily Id='SamplePatchFamily' Version='1.0.0' Supersede='yes' /PatchFamily /Patch /Wix The patch seems to have been created fine and seems to run fine except for one problem. One of the components changed in the patch has a number of registry entries which are also changed (it is a COM object). The patch successfully installs the new registry values, but doesn't remove the old ones. If i uninstall the product after applying the patch, the new registry values are removed as expected, but the original ones are left behind. This seems to indicate the patch partially replaced the mappings for the registry values in the installation. Have I missed an option or otherwise doing something else wrong, or is this unexpected behaviour indicitive of a bug Thanks for your help. John -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Updating registry during Install/UnInstall/Change
Hi, My scenario needs to create/update registry values on Install/Change. My code to create the registry is:- Component Id=MyRegistry Win64=yes Guid=MyGuid RegistryKey Root=HKLM Key=MyKey RegistryValue Name=MyName Type=string Value=[MYPUBLICPROP] KeyPath=yes/ /RegistryKey /Component The registry is created on install with the value of MYPUBLICPROP. However after install, if I choose 'Change' to update the public property the registry value is not updated. From the logs it appears that the Component at that point is considered as already installed and hence the registry value is not updated. What should I be doing to be able to update registry during Change? Any help is much appreciated. Thanks Vidya -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] verification with smoke and message filtering
I just started using smoke for verification, I notice that many of the messages have the same warning/error id, even when the ICE number and message content are different. For example: warning SMOK1076 : ICE30: The target file 'rwfvlhtq.lm8|ATL80.dll' might be installed in '[SystemFolder]' by two different conditionalized components on an LFN system: 'nosxs.97F81AF1_0E47_DC99_FF1F_C8B3B9A1E18E' and 'ansi_atl80.97F81AF1_0E47_DC99_FF1F_C8B3B9A1E18E'. If the conditions are not mutually exclusive, this will break the component reference counting system. warning SMOK1076 : ICE30: The target file 'rwfvlhtq.lm8|ATL80.dll' might be installed in '[SystemFolder]' by two different conditionalized components on an LFN system: 'nosxs.97F81AF1_0E47_DC99_FF1F_C8B3B9A1E18E' and 'ansi_atl80.97F81AF1_0E47_DC99_FF1F_C8B3B9A1E18E'. If the conditions are not mutually exclusive, this will break the component reference counting system. error SMOK0204 : ICE64: The directory SM_License is in the user profile but is not listed in the RemoveFile table. warning SMOK1076 : ICE68: Even though custom action 'UninstallAladdin.F49F1D5A_B1C4_4E02_A9D2_E3F551265430' is marked to be elevated (with attribute msidbCustomActionTypeNoImpersonate), it will not be run with elevated privileges because it's not deferred (with attribute msidbCustomActionTypeInScript). error SMOK0204 : ICE79: Component 'activationclient.exe' referenced in column 'InstallExecuteSequence'.'Condition' of row 'ASRActivate' is invalid. error SMOK0204 : ICE79: Component 'activationclient.exe' referenced in column 'InstallExecuteSequence'.'Condition' of row 'ASRDeactivate' is invalid. error SMOK0204 : ICE79: Component 'activationclient.exe' referenced in column 'InstallExecuteSequence'.'Condition' of row 'ASRDeactivate' is invalid. warning SMOK1076 : ICE82: This action CAProgressDialogDeferred has duplicate sequence number 6504 in the table InstallExecuteSequence warning SMOK1076 : ICE86: Property `AdminUser` found in column `LaunchCondition`.`Condition` in row 'AdminUser'. `Privileged` property is often more appropriate. All the warnings are SMOK1076 and all the errors are SMOK0204. Is this correct? From the perspective of attempting to filter specific warnings, I would have expected that each warning message would have its own id, which would then let me filter out the ICE30: target file . messages, without also suppressing the others. thanks, bill -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to patch elements in InstallExecuteSequence table?
We made some changes to the MSI installer that was released this year and we are releasing the SP soon. One of those changes include adding support to uninstall the patches. For this, we modified some Custom elements in InstallExecuteSequence table of the MSI generating WXS file. (I am not sure if these are the same as CustomActions though!) Anyway, how do we specify in the Patch.wxs that these Custom elements need to be patched? For instance, here's the change which says that we should not run this action when uninstalling the patch - Custom Action='_GetServiceState' After='_SetADName'![CDATA[Installed And REMOVEALL And Not MSIPATCHREMOVE ]]/Custom And here's how I listed it in the Patch.wxs - PatchFamily Id=AgentPatchFamily Version=1.0.0.1 Supersede=yes !-- Nothing here as of now -- CustomActionRef Id=_GetServiceState / /PatchFamily I have also tried this way - Fragment InstallExecuteSequence Custom Action=_GetServiceState After=_SetADName / InstallServices Sequence=5800 / DeleteServices Sequence=2000 / /InstallExecuteSequence /Fragment However in both the cases, when I generated the patch and applied it to the release MSI through ORCA, I don't see this change at all! Another similar issue is with InstallServices and DeleteServices elements of the same InstallExecuteSequence table. Can someone tell me if this is the right way to do this? Thanks, Sharat Janapareddy ~ 40269 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] FW: Torch error
I'm building an msp using wix v3 for an msi that was built with version v2. So If I provide the msi I get this : torch -p -ax C:\F14patch\OCS\EN-US\Error\extracted\fso.msi C:\F14patch\OCS\EN-US\Fixed\Extracted\fso.msi -out diff.wixmst torch.exe : error TRCH0280 : The -ax option requires a directory, but the provided path is a file: C:\F14patch\OCS\EN-US\Error\extracted\fso.msi and If I use just -a and path, I'm able to create the mst file but the fails to create the msp. pyro.exe Patch.WixMsp -out Patch.msp -t RTM Diff.wixmst Diff.wixmst : error PYRO0104 : Not a valid output file; detail: Invalid character in the given encoding. Line 1, position 1. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to patch standard actions?
FYI, I was able to figure out how to include CustomActions in the patch. But the one thing that I don't see in the WIX documentation is how to patch Standard Actions. Thanks, Sharat Janapareddy ~ 40269 -Original Message- From: Sharat Janapareddy [mailto:sharat.janapare...@microsoft.com] Sent: Friday, November 20, 2009 1:02 PM To: General discussion for Windows Installer XML toolset. Cc: Clive Eastwood; Anandha Ganesan Subject: [WiX-users] How to patch elements in InstallExecuteSequence table? We made some changes to the MSI installer that was released this year and we are releasing the SP soon. One of those changes include adding support to uninstall the patches. For this, we modified some Custom elements in InstallExecuteSequence table of the MSI generating WXS file. (I am not sure if these are the same as CustomActions though!) Anyway, how do we specify in the Patch.wxs that these Custom elements need to be patched? For instance, here's the change which says that we should not run this action when uninstalling the patch - Custom Action='_GetServiceState' After='_SetADName'![CDATA[Installed And REMOVEALL And Not MSIPATCHREMOVE ]]/Custom And here's how I listed it in the Patch.wxs - PatchFamily Id=AgentPatchFamily Version=1.0.0.1 Supersede=yes !-- Nothing here as of now -- CustomActionRef Id=_GetServiceState / /PatchFamily I have also tried this way - Fragment InstallExecuteSequence Custom Action=_GetServiceState After=_SetADName / InstallServices Sequence=5800 / DeleteServices Sequence=2000 / /InstallExecuteSequence /Fragment However in both the cases, when I generated the patch and applied it to the release MSI through ORCA, I don't see this change at all! Another similar issue is with InstallServices and DeleteServices elements of the same InstallExecuteSequence table. Can someone tell me if this is the right way to do this? Thanks, Sharat Janapareddy ~ 40269 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch registry problem
Hi, I've created a patch from 2 MSI files (unfortunately I don't have the original wix object files so have to use MSIs) using the following, which all seemed to go fine: details skipped The patch seems to have been created fine and seems to run fine except for one problem. One of the components changed in the patch has a number of registry entries which are also changed (it is a COM object). The patch successfully installs the new registry values, but doesn't remove the old ones. If i uninstall the product after applying the patch, the new registry values are removed as expected, but the original ones are left behind. This seems to indicate the patch partially replaced the mappings for the registry values in the installation. Have I missed an option or otherwise doing something else wrong, or is this unexpected behaviour indicitive of a bug A couple of things I probably should have mentioned, firstly I'm using WIX v3.0.5322.0. Secondly, in the diff.wixout that is generated above, I can see entries in the Registry table with op = delete which match what should be removed, but it doesn't seem to be applied by the patch. Similarly if I do a verbose log of the patch process, I can see all the RegAddValue operations for the new data. Thanks John -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to patch standard actions?
Nope, I don't see them being updated. I am checking this with Orca. Even the custom actions that I got working, I had to add them to a patch family. Thanks, Sharat Janapareddy ~ 40269 -Original Message- From: Heath Stewart Sent: Friday, November 20, 2009 2:34 PM To: Sharat Janapareddy; General discussion for Windows Installer XML toolset. Cc: Clive Eastwood; Anandha Ganesan Subject: RE: How to patch standard actions? If these are added to the upgrade build, they should be pulled in automatically. Is that not happening? Heath Stewart Deployment Technology Group, Microsoft http://blogs.msdn.com/heaths -Original Message- From: Sharat Janapareddy Sent: Friday, November 20, 2009 2:25 PM To: General discussion for Windows Installer XML toolset. Cc: Clive Eastwood; Anandha Ganesan; Heath Stewart Subject: How to patch standard actions? FYI, I was able to figure out how to include CustomActions in the patch. But the one thing that I don't see in the WIX documentation is how to patch Standard Actions. Thanks, Sharat Janapareddy ~ 40269 -Original Message- From: Sharat Janapareddy [mailto:sharat.janapare...@microsoft.com] Sent: Friday, November 20, 2009 1:02 PM To: General discussion for Windows Installer XML toolset. Cc: Clive Eastwood; Anandha Ganesan Subject: [WiX-users] How to patch elements in InstallExecuteSequence table? We made some changes to the MSI installer that was released this year and we are releasing the SP soon. One of those changes include adding support to uninstall the patches. For this, we modified some Custom elements in InstallExecuteSequence table of the MSI generating WXS file. (I am not sure if these are the same as CustomActions though!) Anyway, how do we specify in the Patch.wxs that these Custom elements need to be patched? For instance, here's the change which says that we should not run this action when uninstalling the patch - Custom Action='_GetServiceState' After='_SetADName'![CDATA[Installed And REMOVEALL And Not MSIPATCHREMOVE ]]/Custom And here's how I listed it in the Patch.wxs - PatchFamily Id=AgentPatchFamily Version=1.0.0.1 Supersede=yes !-- Nothing here as of now -- CustomActionRef Id=_GetServiceState / /PatchFamily I have also tried this way - Fragment InstallExecuteSequence Custom Action=_GetServiceState After=_SetADName / InstallServices Sequence=5800 / DeleteServices Sequence=2000 / /InstallExecuteSequence /Fragment However in both the cases, when I generated the patch and applied it to the release MSI through ORCA, I don't see this change at all! Another similar issue is with InstallServices and DeleteServices elements of the same InstallExecuteSequence table. Can someone tell me if this is the right way to do this? Thanks, Sharat Janapareddy ~ 40269 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] IIS Extension - ICE68 Validation Error
I have a WiX MM project that builds through Visual Studio without any validation errors. However if I use ORCA to validate the module ( using the mergemod.cub found in the WiX directory ) I get a series of ICE68 error messages complaining that the CA type is invalid.The CA name's and types that are redlined are: AddUserCertificate 25601 DeleteUserCertificate 25601 RollbacAddUserCertificate 25857 RollbackDeleteUserCertifcate 25857 I looked up 25601 and it seems to be DLL in binary table, terminal server aware and hidden.This seems like a valid # to me. My .Wixproj settings don't seem to be suppressing validation or any particular ICE's so I'm not sure why I'm not catching the error there during the build. Has anyone seen this before? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Shared assemblies
If I had two applications which shared some core assemblies, how would these handled between two installers? If I shared a WiX fragment source file between two WiX projects, the components would have the same GUIDs. Would that cause a problem or conflict? Could the two projects be installed, for example, on two separate drive letters? I'm not sure if MSI insists on having only one instance of a component with a particular GUID, or if it tolerates two installers listing the same component GUID in separate locations. Any recommendations on how this is supposed to be handled? Thanks! -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to get USERDOMAIN?
http://msiext.codeplex.com has a CA to get extensive user info that uses Win32 API. CustomAction Id=GetUserInfo BinaryKey=UserPrivileges DllEntry=GetUserInfo Execute=immediate Return=check / Here's what it returns: \return USER_FQN DNS domain name followed by a backward-slash and the SAM username \return USER_NAME full username, includes the domain for domain users \return USER_DOMAIN qualified domain from LookupAccountName \return USER_SID user SID -dB. dB. @ dblock.org Moscow|Geneva|Seattle|New York -Original Message- From: Konstantin Vlasenko [mailto:konstantin.vlase...@gmail.com] Sent: Thursday, October 22, 2009 11:53 PM To: General discussion for Windows Installer XML toolset. Cc: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to get USERDOMAIN? It is exactly what I need:) Sent from my iPhone 23.10.2009, в 1:05, Michael Osmond mosm...@baytech.com.au написал(а): The big issue with %USERDOMAIN is that it is the domain of the user account that is logged on (and running the install). This may not be the Domain you are after. Example: You are installing software on a Server in an Active Directory domain. You want the domain name of AD - but the user account logged on is the local administrator for the server, in this case the %USERDOMAIN will actually be the server name, as this is a local account. By the way, I have not found an easy way to get the domain in this case, other than prompt for it. Michael -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, 23 October 2009 6:51 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How to get USERDOMAIN? If it exists and you trust it, it can be used in any field that accepts environment variables (for example: formatted). It cannot be evaluated within the context of a deferred custom action, but it can be evaluated in the process of writing the deferred script, so it should work in the CustomAction table even for deferred actions. -Original Message- From: Konstantin Vlasenko [mailto:konstantin.vlase...@gmail.com] Sent: Thursday, October 22, 2009 1:00 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] How to get USERDOMAIN? Hello, I need to put usersomain into configuration file during the installation. How can I use %USERDOMAIN environment variable in the setup? Do we have some restrictions related to how and when we can use this environment variable? --- --- -- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- --- - Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- --- - Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free
Re: [WiX-users] How to change the installation to point to C:\
It's tricky. There's a product out there that belongs to a very big corporation (not Microsoft), that has severe complications when you tell it that it should be putting logs into a path with parenthesis. Because we need those logs, we needed to put our software into a path without parenthesis. On a 64-bit machine you have (x86) for 32-bit applications, so we break. We had to solve this. You can't just say C:\ because not all machines have C:\. You cannot take [SystemDrive] because those are often small system disks. So we take [ProgramFiles] and figure out its parent path with a CA from http://msiext.codeplex.com (SystemTools::Win32_GetParentDirectory). CustomAction Id=SetRootFolder Return=check Execute=firstSequence Property=ROOTFOLDER Value=[ProgramFilesFolder] / CustomAction Id=SetRootFolderParent Property=WIN32_DIRECTORY Value=[ROOTFOLDER] Execute=firstSequence / CustomAction Id=ResolveRootFolderParent BinaryKey=SystemTools DllEntry=Win32_GetParentDirectory Return=check Execute=firstSequence / CustomAction Id=SetRootFolderFromParent Property=ROOTFOLDER Value=[WIN32_PARENT_DIRECTORY] Execute=firstSequence / !-- set the install location from the previously recorded location in registry for upgrade -- CustomAction Id=SetInstallLocationFromInstalledProductLocation Return=check Execute=firstSequence Property=INSTALLLOCATION Value=[INSTALLEDPRODUCTLOCATION] / InstallExecuteSequence !-- set the root folder to the parent of [ProgramFilesFolder] -- Custom Action=SetRootFolder After=LaunchConditionsNOT ROOTFOLDER AND NOT INSTALLEDPRODUCTLOCATION/Custom Custom Action=SetRootFolderParent After=SetRootFolderNOT INSTALLEDPRODUCTLOCATION/Custom Custom Action=ResolveRootFolderParent After=SetRootFolderParentNOT INSTALLEDPRODUCTLOCATION/Custom Custom Action=SetRootFolderFromParent After=ResolveRootFolderParentWIN32_PARENT_DIRECTORY AND NOT INSTALLEDPRODUCTLOCATION/Custom !-- set the installation location from a previously installed version -- Custom Action=SetInstallLocationFromInstalledProductLocation After=SetMaintenanceINSTALLEDPRODUCTLOCATION/Custom /InstallExecuteSequence If your program files is D:\Program Files (x86), we get D:\, etc. Hope this helps, Cheers dB. dB. @ dblock.org Moscow|Geneva|Seattle|New York -Original Message- From: Anu Dev [mailto:queryl...@yahoo.com] Sent: Monday, November 02, 2009 9:49 AM To: WIX Subject: [WiX-users] How to change the installation to point to C:\ Hi How to change the installation to point to C drive, rather than to programfiles or any other directory Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Is there any easy way to do it. Regards Anweshi -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question on Listbox
This is working code for a list that already has an item.
LONG insert_index = index;
for each (const std::wstring name in names)
{
// the first record is inserted at index 2, there's at least one
default item in the view
MsiHandle hRec(MsiCreateRecord(4));
CHECK_WIN32_DWORD(MsiRecordSetString(hRec, 1, listbox.c_str()),
LMsiRecordSetString(1) failed); // Column1: Property
tied to the entry
CHECK_WIN32_DWORD(MsiRecordSetInteger(hRec, 2, insert_index),
MsiRecordSetInteger(2) failed); // Column2: Display
order of the item
CHECK_WIN32_DWORD(MsiRecordSetString(hRec, 3, name.c_str()),
MsiRecordSetString(3) failed); //Column3: Value to
set property to
CHECK_WIN32_DWORD(MsiRecordSetString(hRec, 4, name.c_str()),
LMsiRecordSetString(4) failed); //Column4: Display
text for item
CHECK_WIN32_DWORD(MsiViewModify(msiView, MSIMODIFY_INSERT_TEMPORARY,
hRec),
MsiViewModify failed);
insert_index ++;
}
From http://msiext.codeplex.com, look for SQLDMO_ListAvailableSQLServers.
dB. @ dblock.org
Moscow|Geneva|Seattle|New York
-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Tuesday, November 10, 2009 9:56 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Question on Listbox
Hi wix-users,
I want to use Listbox control to show some items on dialog. So I tried
the sample in WiX Tutorial 10.1
I changed the sample a little bit for passing build:
Add
Property Id=LISTBOXVALUES Value=1/
To sampleListbox.wxs. Otherwise there is always error in verbose log
that control needs a property link to it.
And
MSIDBERROR error;
hResult = WcaAddTempRecord (hTable, hColumns, LListBox, error, 0,
3, LLISTBOXVALUES, 1, LItem 1);
hResult = WcaAddTempRecord (hTable, hColumns, LListBox, error, 0,
3, LLISTBOXVALUES, 2, LItem 2);
hResult = WcaAddTempRecord (hTable, hColumns, LListBox, error, 0,
3, LLISTBOXVALUES, 3, LItem 3);
In the sample, there is no error parameter.
However, when I run the sample.msi, the listbox is empty.
The hResult has the type HRESULT. I want to show hResult value in a
messagebox. So I add code:
wchar_t buffer[10];
swprintf_s( buffer, 10, L%s, hResult );
ShowMessage.Append(buffer);
::MessageBoxW(NULL, ShowMessage, LFill Listbox, MB_OK);
And at last, the message shows (null).
What is wrong with WcaAddTempRecord ? How to add item to listbox
control?
Best regards,
Chunyan
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] SQLScript
Take a look at http://msiext.codeplex.com that has some wix extensions that might allow you to do all of what you want. Here's from the MSSQLDatabase sample: AppSecInc:MSSQLDatabaseConnection Id=LocalSQLServerConnectionDemoDatabase IpAddress=localhost Port=1433 Protocol=Tcp WindowsAuthentication=yes Database=[MSSQL_DATABASE_NAME] / Binary Id=ExecuteManyGoStatements_sql SourceFile=ExecuteManyGoStatements.sql / !-- files are always executed as is -- AppSecInc:ODBCExecuteFile Id=MSSQLDemoDatabase_CreateFileTable_NotEncoded ConnectionId=LocalSQLServerConnectionDemoDatabase ExecuteOnInstall=yes Filename=[#CreateFileTable_NotEncoded_sql] / !-- a binary sql that doesn't have properties and is not evaluated -- AppSecInc:ODBCExecuteBinary Id=MSSQLDemoDatabase_CreateBinaryTable_NotEncoded ConnectionId=LocalSQLServerConnectionDemoDatabase ExecuteOnInstall=yes EvaluateProperties=no BinaryId=CreateBinaryTable_NotEncoded_sql / Hope this helps, -dB. dB. @ dblock.org Moscow|Geneva|Seattle|New York -Original Message- From: Simon Topley [mailto:simon.top...@wallingfordsoftware.com] Sent: Friday, November 13, 2009 11:23 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] SQLScript There seems to be a huge overhead of running sql scripts from within windows installers so I'm playing with the idea of using skeleton databases stored in MDf/LDF files, I see there are sqlFileSpec elements that handle these but i can't get them towork yet, I'm not usinga script just 2 files and the database details in the parent sqldatabase element: SqlDatabase Id=SQLCreateMeterStreamDatabase2 Database=bob Server=[SQLSERVERNAME] Instance=[SQLINSTANCE] CreateOnInstall=yes DropOnUninstall=yes User=MySQLUser ContinueOnError=no SqlFileSpec Id=bob Filename=d:\bob.mdf/SqlFileSpec SqlLogFileSpec Id=bob1 Filename=d:\bob_log.ldf/SqlLogFileSpec /SqlDatabase Is this how they are expected to be used? -Original Message- From: Simon Topley Sent: 13 November 2009 15:07 To: 'wix-users@lists.sourceforge.net' Subject: RE: SQLScript h, it seems that you can run scripts that cahnge other databases outised of the sqldatabse element the scrit is inside of so maybe it'sa size issue. The script I'm trying to run is 16mb... about 300,000 lines of SQL. This takes about 3 minutes to run if you do it manually.. I've split the file up it 3mb files and they seem to work although the time required seems to be huge compared to just running the sql scripts from within SQL server management studio. is this a known issue? -Original Message- From: Simon Topley Sent: 13 November 2009 09:54 To: wix-users@lists.sourceforge.net Subject: SQLScript Hello again team, I've got another issue with some SQL scripts I'm trying to run. I have a large collection of scripts all of them work as they each refer to a specific databasehowever I have one big script that updates tables in multiple databases so I can't put it in one specific SqlDatabase element. any ideas? Or will this script need to be split into many parts? (that could be a bit of a nightmare) Simon Disclaimer: This electronic communication and its attachments may contain confidential, proprietary and/or legally privileged information which are for the sole use of the intended recipient. If you are not the intended recipient, any use, distribution, or reproduction of this communication is strictly prohibited and may be unlawful; please contact the sender and delete this communication. MWH does not warrant or make any representation regarding this transmission whatsoever nor does it warrant that it is free from viruses or defects, correct or reliable. MWH is not liable for any loss or damage that occurs as a result of this communication entering your computer network. The views expressed in this message are not necessarily those of MWH. This communication cannot form a binding agreement unless that is the express intent of the parties and they are authorized to make such an agreement. MWH reserves all intellectual property rights contained in this transmission. MWH reserves the right to monitor any electronic communication sent or received by its employees. This communication may come from a variety of legal entities within or associated with the MWH group. For a full list of details for these entities please see our website at www.mwhglobal.com. Where business communications relate to the MWH UK Limited entity, the registered office is Terriers House, 201 Amersham Rd, High Wycombe, HP13 5AJ Tel: 01494 526240 and the company is registered in England as registration number 01188070. Where business communications relate to the MWH Constructors Limited entity, the registered office is as above and the company is registered in England as registration number 04635724. Where business communications relate to the MWH Soft Limited entity, the registered office is as above and
[WiX-users] Two installers in one?
I have two applications, A and B. They are actually 99% the same assemblies, basically differing only in config files which dictate which classes obtain control (a very pluggable architecture). Thus we normally install all the assemblies, and pass the extra config file in the shortcut. They want two installers: 1) One that installs A only (same files, one shortcut) 2) One that installs A and B (same files, two shortcuts) If a person installs #1, then #2, the result should be #2. They don't want two separate copies of the same application. Experimenting shows that if I create two MSIs, I get two separate copies. Is it practical to include two sets of dialogs in an installer, enabling A and B by defining a property at the command line? We'll have to launch the installer from a bootstrapper anyhow, and thought that perhaps I could give the same MSI two faces though a property. Or is there a better way to approach this that I'm not aware of? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Question about ComponentRef in PatchFamily
I'm still trying to track down the PYRO0252 error from Pyro. I think it may be due to the ComponentRef element(s) in the PatchFamily element of the WSX source file. All the samples are very, very simple with just one component. My setup has many, many components. I found in the documentation of PatchFamily that I could use FeatureRef, which seemed to be the answer. I tried it, setting each FeatureRef's Id attribute to one of the names of the 3 features in the setup. However, that did not change the transform error at all. I couldn't really tell if that was proper usage from the documentation of FeatureRef, which seems to be more oriented towards using it in the source for a new setup, rather than a patch for pyro. Can someone show me an example of using FeatureRef elements to refer to the features in a setup, which would get pyro to look up all the components of those features? Otherwise, I'm afraid that I'm going to have to write a patch WSX that lists each and every one of those many, many components. Any help, suggestions or samples greatly appreciated. Thanks, John Media Cybernetics ## CONFIDENTIALITY NOTICE: This email transmission and its attachments contain confidential and proprietary information of Princeton Instruments, Acton Research, Media Cybernetics and their affiliates and is intended for the exclusive and confidential use of the intended recipient. Any use, dissemination, printing, or copying of this transmission and its attachment(s) is strictly prohibited. If you are not the intended recipient, please do not read, print, copy, distribute or take action in reliance upon this message. If you have received this in error, please notify the sender immediately by telephone or return email and promptly delete all copies of the original transmission and its attachments from your computer system. ### -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
