Hello WiX Community,
I hope you can help us with an error message we do not understand. J
Scenario:
* We want to create the empty folder %AppData%\X\Y.
Current solution:
Directory Id=AppDataFolder
Directory Id=X Name=X
Directory Id=Y Name=Y /
to not bother looking. On the other hand, your
suggestion can't do any harm; feel free to contribute the change.
-Original Message-
From: Markus Karg [mailto:k...@quipsy.de]
Sent: Thursday, April 15, 2010 9:43 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re
If it is really so frequently asked, maybe it would be a good idea to
post the date in the WiX FAQ http://wix.sourceforge.net/faq.html or on
the WiX web site's front page http://wix.sourceforge.net/ to prevent
dumb people like me asking silly questions like this over and over
again? ;-)
. April 2010 18:34
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Searching for existing files but only once
-Original Message-
From: Markus Karg [mailto:k...@quipsy.de]
Sent: Saturday, April 10, 2010 7:37 AM
To: General discussion for Windows
Solutions Limited. Registered in Scotland
No.
SC151456
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer
-Original Message-
From: Markus Karg [mailto:k...@quipsy.de]
Sent: 09 April 2010 13:33
To: General discussion
I assure you, all of us were beginners once.g And, of course,
learning
WiX is almost trivial; it's MSI that's hard.
That's not true in one point: WiX comes with lots of stuff that has
nothing to do with MSI. See the extensions. Maybe somebody write a
brilliant custom task that does what we
AFAIK for a small update (not minor upgrade) the version number of a
product must not change. The problem is: How to identify which version
(the original or the patched one) is installed now?
Maybe I misunderstood the contraint about version numbers, so I *may*
change the ProductVersion, but I
icon file as long as all of the target
files have the same extension.
So, to fix that:
Icon Id=MyIcon.exe SourceFile=pointer to exe file/
Shortcut Icon=MyIcon.exe ... /
Regards,
Alex
-Original Message-
From: Markus Karg [mailto:k...@quipsy.de]
Sent: Thursday, April
Any chance you might start thinking for yourself sometime soon?
Actually I do not understand why writing this. We are beginners with MSI
and WiX and have no clue what is there for free out of the box, and what
must be done with special tasks. Possibly there would be something that
can prevent
,
Glasgow G20 0SP
Email Disclaimer
-Original Message-
From: Markus Karg [mailto:k...@quipsy.de]
Sent: 09 April 2010 09:11
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] ProductVersion / Small Updates
AFAIK for a small update (not minor upgrade) the version
has no knowledge
of 64-bit environment and if u wont to provide support to both 64-bit
and 32-bit OS, its required man...sorry.. you can try with it..
-- H
-Original Message-
From: Markus Karg [mailto:k...@quipsy.de]
Sent: Thursday, March 25, 2010 4:59 PM
To: General
General discussion for Windows Installer XML toolset doesn't mean
e-mail here to ask for help on every little issue you get stuck on
without trying to figure it out for yourself. Maybe I'm being too
harsh
on yourself but there's a lot of people posting questions on here
which
can be answered
We'd like to provide a support phone number in our WiX-generated .msi in
a way that this phone number is visible to the end user when looking at
Support Details in the Software Control Panel of Windows. How to do
that?
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer
-Original Message-
From: Markus Karg [mailto:k...@quipsy.de]
Sent: 08 April 2010 09:49
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Support Phone
I have a strange problem. Following the directions in the WiX manual, I
added a ShortCut which is working well. Now I added a icon, but the
shortcut is not using it - it still uses the icon of the EXE! The
installation is per machine.
Icon Id=my.ico SourceFile=..\foo\my.ico /
Component
We need to upgrade a preinstalled software. That software is very old
and knows nothing of MSI, Registry etc. We actually have to search all
local drives for the old EXE file and remove the surrounding folder. As
this is a time consuming task, this shall only happen if this is really
an update of
I've set up a clean windows XP machine, installed MSVB5 on it, and WiX
3.0.
I can use MSVB5 to create the EXEs which in a second step shall get
packed into a MSI by WiX.
But when I start any WiX tool (like CANDLE or HEAT) it tells me that it
cannot initialize the tool.
Maybe I have to install
Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer
-Original Message-
From: Markus Karg [mailto:k...@quipsy.de]
Sent: 07 April 2010 10:16
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Cannot start any WiX 3.0 tool
I've set
There is no generic solution to detect any JRE. What you did below
should work with Sun's.
-Original Message-
From: ppremk [mailto:prem.kumar.ponutho...@exact.com]
Sent: Sonntag, 4. April 2010 08:29
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to check if JRE is
the .wxs
file does not include it.
Regards
Markus
-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent: Donnerstag, 1. April 2010 02:26
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] WiX 3.0: Bug in LIGHT
On 3/31/2010 8:55 AM, Markus Karg wrote:
tried
We have to write a .msi to install modules into a preinstalled software.
The problem is that once the module is installed, it can never get
uninstalled, as it modifies some software-internal structures in a way
that makes it impossible to undo.
So, we have to prevent that somebody goes
Zarevúcky
On 1.4.2010 8:21, Markus Karg wrote:
The original error message is:
error LGHT0130 : The primary key
'regA2E5343F2EC34F3CCC232B9D03BB2A85'
is duplicated in table 'Registry'.
Please remove one of the entries or rename a part of the primary key
to
avoid the collision.
I
-
From: Rob Hamflett [mailto:r...@snsys.com]
Sent: Donnerstag, 1. April 2010 11:52
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Prevent deinstallation
Are you aware that disabling installs will prevent major upgrades?
Rob
On 01/04/2010 10:29, Markus Karg wrote:
We
We noticed that there must be a bug in LIGHT (WiX 3.0):
We used
HEAT file my.ocx -out my.wxs
to create a Fragment from an OCX file, compiled it using CANDLE, then
tried to link it using LIGHT. LIGHT says that there is a duplicate in
that fragment, so we checked the fragment. In fact,
We're using HEAT to create Fragments from files:
CD %PROGRAMFILES%\Windows Installer XML v3\bin
HEAT file EXCEL8.OLB -gg -out EXCEL8.wxs
That works pretty well as long as HEAT and EXCEL8.OLB are located in the
same folder.
But if they are not, both of the following commands will fail:
.
Subject: [WiX-users] Beginner's Question: Registering OCX
On Mon, 29 Mar 2010 16:15:02 +0200, Markus Karg wrote:
Markus,
That page does not contain the word OCX, so what do you like to
tell me?
But it does mention the word file and OCX (a DLL, actually) is a file
type that Heat can
+0200, Markus Karg wrote:
Markus,
I wonder why this simple instruction is not found in the manual or
tutorial. ;-)
http://www.tramontana.co.hu/wix/lesson6.php#6.1 ;-)
Bye,
Gábor
---
Gábor DEÁK JAHN -- Budapest
We need to register a OCX file using WiX. How to do that?
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for
Limited. Registered in Scotland No.
SC151456
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer
-Original Message-
From: Markus Karg [mailto:k...@quipsy.de]
Sent: 29 March 2010 14:49
To: wix-users
Dear WiX Community,
for one of our applications, we need to provide the latest version of a
DLL which comes with XP in an older version (e. g. ASycFilt.dll) and
lives in WINDOWS\System32.
When we try to run our MSI on XP, it says that it cannot replace this
DLL since it is protected by the
Dear WiX Community,
we need to write a MSI file that has to install a 32 Bit software. It
shall correctly install on both, Windows 32 and Windows 64.
Is it correct to do one setup that always installs into SystemFolder, or
do we have to take any special care for the Windows 64 case?
] Beginner's Question: 32 Bit MSI on 64 Bit OS
Just create your MSI on 64-bit machine with the DLLs created as target
x86, and it will run on both 32-bit\64-bit machine. 64-bit OS will
automatically take care of system folder.
-- H
-Original Message-
From: Markus Karg [mailto:k
machine only then and then only msi
will be fully 64-bit\32-bit compatible. I already encounter this issue
in past and had to get 64-bit OS just to solve this issue.
-- H
-Original Message-
From: Markus Karg [mailto:k...@quipsy.de]
Sent: Thursday, March 25, 2010 4:46 PM
**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: Markus Karg [mailto:k
that msi created on 32-bit machine has no knowledge
of 64-bit environment and if u wont to provide support to both 64-bit
and 32-bit OS, its required man...sorry.. you can try with it..
-- H
-Original Message-
From: Markus Karg [mailto:k...@quipsy.de]
Sent: Thursday, March 25
[mailto:tschoen...@am-soft.de]
Sent: Donnerstag, 25. März 2010 16:23
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Replacing files in WINDOWS\System32
Guten Tag Markus Karg,
am Donnerstag, 25. März 2010 um 13:37 schrieben Sie:
Doesn't sound really
don't need to worry
about
the flag or the property being set correctly (for non Win7-only
switching
packages).
-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net]
Sent: Thursday, November 05, 2009 1:02 PM
To: 'General discussion for Windows Installer XML toolset
the
exact same MSI files in the same way (there is NO forcing of a new
way), or
you can make a single package that can be installed either way using
the new
property to enable the new behavior.
-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net]
Sent: Thursday, November
are supporting (if you use ProgramFilesFolder,
for
instance, the location you get will be in a non-profile location that
requires elevation to access, that is, a per-machine location, so you
can't
really use it in a per-user package.)
-Original Message-
From: Markus Karg [mailto:markus.k
This perMachine / perUser discussion really confuses me. ;-)
I tried what happens if I set InstallScope=perUser.
The result is, that I cannot install the software on Vista, because it says
I do not have sufficient access rights to enter C:\Program
Files\[Manufacturer] (no, it does not ask
When running my .msi on Vista, I do not see any difference between
InstallScope=perMachine and not using this attribute at all. Is
perMachine the default?
--
Let Crystal Reports handle the reporting - Free Crystal Reports
a per-user install when a
per-system may have been assumed (some other user logs on and says I
can see the files are installed but there's no shortcut).
Phil Wilson
-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net]
Sent: Thursday, November 05, 2009 11:53 AM
option which very nicely generates componentgroups, but the ID's
for
each directory are things like 'folder1'. Now when both libraries have
directories with the same Id it is there that I run into trouble.
-Nick
-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net]
Sent
it one or the other and prevent the one you
don't
support.
-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net]
Sent: Tuesday, November 03, 2009 9:28 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Per User / Per Machine
Blair
I disagree that structure and content are different concerns, they are the
same (or do you separate files and folders on your harddisk, too?). The
question was, why it is used in the *most simple* examples. Since it does
*not* focus on the example at hand, but instead, makes that examples overly
Spent one hour, finally discovered my own fault: I wrote light x.wixlib
y.wixOBJ instead of light x.wixlib y.wixLIB -- certainly there will be no
resources found in the original .wixOBJ, but only in the .wixLIB...! :-(
-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net
for the
application to run--so all the individual projects linked in this one
directory structure.
-Zach
On Wed, Nov 4, 2009 at 11:02 AM, Markus Karg markus.k...@gmx.net
wrote:
I disagree that structure and content are different concerns, they
are the
same (or do you separate files
Markus I'd recommend setting InstallerVersion to 301 unless you want to
either bootstrap the 4.5 installer before your MSI (or expect your
users
to manually install it) or you don't mind excluding users on certain
O/S'es (this is sometimes desirable if your application has certain
share the same wixlibs, while wix 2.0
can't
share the same libs with 3.x (or the same source code without some
transformation either).
-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net]
Sent: Monday, November 02, 2009 12:07 PM
To: 'General discussion for Windows
in that release
of
Windows Installer.
-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net]
Sent: Monday, November 02, 2009 11:16 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] How to know which InstallerVersion to use?
I am
the magic incantation yet.
-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net]
Sent: Monday, November 02, 2009 11:01 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] Per User / Per Machine
Blair,
in a different context you wrote
I have read both, the WiX manual and the WiX tutorial.
While the WiX tutorial is putting content (Files) directly into structure
(Directorys), the WiX manual is always separating it (Files are only
used in DirectoryRefs). As Gábor didn't know why the WiX manual authors
did that complexity, I'd
I have modularized my WiX project into several small subprojects using
fragments and wixlibs.
Binding together the wixlibs (and such, the fragments with the main
product) is working well.
Now I want to modularize my translations (.wxl file).
I am binding micro .wxl files into my wixlibs
share the same libs with 3.x (or the same source code without some
transformation either).
-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net]
Sent: Monday, November 02, 2009 12:07 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users
with non-wix
toolsets.
Note that wix 3.5 and 3.0 can share the same wixlibs, while wix 2.0
can't
share the same libs with 3.x (or the same source code without some
transformation either).
-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net]
Sent: Monday, November 02, 2009
to check for your code (using
MsiProvideComponent()) to obtain the benefits associated with
advertised
entry points.
-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net]
Sent: Sunday, November 01, 2009 10:05 AM
To: 'General discussion for Windows Installer XML toolset
Blair,
in a different context you wrote:
It is best to make your installations pure-perMachine or pure-
perUser
and never mix them
There is one thing I do not understand in that context: I always had the
impression that it is up to the *administrator* to decide whether to install
a software
I am a beginner to MSI and WiX and have a question on the InstallerVersion
attribute:
How to know what version of WindowsInstaller my .msi will need to run
correctly?
Is there some kind of table that I did not discover so far, containing all
WiX / MSI features plus the needed version
If I understand correctly, there are two ways to modularize my setup:
Fragments and Merge Modules. So the question is: Which one to use?
For me it looks like Merge Modules being a more heavy weight solution, but
the benefit is that those are a product-independent standard (i. e.
InstallShield
The WiX manual contains the following:
The first is a RemoveFolder element, which ensures the
ApplicationProgramsFolder is correctly removed from the Start Menu when the
user uninstalls the application. The second creates a registry entry on
install that indicates the application is installed.
I have a question on Verbs.
Error CNDL0019 : The Verb/@TargetProperty attribute cannot be specified
because the element is advertised.
The WiX manual does not say *why* I cannot use Verb/@TargetProperty with
advertised ProgIDs.
(1) Why can't I use this combination?
(2) What program
understand). Imagine what he could do writing a
tutorial
on how to author applications in Java or C++ or Ruby on Rails and
explain
using those technologies to the same degree. He could make money.
-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net]
Sent: Tuesday, October 27
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Beginner's Question on Multi Language Installer
On Mon, 26 Oct 2009 19:42:13 +0100, Markus Karg wrote:
Markus,
What is the best way to send it in?
Using the mailto link in the footer of every page.
Bye
-Original Message-
From: DEÁK JAHN, Gábor [mailto:d...@tramontana.co.hu]
Sent: Montag, 26. Oktober 2009 12:17
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Beginner's Question on Multi Language Installer
On Wed, 21 Oct 2009 20:18:00 +0200, Markus KARG wrote
Question on Multi Language
Installer
Great, specifics. Can you capture them in a bug (or multiple bugs) so
we
knock them down and not lose them in email.
On Sun, Oct 25, 2009 at 1:32 AM, Markus Karg markus.k...@gmx.net
wrote:
Rob,
my suggestions to improve the documentation are below
suggestions as to what is
not clear?
On Sat, Oct 24, 2009 at 5:02 AM, Markus Karg markus.k...@gmx.net wrote:
Thank you for this explanation. I wish this would be told in this clarity
in
the WiX documentation.
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Donnerstag, 22
] Beginner's Question on Multi Language Installer
The Specifying Cultures to Build topic in wix.chm (and on the web site)
differentiates between command-line (light.exe) and Visual Studio/MSBuild)
usages by section.
-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net]
Sent
toolset.
Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer
There is an entire page dedicated to this topic in the WiX.chm called
Specifying Cultures to Build. Can you provide suggestions as to what is
not clear?
On Sat, Oct 24, 2009 at 5:02 AM, Markus Karg markus.k
:)
Sascha
On Thu, Oct 22, 2009 at 5:18 AM, Markus KARG markus.k...@gmx.net wrote:
Well, frankly spoken that (really huge) tutorial is in part outdated,
false
and overly complex to understand, and it does things without explaining
their intension or details in some chapters (what really confuses
. Oktober 2009 02:51
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer
Interesting. I've never heard that feedback before. Thank you.
On Wed, Oct 21, 2009 at 11:18 AM, Markus KARG markus.k...@gmx.net wrote:
Well
separator character you may or may not break this
implementation, I don't remember and I'm not taking the time to look it up
right now.
Light.exe doesn't care, it recognizes both the semicolon and the comma as
separators and treats them identically.
-Original Message-
From: Markus KARG
back to English.
In other words, there is no real difference at all between the three
command-lines.
-Original Message-
From: Markus KARG [mailto:markus.k...@gmx.net]
Sent: Wednesday, October 21, 2009 11:09 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX
Markus KARG wrote:
What I do not understand under this circumstances is: Why can I add a
LIST
of cultures to light.exe? I mean, what does it actually do with all
the
cultures if actually always taking just the first in the list?
It uses all of them to support fallback from available
files that
don't
match the culture are ignored, so the command-line variation between
the
different links is minimal and easily controlled for.
-Original Message-
From: Markus KARG [mailto:markus.k...@gmx.net]
Sent: Tuesday, October 20, 2009 3:01 PM
To: 'General discussion for Windows
. At
that point, you can vary just the Cultures parameter and all WXL files
that don't match the culture are ignored, so the command-line variation
between the different links is minimal and easily controlled for.
-Original Message-
From: Markus KARG [mailto:markus.k...@gmx.net]
Sent
, and bind the baseline
wixout
into the MSI you subsequently apply each MST to.
-Original Message-
From: Markus KARG [mailto:markus.k...@gmx.net]
Sent: Tuesday, October 20, 2009 12:06 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Beginner's Question
Hello Everybody,
I am new to both, MSI technology in general and the WiX product in
particular, but I have some experience with some old InstallShield products
(pre-MSI-age).
InstallShield allowed me to simply add translated strings for lots of
languages, so one single setup.exe contained
-
From: Markus KARG [mailto:markus.k...@gmx.net]
Sent: Tuesday, October 20, 2009 12:06 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Beginner's Question on Multi Language Installer
Hello Everybody,
I am new to both, MSI technology in general and the WiX product
78 matches
Mail list logo
