Thanks Benjamin and Rob:
I did try that. I had an odd behavior. If I tried CreateFolder for
windows\temp, all existing permissions were lost (meaning administrators, etc
were removed from folder permissions).
If I tried for some other folder, it worked as expected. Basically adds the
perm
This would appear to indicate that someone has messed with Windows
Installer's internal state (either its stored state or the cached/stripped
files it "owns", or both, any of which requires administrator-level
privileges). This is not the kind of thing that is likely to happen under
any normal use
I'm not sure which source I was looking at. Assuming v3.0 RTM, Bob is right.
Wix's final dialog is called ExitDialog, and it is a "success" dialog. You
would need to replace that dialog with the content of your "MyDialog"
(including sequencing) and make that dialog call another dialog from its
"Ne
Blair wrote:
>
>
>
>
I don't think that'll work -- remember that InstallUISequence has
"special" sequences for the success, cancel, fail, and suspend dialogs.
To have multiple dialogs after an install completes successfully, you
need to replace ExitDlg.
--
sig://boB
http://joyofsetup.co
Any MSI with any arbitrary ProductCode needs a stable name.
If you always use Major Upgrades, the names don't matter, and you won't have
any issues with your names.
If you employ minor upgrades or small updates, and you distribute those via
MSI instead of MSPs, you will probably need a bootstrapp
Normally the INSTALLDIR passed to a mergemodule is where the package author
wants the merge module's content to be. Your requirement seems to indicate
that you are not allowed to communicate to the package author what directory
they are supposed to supply to you when performing the merge.
If you t
Managed code custom actions called frequently like that are going to be slow
because of all the process creation-and-termination/CLI-state
setup-and-teardown/etc. going on. You may be interested in the "workaround"
described on this page
(http://legalizeadulthood.wordpress.com/2009/10/23/ui-custom-
We are currently considering a convention for file-naming, to assist in
tracking our numerous installers, and the many versions thereof.
I recall some time ago being told that renaming an MSI will break some
features - and also read this:
http://blogs.adobe.com/simplicity/2007/05/dont_rename_that
So you need upgrades to not replace previous installations? In that case
they are not upgrades.
I'm still trying to understand your use-case and your servicing strategy.
How do you intend to fix older versions? What do your users expect when they
run a newer installation package from you when they
For option one: you require either some side-effect from the UI sequence OR
a public property that you can cryptographically (or otherwise) verify from
the execute sequence was correctly set from the UI sequence. Correct?
Side-effects that are not part of the installation transaction can have
unin
Heat.exe and dark.exe both use WiX extensions to generate WiX source files.
The initial list of extensions to use are supplied via the corresponding
.config file, augmented by the -ext command-line argument (or
response-file equivalent).
Or are you referring to the extensions' code callable by th
Admin images are MSIs that do not contain embedded cabs where the files are
laid-out in "source-directory" layout using their 8.3 filenames according to
the File table's FileName column, which is what you get when you perform an
"administrative installation" of an MSI.
The "path" part of the -ax
>From your description you have one package that installs both website and
database and you use two features, one for database and the other for
website?
If you use the same "installation directory" for both the components of both
features they will use that same directory on maintenance transacti
Also, instead of saving the features you picked in the registry, you may
prefer to use the MigrateFeatureStates activity that is built into Windows
Installer and was intended for maintaining feature settings across major
upgrades (minor upgrades and small updates preserve feature settings
automatic
Your first dialog (in a series) is the only one of that series you should
place into the InstallUISequence. That first dialog will then call the
second dialog, the second can call the first, either one can cancel the
series, and only when the second dialog is done do you close the series,
which wou
I'm also not clear on your intent here. Are you trying to force your shell
to be uninstalled when upgrading from a previous installation where it was
previously installed? Or simply force your shell to never be upgraded?
-Original Message-
From: Alexander Shevchuk (Volt) [mailto:a-ale...@m
Short answer:
-gg is intended for "run-heat-once-check-in-result" and manually tweak the
.wxs files later.
-ag is intended for "run-heat-each-build" where you may not be checking in
the .wxs files.
Intermediate answer:
-gg generates truly unique guids for each component that have no guarantee
of s
All custom directories, like SHELLPATH are represented as properties and they
will get their values after CostFinalize (suggested sequence number in
InstallExecuteSequence - 1000). Your mailto:mirram...@googlemail.com]
Sent: Monday, October 26, 2009 4:18 PM
To: General discussion for Windows In
We do all of those things. Not to belabor the point, but in our
scenario (prebuild.bat generation of component.wxs using heat) is
there really a difference between -gg and -ag?
On Mon, Oct 26, 2009 at 11:18 AM, Blair wrote:
> I would recommend that the first change would be to update your prebui
Hi all,
after hours and hours of stabbing in the dark I ask you for your help. I
have a msi file which contains the following elements:
- <#>
- <#>
...
- <#>
- <#>
- <#>
- <#>
- <#>
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,
Gábor
---
DEÃK JAHN, Gábor -- Budapest, Hungary
E-mail: d...@tramon
On this page: http://wix.sourceforge.net/ in the box of categorized links,
under Support, pick the one about the bug database, and click "Add new".
You can leave the bug unassigned, it will be assigned either before or
during the weekly wix-dev meeting.
-Original Message-
From: Markus Kar
Hi Dan,
Yep, unfortunately this sort of change is something that needs to be
looked at long term - it'll take a while and be an iterative process.
Moving this sort of thing into the post-install was one of our more
recent changes, thankfully I managed to get our InstallShield-to-WiX
migration star
What Blair highlights below is probably the best misunderstood feature
of wixlib/shared fragments - you can reference *.wxs and *.wixobj each
time you build, but only the fragments that are referenced are
included in the MSI output.
Meaning you can have a large number of fragments in your common/s
I'm trying to wrap my head around exactly how Back/Next buttons work, and the
right way to wire them together. In my installer UI, I have two dialogs:
WelcomeEula Dialog and Keycode Dialog. I declare them both in my
InstallUISequence as follows:
NOT Installed
NOT Installed
Simply by do
If you tell me where and how to do this I would be glad to file all of them.
:-)
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Montag, 26. Oktober 2009 04:28
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Beginner'
Thank you for picking up my issue. If I would have known earlier that active
interest is there, I would have noted my issues with the tutorial when
reading it. Unfortunately I did not. But if I will find some more, I will
let you know. What is the best way to send it in?
Regards
Markus
> -Ori
In case anyone was wondering, it seems MSI does not like the
Session.Database object being called from within a VBScript function. So
the work around is as follows...
Dim gSessionDatabase, gComboBoxView
Set gSessionDatabase = Session.Database
Function GetComboBoxView( oSessionDatabase, oProperty
You probably want to use the AddLocal and Remove events. Try adding something
like this inside the
Control element for your Next button:
The AddLocal and Remove events update the list of features to be installed The
text given for Value
is the ID of the feature. I'm digging up old W
Thanks, I figure that much... :-)
#2 is also not a great options because I don't want to unnecessarily inflate
the install package.
On Mon, Oct 26, 2009 at 5:46 PM, Blair wrote:
> There are only three possible "solutions":
> 1) use a better MSM. Unfortunately there isn't one from MSFT at this ti
There are only three possible "solutions":
1) use a better MSM. Unfortunately there isn't one from MSFT at this time.
Hopefully they will improve their MSMs over time.
2) use a bootstrapper that installs the runtime for you using their .exe
file (vcredist*.exe) for the runtime.
3) live with these w
In my UI I have three options represented by radio buttons in the UI
that only are shown the first time the product is ever installed.
Call them A,B,C. The selected feature is installed and remembered in
the registry so I don't ask again if a newer version of the product is
installed.
I wanted to
For DLL (and EXE) custom actions, the bitness is determined by the action's
binary itself, not any marking in the MSI. In the case of DTF, the initial
bitness employed will be the bitness of the sfxca.dll packaged by the
wrapping action of the DTF build process. I haven't looked at the source
code
I would recommend that the first change would be to update your prebuild
batch file and replace "-gg" with "-ag". The second would be to ensure that
the Id attribute of the Product element is "*" and ensure you have
functional Update authoring, and the third is to provide a way to have your
build s
No, we haven't shipped yet.
At this point, our build system doesn't (easily) support check-ins
back to source control. So, our -gg script might as well be an -ag
script. I have only checked in a simple stub component file for the
project which gets over-written by a prebuild batch file that, amo
My code is quite standard way to include merge files:
**
* *
* *
**
* *
* *
* *
* *
**
I get like a hundred+ different warnings (which, well, worry me a bit,
although the install seems to
work.) The examples of warnings I get are as following:
warn
Hi wix users,
My install allows the users to install a website and/or database using
typical or custom features. Currently, if the user installs the
database first, I put the database scripts in a temp folder, but the
product is registered with add/remove programs. For the database
install, I
On Wed, 21 Oct 2009 20:18:00 +0200, Markus KARG wrote:
Markus,
> Well, frankly spoken that (really huge) tutorial is in part outdated,
> false and overly complex to understand,
Well, it had been updated to v3 just a couple of months ago, I hope it couldn't
have become that outdated since. And i
Hi guys, I'm still having trouble using torch with the admin images and
cannot find much instructions for it. Could you clear up a couple of basic
questions for me?
What are Admin images - these are the "msi"s? I notice some examples around
where 2 of these are fed into the torch commandline after
Rob Mensching-7 wrote:
>
> Do something like:
>
> Value=""[DirName]FileName.exe""
>
> or better:
>
> Value=""[#FileId]""
>
>
First one did not work. The solution is, apparently, to put the whole string
along with quotation marks inside apostrophes. Like this:
' "[DirName]FileName" ' (space
40 matches
Mail list logo
