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
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
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
)
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
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
root of your folder structure.
> In this example I use the Set WINDOWSVOLUME = [WindowsVolume] - it's
> always available and it is usually C:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
&g
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
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,
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).
>
>
>
ey think are passable installer experiences.
> >
> > Yes, sorry, it is a lot of work to learn MSI. I was writing
> InstallScript
> > installers for 7 years and was not initially impressed with MSI. In
> fact,
> > you could say I was a late adopter since I didn
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
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
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?
>
>
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"
>
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
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
nt Integration - Walt
Dexter
On Fri, Jan 24, 2014 at 10:35 PM, Rob Mensching wrote:
> What about the MSIRMSHUTDOWN property and maybe the REBOOT property.
>
> -Original Message-
> From: Walter Dexter [mailto:wfdex...@gmail.com]
> Sent: Friday, January 24, 2014 8
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
MANAGERCONTROL is the one that would actually help. Your
>> example shows a "0". You might use "Disable". Ultimately, all this is
>> documented here:
>> http://msdn.microsoft.com/en-us/library/aa372059(v=vs.85).aspx
>>
>> -Original Message-
&
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
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
;
> >>
> >> Your verbose install logs should be telling you why it wanted to
> "replace" files that "didn't change". What do your logs have to say?
> >>
> >>
> >>
> >>
> >>
> >>
> >> Blair
> >>
> >>
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
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.
>
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
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
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
KeyPath="yes">
>
> Description="Launch MyApp"
> Target="[ProgramDir]MyApp.exe" WorkingDirectory="ProgramDir"
> Icon="icon.ico"/>
>
>
>
>
> Cheers,
> Paul
>
>
k);
>
> MyShortcut.TargetPath = "";
> MyShortcut.Arguments = " ";
>
> MyShortcut.WorkingDirectory = "";
> MyShortcut.Description = "Launch blah blah";
>
> MyShortcut.IconLocation =
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
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
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
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
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.
> >
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
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
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
57 AM, "Rob Mensching" wrote:
> This? http://msdn.microsoft.com/en-us/library/aa368012(v=vs.85).aspx
>
> ___
> FireGiant | Dedicated support for the WiX toolset |
> http://www.firegiant.com/
>
> -
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
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
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
>
>
>
> -
*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
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
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 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,
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
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
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
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
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
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
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
52 matches
Mail list logo
