I have to create a package with three features FeatureA, FeatureB FeatureC.
The Feature selection is a RadioButtonGroup with selectable options being:
option 1 : FeatureA,FeatureB FeatureC.
option 2 : FeatureB
option 3 : FeatureC
I have created a Custom Dialog:
Property Id=ADDLOCAL Value=ALL/
Hi Rob,
I looked at the Directory table of the resulting MSI with SuperOrca
and MergeRedirectFolder's Directory_Parent = myProd.
The problem was the sample I sent you did not replicate a bug that I
had in the real merge module. I prematurely closed a directory.
But now that we are on the topic,
I guess this says a lot about my WIX authoring skills :) I'll provide as
much info as I can.
Thanks,
Francesc
On Sun, Jun 6, 2010 at 5:32 PM, Rob Mensching r...@robmensching.com wrote:
Wow, haven't seen a bug like that in a very long time. Can you open a bug
and provide as much information
Hi, is it any way possible possible to do a minor upgrade and automatically
remove related products in the background? I want to keep the same product
code basically.
The scenario is I made some bug fixes to our product that dont seem to warrant
a major upgrade. My version numbers are
On 6/7/2010 8:10 AM, warne warne wrote:
Hi, is it any way possible possible to do a minor upgrade and automatically
remove related products in the background?
No, that's a major upgrade.
The scenario is I made some bug fixes to our product that dont seem to
warrant a major upgrade. My
Hi All,
I'm trying to attain unattended installation using WIX, where I need to read
some parameters from .ini file and set the properties to select only some
features on installation.
I have tried setting Properties using both MsiSetProperty and WcaSetProperty
as mentioned below:
The answer would be no. Changing the Product Code means it's not a Minor
Upgrade, it's a Major Upgrade. See -
http://msdn.microsoft.com/en-us/library/aa370579.aspx
You could deploy the changes as an MSP rather than an MSI.
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141
On 6/7/2010 2:48 AM, Bijay Agarwal wrote:
Property Id=ADDLOCAL Value=ALL/
The MSI doc says you should not set ADDLOCAL to all. Use AddLocal in
Publish elements instead. Then check a verbose log to see which features
are being installed.
--
sig://boB
http://joyofsetup.com/
When are you scheduling the RemoveExistingProducts for the upgrade? I was
seeing this problem as well. I am using the MajorUpgrade element and had is
scheduled for afterInstallExecute. I moved it to afterInstallValidate
(which is the default) and my upgrade worked.
Not sure if it will work
Follow the Property value in a verbose log file. That'll tell you what is
going on.
On Mon, Jun 7, 2010 at 5:19 AM, vijay chander vijaychander2...@gmail.comwrote:
Hi All,
I'm trying to attain unattended installation using WIX, where I need to
read
some parameters from .ini file and set the
I think it says more about our coding skills. wink/
On Mon, Jun 7, 2010 at 3:58 AM, Francesc Castells
fcaste...@dgtexperts.comwrote:
I guess this says a lot about my WIX authoring skills :) I'll provide as
much info as I can.
Thanks,
Francesc
On Sun, Jun 6, 2010 at 5:32 PM, Rob Mensching
At this point, it sounds like a bug.
On Thu, Jun 3, 2010 at 7:23 PM, Chong Li chon...@microsoft.com wrote:
I just tried 3.5.1728.0 downloaded from
http://wix.sourceforge.net/releases/
But it still didn't work. The webaddress with the specified ip and port
already exists but it seems that
I'm hitting some issues with localization.
I created error 25001 as follows and called MsiProcessMessage from a custom
action:
UI
Error Id=25001!(loc.Error_25001)/Error
/UI
And created a file named wix_eng.wxl with the following content
?xml version=1.0 encoding=utf-8?
WixLocalization
In other words, Minor Upgrades are not allowed to RemoveExistingProducts. You
need a Major Upgrade to do that (requiring a change in ProductCode).
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider
Bingo! Thanks John the issue is resolved. I had RemoveExistingProducts
After=InstallInitialize, now with InstallValidate upgrade works. Thanks a
lot!
-Original Message-
From: John L Krupka [mailto:john.kru...@nmwco.com]
Sent: Monday, June 07, 2010 18:12
To:
In our project using light we reference two localization files:
CUSTOM_WixUI_en-us.wxl and WixUI_en-us.wxl
In most cases we create a custom localization and place them in the
CUSTOM_WixUI_en-us.xml and then reference them when necessary.
In this instance I want to modify the text of an error
Glad it worked for you. I am not so sure I am convinced that there is not a
bug as it should work with the different schedule types or a compiler should
be thrown for invalid ones.
If it is a bug, at least there are options.
--
View this message in context:
They have the same GUID because they both are related to the same Merge
Module (the guid is your merge module's guid).
The warning is ignorable because the two properties don't depend on each
other. Mergemod.dll from Microsoft's own SDK is what creates those actions,
and I don't know of a way to
Thanks Sascha!
So far we had 40 users with vcredist_x86.exe install problem. All Windows 7 but
not only 64 bit. It is interesting, but not yet enlightening to me, how some
issues got solved. Quite a few users run vcredist_x86.exe manually, with full
UI. Normally it is run silently by our setup
See
http://blogs.msdn.com/b/heaths/archive/2006/10/25/how-windows-installer-uses
-languages.aspx for a really good analysis on how these two values are used.
packa...@languages becomes the PID_TEMPLATE value that Heath mentions
(defaults to the produ...@language value), while the produ...@language
When and in which table(s) is your DLL sequenced? What does the installation
log say?
-Original Message-
From: vijay chander [mailto:vijaychander2...@gmail.com]
Sent: Monday, June 07, 2010 5:20 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Can we control registration of
Please ignore the previous mail about localization issues. I was using
light.exe from Wix V2.0, so I was not seeing localized strings. Once I
started using Wix 3.0 toolset, I'm able to see the localized texts. Thanks
for the help folks! Thanks Blair and Nick!
On Mon, Jun 7, 2010 at 7:57 AM,
I don't know if it as simple as removing the quotes or not:
UI
Error Id=25001!(loc.Error_25001)/Error
/UI
Also, your light.exe commandline looks more like WiX v2 instead of WiX v3.
-Original Message-
From: Pratapa Reddy Sanaga [mailto:pratap.san...@gmail.com]
Sent: Monday, June
Ok, thanks all for clarifying anyway. cheers.
_
http://clk.atdmt.com/UKM/go/195013117/direct/01/
--
ThinkGeek and
Hi,
Does Wix 2.0 have support for creating transforms? I see that Torch tool has
been introduced in Wix 3.0. How did Wix 2.0 users create transforms?
Also, !(loc.StringIdForError) format for custom error message localization
doesn't work when the MSI is created with Wix 2.0 tools. Maybe Wix 2.0
Hi I am mahesh, I am working on a Wix project but I am not able
to add schedule tasks to it.
Here is my code. Please help me out. here is my code,
CustomAction
Id=CreateScheduledTask
Return=check
Directory=ProgramFilesFolder
ExeCommand= schtasks /create
The issue was that I was using Wix V2 version of light.exe. Could you please
provide me a pointer to the syntax for doing the same with Wix v2 version?
I'm guessing there should have been some way to do the string localization
with V2 too...
On Mon, Jun 7, 2010 at 9:56 AM, Blair os...@live.com
It is extremely similar but the XML namespaces changed between v2 and v3,
making identical sources incompatible.
-Original Message-
From: Pratapa Reddy Sanaga [mailto:pratap.san...@gmail.com]
Sent: Monday, June 07, 2010 1:00 PM
To: General discussion for Windows Installer XML toolset.
In v2 it was $(loc.StringId). That was changed to !(loc.StringId) in v3
(IMHO to make it more obvious when the replacement happens [precompile vs.
late-stage linking/binding]).
V2 users must use MSI-SDK tools for creating transforms. See MSDN for
examples.
-Original Message-
From:
I see that the source tree moved from SourceForge to codeplex YESTERDAY. But
on the 3.5 stuff is on codeplex. Where did the 'stable' release of 3.0 go?
Today I couldn't load my wix project in VS2008 for some reason. I got a
message like this:
I think the problem is that you are not specifying the full path to
schtasks.
I do something similar for a non-public application in the following
way:
!-- Embed a copy of schtasks --
Binary Id=schtasks
SourceFile=$(var.ProjectDir)\Support\schtasks.exe /
CustomAction Id=CreateMaintenanceTask
If the DLLs go into the GAC then they must be signed.
Jacques
On Thu, Jun 3, 2010 at 10:04 AM, Pally Sandher pally.sand...@iesve.comwrote:
Sign your MSI to make the UAC prompts look prettier.
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141
V3.0 is on the main Codeplex site: http://wix.codeplex.com or here:
http://wix.sourceforge.net/releases/3.0.5419.0/
This is in the readme.htm that is on the SourceForge site.
Neil
-Original Message-
From: gapearce [mailto:mr_gapea...@yahoo.com]
Sent: 07 June 2010 22:02
To:
Thanks Neil - I found it.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Re-What-happened-to-3-0-tp5151154p5151179.html
Sent from the wix-users mailing list archive at Nabble.com.
Somehow I broke my VS2008 project and I can't load my wixproj any more. I'm
getting the following error:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/file/n5151101/error.jpg
Reinstalling 3.0 didn't help. Any suggestions on how to fix this?
--
View this message in context:
If the issue is that the program says it's not signed, then you can sign it,
and if you're into signing then sign everything with your own certificate,
which I assume is A's, including the MSI file.
Can company B sign the content, even after *.msi is created / delivered ?
Well yes, but
I have a C++ dependency issue that I'm trying to figure out.
A.DLL depends on: ( compiled by us using VS2008 )
MSCOREE.dll
KERNEL32.dll
MSVCM90.DLL 9.0.21022.8
MSVCR90.dll 9.0.21022.8
MSVCP90.dll 9.0.21022.8
B.DLL
B.DLL depends on: ( compiled by third party using
To make things even more interesting, sometimes there are type library and COM
dependencies. Also some DLL's could be delay-loaded or dynamically linked to.
The Sysinternals depends tool is a great help. It is best just to bootstrap
the C++ runtime (.MSI) packages. Avoid the merge modules
I have the following error (treating warnings as errors, warning level
pedantic):
ICE48: Directory 'INSTALLDIR' appears to be hardcoded in the property table
to a local drive.
However INSTALLDIR is a property that I expect to always pass in to msiexec
at install time. How can I either fix the
Have you used fuslogvw (the fusion log viewer) to try to see what's going
on, or the sxstrace tool?
I'd recommend looking at the output of sxstrace and/or fuslogvw to see
what's happening. I'm pretty sure it'll be enlightening.
Kelly
Christopher Painter chr...@deploymentengineering.com
Isn't depends simply busted for WinSxS?
I assume the application doesn't run? Just in case, if those A.DLL and B.DLL
are custom actions this won't work - you have to install the CRTs outside of
the MSI (something about loading per-process).
dB. @ dblock.org
Moscow|Geneva|Seattle|New York
On 6/7/2010 12:13 PM, pmarkey wrote:
Is there a way to ensure the system will use the custom version of Error1730
instead of the default version found in the WixUI_en-us.wxl file without
modifying the default version directly?
Just include it without the Overridable attribute; it will
On 6/7/2010 8:58 PM, Manuel Aude wrote:
Property Id=DOTNET35SP1INSTSomeDir\dotnetfx35.exe/Property
That won't work -- you can't install the .NET Framework as a custom action.
--
sig://boB
http://joyofsetup.com/
Don't put anything in the Property table. If you're always going to pass it
in, you don't need it in the Property table.
On Mon, Jun 7, 2010 at 5:49 PM, Andrew Hammond
andrew.george.hamm...@gmail.com wrote:
I have the following error (treating warnings as errors, warning level
pedantic):
Yes, but nothing free I'm aware of :)
We use IRMakeBootstrap that is a component of MSI Factory
(http://www.indigorose.com/products/msi-factory/) - you don't need to
use MSI Factory, the bootstrapper is a self-contained component that
can be integrated into any build process. Unfortunately an MSI
Oh I see. But could you please tell me if there's a way to do it with WiX,
then?
Thanks
--
On 6/7/2010 8:58 PM, Manuel Aude wrote:
Property Id=DOTNET35SP1INSTSomeDir\dotnetfx35.exe/Property
That won't work -- you can't install the .NET Framework as a custom action.
--
Hi,
I'm using the following code snippet inside a function to set the property
inside COM DLL:
hr = WcaSetIntProperty(LPROPNAME, 1);
ExitOnFailure(hr, Failed to set PROPNAME property value);
I'm calling this function from the WIX code using Custom Action DLL Entry.
Snippet:
Property Id
47 matches
Mail list logo
