I know this isn't really specifically WiX related, but I also know you guys
know lots of MSI and installer stuff.
I'm seeing references to 32-bit MSIs vs. 64-bit MSIs.
Is there actually something inherently architecture-related about an MSI,
or is it just a matter of the 32/64 nature of the progr
d, the base MSI can be provided, but since the
> installed product consists of MSI+patches, the actual installed
> product can't be rebuilt. It may ask for the patch in that situation.
> It looks like you have some testing to do.
> ---
> Phil Wilson
>
>
> On
Hi, all.
I know you're going to just shake your head at this, but here it is.
I create installers for one of many products that install onto a group of
roughly 14,000 systems at my employer. Some of these systems have drives
that are small by modern standards, and thanks to a weird partitioning
s
May want to just open up one of your InstallShield MSIs with Orca and see
if you can tell how the applicable stuff is set. My experience with the
more heavy-duty installers is that there's a lot of crap in their MSIs, but
you might find something.
On Fri, May 8, 2015 at 11:39 AM, Zig wrote:
> On
Scott,
There's little doubt that security on Windows has tightened up in recent
versions. Have you been able to install as you describe in 7 and 8 or was that
strictly XP?
On May 7, 2015, at 10:04 PM, Scott Ferguson
wrote:
> Hi,
>
> Yes I've picked up that it probably "shouldn't be possi
I think you'd have to rig heat to run as part of package creation. Personally I
never managed to get it to do what I wanted, but I know people do.
> On Apr 19, 2015, at 11:06 AM, ronif wrote:
>
> Hi Rob,
>
> Thanks for your answer,
> So there is no way to include a folder without specifying
I suspect I'm "stuck" but thought I'd ask.
I have two existing MSIs, call them "Base.msi" and "Dell.msi". They install
separate facets of my product - the base files, then additional files
needed to support particular Dell hardware.
I now want to create a new single MSI that replaces "Base.msi" a
What you're describing is vaguely similar to how we do things. There's a
single server in each of our locations that contains MSIs that are
installed on other systems in that location across the network.
I just package the client MSIs in a bigger MSI, and install the "bigger
MSI" on the server. Wi
You probably don't have sufficient permission. Try running your MSI as
Administrator.
On Jul 9, 2014, at 7:19 AM, Pritesh Acharya wrote:
> I am new to WiX and I've been trying to use it to create a installer for a
> basic console application which just prints hello world in console and
> hang
I do this quite a lot. So long as the setup.exe isn't masking an MSI, its a
simple matter of installing the files to the target system and doing a
custom action to invoke it.
On Jun 15, 2014 6:14 PM, "Nicolás Alvarez"
wrote:
> 2014-06-15 14:36 GMT-03:00 Moyer, Andy :
> > What I need help with is,
I've only done it with VBS, which I know isn't recommended, etc, but to do
that, I have the below.
If you're really using calc.exe in your testing, are you sure it isn't
working? Sometimes weirdness happens with user contexts - did you check to
see if calc.exe is running on your system under a dif
I don't have my packages on this system, so I can't look to see how I have
it working, but I believe you'd use a to reference the
executable, then a CustomAction with "BinaryKey" and "ExeCommand"
attributes to run it, and let Windows Installer take care of the temporary
nature of it.
Since the d
*Tons of background...*
I have an MSI that installs three executables, a bunch of image files, and
a few INI files.
On the target device, which is similar to a cash register, two of the
executables ("A1.exe" and "A2.exe") are always running, but the third
executable ("N.exe") runs for about 10 se
and think about the
> consequences.
>
> --
> John Merryweather Cooper
> Build & Install Engineer – ESA
> Jack Henry & Associates, Inc.®
> Shawnee Mission, KS 66227
> Office: 913-341-3434 x791011
> jocoo...@jackhenry.com
> www.jackhenry.com
>
>
>
> -
Why is doing this a bad idea? I know that's the common belief, but I don't
know the reason.
On Fri, May 30, 2014 at 11:09 AM, John Cooper
wrote:
> Instead of using the old Upgrade authoring, use the MajorUpgrade authoring
> and take a look at the AllowSameVersionUpgrades attribute. Note that
I do this in some MSIs that we deploy strictly silently via Microsoft
system management stuff.
My upgrade block looks like this:
And also this, which I think matters:
Then I have a wxi file that I include that contains:
You don't really need the vars and the .wxi fi
Original Message-
> From: Walter Dexter [mailto:wfdex...@gmail.com]
> Sent: Thursday, April 3, 2014 8:37 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Reference for logical operators, conditions, etc
>
> I feel foolish asking, because I
I feel foolish asking, because I know it's a "RTFM" moment, but my problem
is that I can't find the "M".
I see scraps of WiX input that look like:
but I can't find the reference for the logical operators, comparison
operators if any, etc.
Can someone provide a link or at least point me in t
So you have compared every single file installed between the InstallShield
install and the WiX install and they're the same?
Same for any registry settings?
I'm not likely to be able to help you, but if you don't tell the WiX-smart
guys here what you've done and what you've found, they're not goi
You've had a number of suggestions for troubleshooting. Have you followed
them? If so, what did you find? If not,why not?
On Mar 21, 2014 2:29 AM, "karthikrangaraj" wrote:
> To All,
>
> For testing and i made an installer using Install Shield LE and the
> application works perfectly fine on both
else it is
> showing the error "Preferences.xml not found". Thats the reason i am
> using the CopyFile the way I am.
>
> On 18-03-2014 17:22, Walter Dexter wrote:
> > I understand what you're trying to do, but please stop and ask if it
> makes
> > sense.
> >
I understand what you're trying to do, but please stop and ask if it makes
sense.
The format of the path under ProgramData is usually
publisher/software/files and not editable by the user.
For that matter, the software should be under Program Files, referenced by
symbol, not C:\.
It's a bit confu
This really isn't an install issue at this point, but...
Do you actually need to store things in this file, or are you just wanting
to make sure you have X MB available for your program?
If the latter, you could create and package a file that contains the same
byte value over and over. That shoul
Of course the last 1% is always the hardest.
On Mar 7, 2014, at 12:30 PM, Pavan Konduru wrote:
> Hi Walter,
>
> Changing the upgrade code will only treat it as an upgrade. We would need to
> change the product code to make it install side-by-side.
>
> --Pavan
>
>
Silly naive question... Would giving each version a different Upgrade
codeand a version based destination directory (like MyApp.1.1.1 instead of
just MyApp) accomplish at least most of what Pavan wants?
On Mar 6, 2014 3:20 PM, "Bryan Wolf" wrote:
> My thoughts were more focused on what the produc
a) Yes, that's the restart manager.
Try reading up on this stuff at
http://msdn.microsoft.com/en-us/library/aa372059(v=vs.85).aspx (Rob gave me
this link when I was working through something else.) It's tricky and
confusing, took me a day or two of reading, testing and begging for help
here to ge
k);
>
> MyShortcut.TargetPath = "";
> MyShortcut.Arguments = " ";
>
> MyShortcut.WorkingDirectory = "";
> MyShortcut.Description = "Launch blah blah";
>
> MyShortcut.IconLocation =
KeyPath="yes">
>
> Description="Launch MyApp"
> Target="[ProgramDir]MyApp.exe" WorkingDirectory="ProgramDir"
> Icon="icon.ico"/>
>
>
>
>
> Cheers,
> Paul
>
>
I was just coming in to correct the path...
The problem you're having is that the Directory attribute is supposed to be
the ID of a directory, not the path to a directory.
Here's how I'm dealing with absolute paths. My standard disclaimer with WiX
advice is that I first used WiX in November and I
M
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] Read a value from a text file and use it in WIX
> source file
>
> Thanks Walter, that works for me :)
>
> On 12-02-2014 21:35, Walter Dexter wrote:
>> Sorry I forgot about this. Here'
You don't say what OS, but recently in POSReady 7 I achieved this by just
putting a shortcut into the specific directory for that user, which if I
remember right is under c:/userdata/username/Microsoft/windows/start menu/...
If you poke around you'll find it.
On XP and earlier, the start menu t
et /p svt=
On Tue, Feb 11, 2014 at 9:34 AM, Suvrajyoti Panda wrote:
> Thanks Walter, that would be really helpful if you can give me an example.
>
> Regards,
> Suvra Jyoti
>
> On 11-02-2014 19:53, Walter Dexter wrote:
> > It may not be the most elegant way, but I'm
It may not be the most elegant way, but I'm doing the same thing by passing
the contents of the file (first line anyway) as a command line argument to
the linker.
I use a .cmd file to run the WiX ci mpile and link so its just a bit of
batch file processing.
If you need an example I can get it for
If you mean when you install the resulting MSI, that would be in the
Windows installer documentation. Or you can do msiexec /? and I think
that's in there.
On Feb 11, 2014 7:42 AM, "Kiran Somisetty" wrote:
> I have a requirement to pass values from the command line while
> installing the wix.
>
ret/educate on the interpretation thereof
>
>
> Walter Dexter wrote:
>
> So far as the logs, I have yet to ever find anything I can make sense of in
> an MSI log. I'm well aware that's my own deficiency but those things are
> 99.95% unintelligible to me.
>
>
> On Tu
So far as the logs, I have yet to ever find anything I can make sense of in
an MSI log. I'm well aware that's my own deficiency but those things are
99.95% unintelligible to me.
On Tue, Jan 28, 2014 at 2:46 PM, Walter Dexter wrote:
> In my case the installer is always run as quie
> As Blair says, look at the verbose log. In the absence of hard
> evidence that says what's really happening it seems premature to
> change feature content.
> ---
> Phil Wilson
>
>
> On Tue, Jan 28, 2014 at 5:44 AM, Walt Dexter wrote:
> > And there&#
ge”. What do your logs have to say?
>
>
>
>
>
>
> Blair
>
>
>
>
>
> From: Walter Dexter
> Sent: Monday, January 27, 2014 9:53 PM
> To: General discussion for Windows Installer XML toolset.
>
>
>
>
>
> I believe that is
them off. Perhaps it just shoots first and asks questions later unless told
to not terminate. I have no idea.
On Mon, Jan 27, 2014 at 7:17 PM, Nicolás Alvarez
wrote:
> 2014-01-27 Walter Dexter :
> > Got it!
> >
> > I haven't worked out all the details but changing the MSI
If you're talking about this error from "candle," or a similar one from
"light":
error CNDL0200 : The Component element contains an unhandled extension
element 'Util:blahblahblah'. Please ensure that the extension for elements
in the 'http://schemas.microsoft.com/wix/UtilExtension' namespace has
On Sun, Jan 26, 2014 at 7:00 AM, Walter Dexter wrote:
> I tried that. Disable just makes it use the older method instead of the
> restart manager. In practical terms, it's just a different dialog box if
> you don't use the /quiet option, and no difference in behavior if you d
u might use "Disable". Ultimately, all this is
> documented here:
> http://msdn.microsoft.com/en-us/library/aa372059(v=vs.85).aspx
>
> -Original Message-
> From: Walter Dexter [mailto:wfdex...@gmail.com]
> Sent: Saturday, January 25, 2014 9:12 AM
> To: Gene
om/wix/UtilExtension";>
ReallySuppress
e*System Application from Metametrics
US e*Restaura
I have an embedded system running Windows POSReady 7 (Windows 7 for POS
devices.)
I have an MSI that installs a collection of .Net .exe files, VBScripts, and
other stuff.
Three of the executables are always running under a user account. That's
just a normal thing on this device - it boots, automa
So your entire target machine population has had that done?
On Nov 22, 2013, at 9:43 AM, RussellResthaven
wrote:
> Never mind, looks like I found the answer.
>
> I've always disliked Windows 7 UAC security where it gives a pop-up every
> time anything wants to change my system, which is often
Considering local internal changes to WiX a competitive advantage seems
indicative of a marginal business plan at best.
More likely is the opposite. If I were to modify it for internal use I would
have no idea how to get authorization to do so, and nobody would be willing to
figure it out.
O
Is the problem that you no longer have the MSI except as it exists in the
.exe and you need it?
On Saturday, November 9, 2013, Periyasamy wrote:
> Hi Rob,
>
> Here is the requirement:
>
> I have developed the installers using WIX Burn, one of our developer now
> wants to extract the msi file from
ually things done the right way. But when it
> > becomes obvious that the mountain will not move, I break out my bag of
> > tricks to keep the train moving. I prefer not to though.
> >
> >
> > From: "Walter Dexter"
>
k with sometimes.
On Thu, Oct 31, 2013 at 7:20 AM, Christopher Painter wrote:
> Yes, that's going to be a problem. There are ways to mitigate it but is
> there any chance they can fix this? What tool are they using to make the
> EXE?
>
>
Hi, folks.
Sorry to ask such naive (and honestly, non-WiX) questions, but...
when installing from an MSI, Windows Installer makes decisions on EXE files
based on the file version resource in the file, right?
I have a vendor releasing software to me where they've set the Product
version in their
Hi, all.
My "install environment" is our various retail systems scattered around the
country. Because of the nature of retail systems, we have a LOT of drive
corruption, so one of the unofficial rules is to have an installer always
install files, even if they're already there and modified, even if
F: +44 (0) 141 945 8501
> http://www.iesve.com
>
> **Design, Simulate + Innovate with the **
> Integrated Environmental Solutions Limited. Registered in Scotland No.
> SC151456
> Registered Office - Helix Building, West Of Scotland Science Park, Glasgow
> G20 0SP
> Email D
essed with MSI. In fact,
> you could say I was a late adopter since I didn't pick it up until 2003.
> It took me 6 months of banging my head against the wall trying to get it to
> do what I wanted before I felt comfortable. It was another 6 months before
> I had that "b
er makes their
> life easier. That seems fair to me. Hopefully, there are (many, manymore
> people installing your software than there are building it... which means
> saving the customer problems by taking on the work in development is a good
> trade (economically speaking).
>
>
>
data and transformable with standardized behaviors. You lose
> all of that when you choose to use it merely as a glorified ZIP and do
> everything else out of process.
>
>
> From: "Walter Dexter"
> Sent: Monday, October 14,
I'm working on transitioning from Inno Setup to WiX due to corporate
standards.
I have some Inno that are fairly complex, running programs, setting INI
values, registry settings, etc.
If I set the Inno to not make itself uninstallable, I could just move the
files out of it to an MSI, include the
root of your folder structure.
> In this example I use the Set WINDOWSVOLUME = [WindowsVolume] - it's
> always available and it is usually C:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
&g
Moving the custom actions for setting the C Drive to be After CostFinalized
resolved the problem. WiX threw an error when I tried before CostInitialize.
Thanks!
On Thu, Oct 10, 2013 at 2:20 PM, Walter Dexter wrote:
> I just tested by copying the installed files to where the log say C_DR
)
Thanks a lot!
On Thu, Oct 10, 2013 at 1:33 PM, Edwin Castro <0ptikgh...@gmx.us> wrote:
> On 10/10/13 11:08 AM, Walter Dexter wrote:
> > I had a similar thought about an hour ago while driving about c_drive not
> > getting redefined properly for the uninstall and will try t
on. You'll
> notice the uninstall log refers to C:\CDrive\ all over the place.
>
> I don't understand why you need that custom action at all. Can't you
> hardcode C:\ into the Name attribute?
>
> --
> Nicolás
>
> 2013/10/10 Walter Dexter :
> > I pos
Name=20130909USSTC001_PasswordChange.gum,,ComponentId={E387FF1C-6976-4F3D-80A3-A4CF2F79BC68})
>
>
>
> On Wed, Oct 9, 2013 at 11:05 PM, Peng Lv wrote:
>
> > I met with this issue either, my solution is adding a custom action dll
> to
> > delete all files while uninstall, b
I posted this at Stackoverflow as well, but I'm just at a loss for what to
even look at, so I'm hoping someone can point me in a good direction.
I have been using WiX to create an installer for my project. It's fairly
simple, just drop some files in three different directories and run a
VBScript t
In order to bring closure I thought I would post my resolution. I was able to
'fix' the issue by installing as another user on the system. Same machine,
same install, same running apps, just a different logged on user...guessing
a messed up registry but I cannot say for sure.
Thank you,
Dex
--
Use the User Element from the Util Extension to grant the user LogonAsService
permission. If you only want to grant permission to an existing user the
section would look something like this:
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Service
Thank your for all the suggestions. I had already included many of the
suggestions into the original installation. I am now in the process of
determining why this occurs on only a few machines while others work fine. I
just don't know what environmental settings could be causing such a drastic
redu
It appears we are going down the right path.
Thank you.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Install-multiple-services-using-single-ServiceHost-exe-tp7579407p7579449.html
Sent from the wix-users mailing list archive at Nabble.com.
-
66 matches
Mail list logo
