Re: [WiX-users] Dealing with ICE48 warning
Open the MSI up in Orca or Inst Ed and you might find that the directory IDs in the merge modules have had Guids added to them. Ids in modules are modularised to avoid name clashes. -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: 04 October 2011 23:14 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Hi Peter... It was a bit of a nuisance to get a verbose log out of the wmi install, so I've been comparing the logs from the builds using the type 51 and type 35 work-arounds vs the builds just ignoring the error. The differences I see is that TARGETDIR=my custom value in the early phases of all logs, but in the ones with the type 51 and type 35 work-arounds TARGETDIR just doesn't appear to be used in coming up with the final destination for some of the merge modules. Why? I don't know. E.g. Action ended 17:14:01: INSTALL. Return value 1. Property(C): Binaries = C:\OurPath\Binaries\ Property(C): TARGETDIR = C:\OurPath\ Property(C): ASP = C:\OurPath\ASP\ Property(C): Ptt = C:\OurPath\Ptt\ In the log when I just ignore the warning compared to Action ended 15:27:12: INSTALL. Return value 1. Property(S): Binaries = C:\OurPath\Binaries\ Property(S): TARGETDIR = C:\OurPath\ Property(S): ASP = C:\ASP\ Property(S): Ptt = C:\OurPath\Ptt\ In the log when I'm trying one of the other approaches. On your other suggestions, I found a few things: 1) Can't put a type 35 anywhere before after CostFinalize. It throws an error at any stage before. 2) I tried putting my own directory level (e.g. Directory Id=PRODUCTDIR Name=Ice48 Stub.../Directory) just inside of TARGETDIR, but using a type 51 CA Before=CostInitialize still had the same problem of pretty random directory placement. Specifically, it put things in C:\Ice48 Stub\... 3) Same as #2 but going back to type 35 after CostFinalize appeared to do the trick. Things got installed where I expected when running the msi locally. Thanks Mark -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Tuesday, October 04, 2011 12:10 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning The subtle differences between the two are a bit beyond me since I've never needed to distinguish between them. There's a list of considerations at http://msdn.microsoft.com/en-us/library/aa367852%28v=VS.85%29.aspx which may answer your questions. It's worth trawling through the MSDN. For us, setting the property before CostInitialize has always worked. We use a setproperty action but setdirectory would work and should make slightly more sense. It probably helps matters that we don't use merge modules nor MSI UI so the directories are determined before the MSI even starts up and don't change during installation. There are setproperty and setdirectory elements in wix3.5 to more concisely express these kinds of custom action. The remote/local difference is somewhat strange, I agree, but I'm sure there's a good reason for it. A comparison of verbose logs may give you a clue. -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: 04 October 2011 16:57 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Thanks, Peter... I can give it a shot. I was a bit perplexed when I found that the Type 51 approach worked as I expected when it installed remotely through WMI, as opposed to being run locally on the computer. By and large our ops team uses a utility to manage the farm and the installs are run remotely; the difference in behavior just annoyed me. Just out of curiosity, if I switch to using INSTALLDIR instead, does it make a difference whether I use the Type 51 or the type 35 custom actions to set it? And at which phase? I googled around and found a few posts advocating the type 51 approach Before CostFinalize, now some saying type 35 after. I'm wondering if just avoiding the specific case of TARGETDIR would push one way or the other? Thanks Mark -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Tuesday, October 04, 2011 11:45 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning I've just looked back at your original post which is how to avoid ICE48 errors. The ICE48 error is issued because ... ICE48 checks for directories that are hard-coded to local paths in the Property table. (From http://msdn.microsoft.com/en-us/library/windows/desktop/aa368977%28v=vs.85%29 .aspx) ICE48 is objecting to the use of C:\OurPath\ TARGETDIR is by default set to the root of the drive with the most free space (I think). Some of the other components, probably in the merge modules, might have directory paths rooted under a well known directory property like ProgramFilesFolder which overrides the TARGETDIR, even
[WiX-users] Custom themed bootstrapper
After the discovery of the variable WixStdbaThemeXml from this mailing list I set about looking at my own corporate theme. In my main wxs I set these two variables: WixVariable Id=WixStdbaLogo Value=Background.bmp / WixVariable Id=WixStdbaThemeXml Value=MytfTheme.xml / My objective is really to set a background image and have the other items overlayed, looking at thmutil.xds I can define my window: Window Width=600 Height=400 HexStyle=100a FontId=0[WixBundleName] Setup/Window And then I thought the only place really to define the background image was against the page: Page Name=Install Image X=0 Y=0 Width=600 Height=400 ImageFile=Logo.png / Richedit Name=EulaRichedit X=11 Y=100 Width=-11 Height=-70 FontId=0 / Checkbox Name=EulaAcceptCheckbox X=-11 Y=-41 Width=246 Height=17 TabStop=yes FontId=3I amp;agree to the license terms and conditions/Checkbox Button Name=OptionsButton X=-171 Y=-11 Width=75 Height=23 TabStop=yes FontId=0 HideWhenDisabled=yesamp;Options/Button Button Name=InstallButton X=-91 Y=-11 Width=75 Height=23 TabStop=yes FontId=0amp;Install/Button Button Name=WelcomeCancelButton X=-11 Y=-11 Width=75 Height=23 TabStop=yes FontId=0amp;Close/Button /Page Compiled. Issue 1: The length of my rtf license is just over a page.when the bootstrapper first loads, the vertical scroll bar is not visible, the license contents are visible..only when I mouse over the hidden scroll bar does it appear. Issue 2: Regardless of the font or the creation of a new font Id, I don't seem to be able to control the text of the EulaRichEdit data. Within my main WXS I defined WixStdbaLicenseRtf to point to my Eula file, only if I change the font size directly in my external rtf file.OK...that's not too much of a problem.but now I need a coloured background and white text. (Product colours are dark background and white text) I've tried defining a new font Id and setting the foreground and the background.didn't seem to help. My second idea was to change the external rtf file instead, I if I use Microsoft Word to create the rtfin Microsoft Word it looks OK.load the same rtf in WordPad there is no colorizationcompile it into the bootstrapper and still no colour. Where am I going wrong? Regards Neil -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
I understand maintaining the customers data but isn't the goal here to remove it? Which I agree is against the rules normally but it would appear that is what is wanted... Did I miss something? Jon -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Tuesday, October 04, 2011 10:23 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows. On 04-Oct-11 15:29, McCain, Jon wrote: If that is the case then you shouldn't need to worry about being a good install writer and just whack the folder or its subfolders that you don't control with your install. Of course you should. If there's a failure or other rollback, the user's data is gone. -- sig://boB http://joyofsetup.com/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Dealing with ICE48 warning
Okay, I'm looking at the installer in Orca. I see that all the directories declared in the modules have the package guid appended to them (e.g. ASPdirectory0.1A39512D_87E4_4FD4_AEFC_88DE0E1C2536), but that's the same for those that went to the right place and those that went somewhere else. A lot of the binary modules had a Directory Id=INSTALLDIR inside the module's Directory Id=TARGETDIR, so all those INSTALLDIRs are differentiated by the guid... Thanks Mark -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Wednesday, October 05, 2011 4:38 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Open the MSI up in Orca or Inst Ed and you might find that the directory IDs in the merge modules have had Guids added to them. Ids in modules are modularised to avoid name clashes. -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: 04 October 2011 23:14 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Hi Peter... It was a bit of a nuisance to get a verbose log out of the wmi install, so I've been comparing the logs from the builds using the type 51 and type 35 work-arounds vs the builds just ignoring the error. The differences I see is that TARGETDIR=my custom value in the early phases of all logs, but in the ones with the type 51 and type 35 work-arounds TARGETDIR just doesn't appear to be used in coming up with the final destination for some of the merge modules. Why? I don't know. E.g. Action ended 17:14:01: INSTALL. Return value 1. Property(C): Binaries = C:\OurPath\Binaries\ Property(C): TARGETDIR = C:\OurPath\ Property(C): ASP = C:\OurPath\ASP\ Property(C): Ptt = C:\OurPath\Ptt\ In the log when I just ignore the warning compared to Action ended 15:27:12: INSTALL. Return value 1. Property(S): Binaries = C:\OurPath\Binaries\ Property(S): TARGETDIR = C:\OurPath\ Property(S): ASP = C:\ASP\ Property(S): Ptt = C:\OurPath\Ptt\ In the log when I'm trying one of the other approaches. On your other suggestions, I found a few things: 1) Can't put a type 35 anywhere before after CostFinalize. It throws an error at any stage before. 2) I tried putting my own directory level (e.g. Directory Id=PRODUCTDIR Name=Ice48 Stub.../Directory) just inside of TARGETDIR, but using a type 51 CA Before=CostInitialize still had the same problem of pretty random directory placement. Specifically, it put things in C:\Ice48 Stub\... 3) Same as #2 but going back to type 35 after CostFinalize appeared to do the trick. Things got installed where I expected when running the msi locally. Thanks Mark -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Tuesday, October 04, 2011 12:10 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning The subtle differences between the two are a bit beyond me since I've never needed to distinguish between them. There's a list of considerations at http://msdn.microsoft.com/en-us/library/aa367852%28v=VS.85%29.aspx which may answer your questions. It's worth trawling through the MSDN. For us, setting the property before CostInitialize has always worked. We use a setproperty action but setdirectory would work and should make slightly more sense. It probably helps matters that we don't use merge modules nor MSI UI so the directories are determined before the MSI even starts up and don't change during installation. There are setproperty and setdirectory elements in wix3.5 to more concisely express these kinds of custom action. The remote/local difference is somewhat strange, I agree, but I'm sure there's a good reason for it. A comparison of verbose logs may give you a clue. -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: 04 October 2011 16:57 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Thanks, Peter... I can give it a shot. I was a bit perplexed when I found that the Type 51 approach worked as I expected when it installed remotely through WMI, as opposed to being run locally on the computer. By and large our ops team uses a utility to manage the farm and the installs are run remotely; the difference in behavior just annoyed me. Just out of curiosity, if I switch to using INSTALLDIR instead, does it make a difference whether I use the Type 51 or the type 35 custom actions to set it? And at which phase? I googled around and found a few posts advocating the type 51 approach Before CostFinalize, now some saying type 35 after. I'm wondering if just avoiding the specific case of TARGETDIR would push one way or the other? Thanks Mark -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Tuesday, October 04, 2011 11:45 AM To: General discussion for
Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
The scenario I am trying to handle is the cancel during uninstall. If I were to just bomb the folder the rollback wouldn't work and it would delete the folder anyway. I am going to try and see if I can pressure the team into using 3.6. Don't know if it will be an issue or not. Initially they said no but maybe I can get them to budge. --Brian -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: Wednesday, October 05, 2011 8:10 AM To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows. I understand maintaining the customers data but isn't the goal here to remove it? Which I agree is against the rules normally but it would appear that is what is wanted... Did I miss something? Jon -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Tuesday, October 04, 2011 10:23 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows. On 04-Oct-11 15:29, McCain, Jon wrote: If that is the case then you shouldn't need to worry about being a good install writer and just whack the folder or its subfolders that you don't control with your install. Of course you should. If there's a failure or other rollback, the user's data is gone. -- sig://boB http://joyofsetup.com/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message (including any attachments) contains confidential and privileged information intended for a specific purpose, and is protected by law. If you are not the intended recipient, you must delete this message and any attachments. You are hereby notified that any disclosure, copying, or distribution of this message, or any attachments, or the taking of any action based on it, is strictly prohibited. Opinions, conclusions, and other information in this message that do not relate to the official business of API Healthcare Corporation (API Healthcare) shall be understood as neither given nor endorsed by API Healthcare. API Healthcare Corporation 1550 Innovation Way Hartford, WI 53027 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Custom Action Fails when Inserting TemoporaryRows.
I'm not certain what your exact problem is, but looking at the schema
for the remove file table leads me to believe you are missing fields
that are not nullable.
I've used:
const string REMOVEFILES_VIEW = @SELECT `FileKey`, `Component_`,
`FileName`, `DirProperty`, `InstallMode` FROM `RemoveFile`;
...
var foldersToRemove = Directory.GetDirectories(dataFolder,
@*, SearchOption.AllDirectories);
var view = session.Database.OpenView(REMOVEFILES_VIEW,
null);
view.Execute();
foreach (var folderToRemove in foldersToRemove)
{
var guid = Guid.NewGuid();
string folderProperty = string.Format(@dir_{0},
guid.ToString(@N));
string fileKey = string.Format(@file_{0},
guid.ToString(@N));
string folderKey = string.Format(@folder_{0},
guid.ToString(@N));
session[folderProperty] = folderToRemove + @\;
// Remove all the files
var record = session.Database.CreateRecord(5);
session.Log(@FileKey= + fileKey);
record.SetString(1, fileKey);
record.SetString(2, Component Name that will always be
installed);
record.SetString(3, *.*);
record.SetString(4, folderProperty);
record.SetInteger(5,
(int)eInstalMode.msidbRemoveFileInstallModeOnRemove);
view.Modify(ViewModifyMode.InsertTemporary, record);
// and remove the folder
record = session.Database.CreateRecord(5);
record.SetString(1, folderKey);
record.SetString(2, Component Name that will always be
installed);
record.SetString(3, null);
record.SetString(4, folderProperty);
record.SetInteger(5,
(int)eInstalMode.msidbRemoveFileInstallModeOnRemove);
view.Modify(ViewModifyMode.InsertTemporary, record);
}
view.Close();
...
with success. Note, I am recursively adding all files and folders from
my base folder to be removed.
Jacob
-Original Message-
From: Brian Lemke [mailto:brian.le...@apihealthcare.com]
Sent: Wednesday, October 05, 2011 9:48 AM
To: General discussion for Windows Installer XMLtoolset.
Subject: Re: [WiX-users] C# Custom Action Fails when Inserting
TemoporaryRows.
The scenario I am trying to handle is the cancel during uninstall. If
I were to just bomb the folder the rollback wouldn't work and it would
delete the folder anyway. I am going to try and see if I can pressure
the team into using 3.6. Don't know if it will be an issue or not.
Initially they said no but maybe I can get them to budge.
--Brian
-Original Message-
From: McCain, Jon [mailto:jon.mcc...@inin.com]
Sent: Wednesday, October 05, 2011 8:10 AM
To: General discussion for Windows Installer XML toolset.
Cc: McCain, Jon
Subject: Re: [WiX-users] C# Custom Action Fails when Inserting
Temoporary Rows.
I understand maintaining the customers data but isn't the goal here to
remove it? Which I agree is against the rules normally but it would
appear that is what is wanted... Did I miss something?
Jon
-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent: Tuesday, October 04, 2011 10:23 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] C# Custom Action Fails when Inserting
Temoporary Rows.
On 04-Oct-11 15:29, McCain, Jon wrote:
If that is the case then you shouldn't need to worry about being a
good install writer and just whack the folder or its subfolders that you
don't control with your install.
Of course you should. If there's a failure or other rollback, the user's
data is gone.
--
sig://boB
http://joyofsetup.com/
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
This message (including any attachments) contains confidential and
privileged information
[WiX-users] Incremental vs. cumulative patches (.msp)
Hello I am new to the world of msi and started learning about patching. I learned that you can have incremental as well as cumulative patches. For example, I can have a patch 1.2 which will update 1.0 or 1.1 to 1.2. This will be cumulative, but if I have incremental patches, they will be 1.0 to 1.1 andthen another patch for 1.1 to 1.2. Are there any benefits or advantages in using one or the other? Which one is quicker and which one has more risks? Thanks -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Managed BA can't parse unknown args with spaces successfully
Hi, Run bundle with the following command line args: setup.exe /q /INSTALLDIR=c:\dfds safds \sadfds /SomeOtherParam Managed BA receives the following string for command line args: /INSTALLDIR=c:\dfds safds \sadfds /SomeOtherParam The space in the path causes invalid argument parsing in the BA. I am using build #2019 and this issue is only in the managed BA not in the native one. A smiliar bug was filed previously (ID: 3158619, https://sourceforge.net/tracker/index.php?func=detailaid=3158619group_id=105970atid=642714), but according to the comment there this should be fixed. What build was this fixed in if it was? What is a good way to look for this kind of information? Thanks, Shruthi -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Managed-BA-can-t-parse-unknown-args-with-spaces-successfully-tp6863158p6863158.html Sent from the wix-users mailing list archive at Nabble.com. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] LaunchCondition question
Hi all, My installer has several launch conditions setup. It works at it should, checking one condition at a time, and giving the error message configured. I was wondering if there is any way to run them all, instead of sequentially, and show all the non-compliant messages. Thanks! Caio -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] LaunchCondition question
Pretty annoying, heh? Out of the box? No. Some custom tables and custom action / custom dialog work? Sure. Here's an article describing something I created back in 2006 for a former employer: http://blog.iswix.com/2006/07/short-comings-of-launchconditions.html From: Caio Monteiro cmonte...@modulo.com.br Sent: Wednesday, October 05, 2011 3:49 PM To: wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net Subject: [WiX-users] LaunchCondition question Hi all, My installer has several launch conditions setup. It works at it should, checking one condition at a time, and giving the error message configured. I was wondering if there is any way to run them all, instead of sequentially, and show all the non-compliant messages. Thanks! Caio -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] majorupgrade when signing and merge
Hi, I have an MSI installer built few months ago. It used to work fine during MajorUpgrade. Today I signed the MSI with code certificate and also added one Merge Module. However now my MSI file gets installed as a new product and does not upgrade the existing installation as it used to do. As usual I only changed ProductCode and CurrentVersion properties. Does digital signing or adding merge module makes the MSI look like a new product? What else could be the case? Thanks, Martin -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] majorupgrade when signing and merge
Hi Martin, Did you change the Product ID and the version number? Both of those have to change to be called a major upgrade. http://wix.sourceforge.net/manual-wix3/major_upgrade.htm shows how to integrate a major upgrade into your .WXS file. John Wintellect http://www.wintellect.com +1-877-968-5528 -Original Message- From: Martin Kulov [mailto:mar...@kulov.net] Sent: Wednesday, October 05, 2011 2:59 PM To: wix-users Subject: [WiX-users] majorupgrade when signing and merge Hi, I have an MSI installer built few months ago. It used to work fine during MajorUpgrade. Today I signed the MSI with code certificate and also added one Merge Module. However now my MSI file gets installed as a new product and does not upgrade the existing installation as it used to do. As usual I only changed ProductCode and CurrentVersion properties. Does digital signing or adding merge module makes the MSI look like a new product? What else could be the case? Thanks, Martin -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
