Hi all,
This should be a quick one,
I have an installer that installs my application and its support files.
Following a discussion earlier, it’s possible I may need to install some
additional add-on files. Here are my requirements…
1) The add-on files should be installed separately to
On 14/08/2012 17:01, Bob Arnson wrote:
> http://www.outercurve.org/Blogs/EntryId/58/WiX-joins-the-Outercurve-Foundation
>
> http://robmensching.com/blog/posts/2012/8/14/Outercurve-Foundation-and-WiX-toolset-together-at-last
I'm a bit surprised that the license change wasn't highlighted - it
seems
Thanks for the quick response, Bob.
Everything seems to be working correctly. I was missing a condition on a
few of these components.
We're in the middle of implementing this feature for dual ESRI 9 and 10
support so currently the mutually exclussive conditions I'm temporarily
using are just
On 14-Aug-12 11:59, MikeR wrote:
> using mutually exclusive component conditions based on detection of ESRI on
> the target system to avoid Windows Installer component rule issues.
If all the components have conditions, WiX throws that message as a
warning, which you could then suppress. If any of
Another workaround is to make the size of the checkbox control only as large as
the box itself so there's no grey background visible & use a separate text
control which can be set to have a transparent background. Breaks screen reader
compatibility though if you're willing to live with that.
Pa
In this case it is slightly different, when you run the SQL install it extracts
the setup to another folder (usually a guid folder name on drive c) it then
runs the install from that folder and that fails to find the config file as it
is not in the same folder.
Neil
-Original Message-
http://www.outercurve.org/Blogs/EntryId/58/WiX-joins-the-Outercurve-Foundation
http://robmensching.com/blog/posts/2012/8/14/Outercurve-Foundation-and-WiX-toolset-together-at-last
--
sig://boB
http://joyofsetup.com/
--
I'm performing testing for what will be involved in migrating our deployment
projects from WiX 3.5 to 3.6. I am currently testing with build 3.6.2928.0.
Things have gone well mostly but on one of our products I'm receiving errors
from light. Here is one example of the error.
error LGHT0369: Com
Both, I expect.
On Tue, Aug 14, 2012 at 8:42 AM, chroyer wrote:
> > If that does not work, we should add a way to get the full path to a
> > payload via the Burn variable mechanism. That won't help you in WiX v3.6
> > but we should be able to add it in WiX v3.7.
>
> This sounds familiar...see he
> If that does not work, we should add a way to get the full path to a
> payload via the Burn variable mechanism. That won't help you in WiX v3.6
> but we should be able to add it in WiX v3.7.
This sounds familiar...see here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-E
Thanks for evaluating that... I had other stuff to do, so I was not able to
check that yet. But I remember that I stumbled last days over the fact, that I
must provide the *full* path to the SQLServer installation programs. So it is
quite obvious, that it reacts the same way within a BA.
For no
Unfortunately is doesn’t work, SQL needs to full path. What we would need is a
burn variable point to the cache folder - I'll add a defect so it is not lost.
Neil
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 14 August 2012 15:40
To: General discussion for
If that does not work, we should add a way to get the full path to a
payload via the Burn variable mechanism. That won't help you in WiX v3.6
but we should be able to add it in WiX v3.7.
On Tue, Aug 14, 2012 at 2:37 AM, Christian Hausknecht <
chauskne...@beracom.de> wrote:
> Ah... you mean that o
ok, thanks for all your help
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-Patching-tp7579825p7579841.html
Sent from the wix-users mailing list archive at Nabble.com.
--
>Afraid that is a bug in windows installer (not WiX) as it doesn't set the
transparent windows style.
Poo. :(
OK, I guess the other way to look at it is then; why is the final page
background white (rather than grey)?
I notice that all other pages (End-User License Agreement, Destination
Folder,
I don't think so. When you remove the patch it reapplies the original version
which won't contain any of your modifications. You could set the patch to be
not removable if there's no other solution.
-Original Message-
From: Raymond Booth [mailto:raymond.bo...@gmail.com]
Sent: 14 August 20
Hi Peter
That appears to do the trick, thanks. I can't add conditions to the custom
actions but if I add this to my patch it doesn't apply any of the config
modification steps:
So - it must be one of the deferred custom actions... I will need to do
some further tests but its looking g
Yes, that's what I suspect.
The properties are declared in a CustomTable as follows;
SP_property_name
our_value
0
(as opposed to the usual elements. I think one of the custom
actions is resposible for copying these values in.)
We then reference these in wi
OK, it sounds like something unique to your installer, not usual MSI
properties. If you can't see how the action moves properties from table to
registry/xml files then you'll just have to stop the action occurring as you
say.
-Original Message-
From: Raymond Booth [mailto:raymond.bo...@gma
Hi Peter, thanks for your prompt reply.
i will explore the options you've suggested and see how that goes.
Regarding whether the properties are persisted - not sure if I fully
understand but basically the properties are held in a custom table and are
then either injected to Xmlfiles (e.g. web.con
Which is why I recommended you start with the tutorial rather than wade in knee
deep with the reference docs.
Have you looked at it yet?
Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the **
Afraid that is a bug in windows installer (not WiX) as it doesn't set the
transparent windows style. There are ways around it; I created my own dialog
and used a checkbox and separate label, not perfect but not so ugly. I have
also seen examples with a grey background bitmap.
Neil
-Origina
Using the latest version of WiX, I've added a check box to the ExitDialog
using:
This results in the check box with the text, but also an ugly large grey
rectangle behind the check box (while the property page is white).
There's a bug report about the check box background
"ExitDial
It wont work as my szLocalPath is a char and when I change it to LPCWSTR it
says it is not compatiable with a char coming from the function. I have the
MsiSetProperty working, I just don't know how to implement it in my Wix
project and use it in my other DLL functions.
-Original Message-
On 14/08/2012 11:00, Natalie Carr wrote:
> Have you any sample code for the WcaSetProperty, from looking online I'm not
> getting a clear picture (maybe it's just me..:()
I think you should be able to replace:
MsiSetProperty(hInstall, "ProductName", szLocalPath);
with:
WcaSetProperty(L"Product
Were the properties persisted during first time installation ? If not, they'd
be blank during maintenance. Ideally, you'd recover the property values in
the early stages of the (re)installation.
To answer your specific question, for the wix only option, you would add the
condition NOT PATCH to the
>Each of the WiX toolset web sites has at least one link to the bug
database. I like this one: http://wixtoolset.org/bugs. Click the "Add new"
link.
OK, done:
https://sourceforge.net/tracker/?func=detail&aid=3557290&group_id=105970&ati
d=642714
Dave
---
I don't think I can use WcaSetProperty as my function Orc_Get_Product_Name
is returning a char
-Original Message-
From: Bruce Cran [mailto:br...@cran.org.uk]
Sent: 14 August 2012 10:38
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Wix C++ variables
On 14/08/2012 09:48, Nata
Hi
We are working within a constrained environment which defines a set of
custom actions and custom tables for a deployment framework using wix.
I am looking at creating simple patches for MSIs which will ONLY copy
modified files or new files to servers as some of the MSIs are reasonably
comple
Have you any sample code for the WcaSetProperty, from looking online I'm not
getting a clear picture (maybe it's just me..:()
My custom action gets the product name, how can I use this to make it my
product name in my wix project? I also have to use it in many other of my
functions, have you any id
On 14/08/2012 09:48, Natalie Carr wrote:
> MsiSetProperty(hInstall, "ProductName", szLocalPath);
You might want to use WcaSetProperty (and the other Wca* functions)
instead since they're a bit simpler.
--
Bruce Cran
-
Ah... you mean that one should only provide a "relative" path like this:
/CONFIGURATIONFILE=config.ini
? That sounds promising... I will try and report about it later on :-)
Thx
-Ursprüngliche Nachricht-
Von: Neil Sleightholm [mailto:n...@x2systems.com]
Gesendet: Dienstag, 14. August
Yes, a property is the easiest way to share data between an immediate CA and
the wix code.
It's also possible to temporarily alter the MSI database at install time if
you want Windows Installer to alter the system state for you, such as adding
or changing rows in the registry table.
http://www.jo
You won't need a property because a directory ID is a kind of property
already.
The directory structure has to be defined before you can reference it. The
wix help has a section on how this looks
http://wix.sourceforge.net/manual-wix3/add_a_file.htm
-Original Message-
From: Francis Louis [
I have to admit I haven't tried it yet (although probably will be doing exactly
the same thing later today). Have you tried removing the path from the
/CONFIGURATIONFILE parameter?
Neil
-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de]
Sent: 14 August 2012 0
Thank you for all your help and suggestions, I'm going to implement a custom
dialog to my wix project and use custom actions to do everything else that I
need. Hope it works..:)
Thanks
Natalie
-Original Message-
From: Bruce Cran [mailto:br...@cran.org.uk]
Sent: 10 August 2012 17:49
To: G
Is there a way to use certain variables in your wix code and your c++ dll
functions?
extern "C" UINT __stdcall RegProductName(MSIHANDLE hInstall)
{
HRESULT hr = S_OK;
UINT er = ERROR_SUCCESS;
char szLocalPath[MAX_PATH];
hr = WcaInitialize(hInstall, "RegProductName");
ExitOnFailure(hr, "Failed
Hi Crhistoph,
Did you ever get to the bottom of this? I have a similar issue whereby a
patch is modifying my config files with invalid (blank) values when I
actually only want the patch to copy any modified files...
Thanks
--
View this message in context:
http://windows-installer-xml-wix-too
Thank you for the update,
I can verify that the command line dump is being done in the BA (in the RC
build).
Dave, do you know if the issue about the command line dump in the log is
planned to be fixed before IR (or if there is a way to turn off the dump
entirely from the BA)? Is there a bug repo
Thank you for your hint, but could you give me an example, how to express that
in WiX?
I would write this as naïve attempt:
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lis
You should be able to do this using the PayLoad element as a child of your
ExePackage element.
Neil
-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de]
Sent: 13 August 2012 11:09
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to bundle a configura
41 matches
Mail list logo
