Hi,
We planned to use WiX to generate MSI packages for our clients. From the links
and resources, I understand WiX is a concept and WixToolset only facilitates
MSI package generation.
Considering MS-RL license for WiXToolSet, am I allowed to generate MSI packages
for any commercial projects? P
Greetings,
This is my first time trying to add a dialog to the Minimal install. I'm
trying to add a credential dialog so installing users can automatically set up
their configuration. The new dialog I've inserted has back/next buttons but
when going back to the WelcomeEula and the hitting nex
You can just attribute the appropriate File as a KeyFile (See File/@KeyPath).
-Original Message-
From: Hans ter Horst [mailto:hoshis...@gmail.com]
Sent: Tuesday, October 22, 2013 8:55 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Something I noticed with Servic
Oh, I see, you are referring to the Microsoft Installer internal tables, so
nothing can really be done.
On Wed, Oct 23, 2013 at 3:53 AM, Hans ter Horst wrote:
> And the keyfile would be the first file in the Component? Wouldn't it make
> sense to make the link to the service install target a bi
And the keyfile would be the first file in the Component? Wouldn't it make
sense to make the link to the service install target a bit more explicit to
help people messing about like me?
Hans
On Wed, Oct 23, 2013 at 3:18 AM, Christopher Painter wrote:
> The ServiceInstaller table doesn't have a
Hi Bruce,
Every now and then we also get the problem where the timestamp server is
unavailable and the code signing fails, which in turn causes our automated
build to fail. Our application is very large and takes more than an hour
to complete a full build, so as you could imagine a code signing
The ServiceInstaller table doesn't have a foreign key join back to the file
table. It's target of the service is always the keyfile of the parent
component.
From: "Hans ter Horst"
Sent: Tuesday, October 22, 2013 8:13 PM
To: "General discussion for W
When I used the Fragment below, I noticed that the Windows service created
links to the *web.config* file as executable instead of linking to
MyServer.exe which is of course not a proper executable file and the
service fails to load understandably.
I moved the line to a separate
Fragment and Compo
I'm creating an installer in WiX that requires text replacements in a
config file. The config file is not XML or INI based so I need to do some
sort of search and replace / regex. Is there anything in WiX or other
community extensions that provide this? I know how to do this using
InstallS
Can a bootstrapper with multiple chained MSIs be made to avoid multiple
Add/Remove Program entries? In other words, I want the bootstrapper to
simply run each MSI as if it were run outside of the bootstrapper. I don't
want the set of MSIs to be treated as a single package.
Thanks for any assi
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
Thanks, I figured out the correct switch for the description. We use the
/f /p option in our current build for cert selection. Regarding the retry
issue, I recall one of my former build systems doing something similar. I
don't think we have run into that here (knock on wood). Maybe IS magic
pro
On 10/22/2013 6:47 PM, Tony wrote:
> Answering my own question...
>
> ".(though now I see it needs to be "property", so I'll give that a try)"
> <-- that was it. I don't know why I was thinking it need to be a WiX
> property and/or preprocessor variable. **OBVIOUSLY** it needs to be a
> "proper
Signing the MSI now works, but I don't see the SignCabs target being
invoked. How does SignCabs get set to the list of my cab files?
On Tue, Oct 22, 2013 at 1:47 PM, Tony wrote:
> Answering my own question...
>
> ".(though now I see it needs to be "property", so I'll give that a try)"
> <-- t
Some of my registry keys use values from the Directory structure:
http://www.intergraph.com
.
From: Phil Wilson [phildgwil...@gmail.com]
Sent: Tuesday, Oct
Answering my own question...
".(though now I see it needs to be "property", so I'll give that a try)"
<-- that was it. I don't know why I was thinking it need to be a WiX
property and/or preprocessor variable. **OBVIOUSLY** it needs to be a
"property" within the project file. Duh!
Now the sig
Thank you for the correction, Phil. I take it I cannot easily determine if a
downgrade was prevented from a non-interactive mechanism?
(Our applications are installed by a Windows service without user intervention.)
Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0
I built a "Hello World" C# console application to test the signing process.
Here's what I've done so far...
1. Added a wix (msi) project to the solution.
2. Set Manufacturer, updated InstallerVersion to 500, added a
'MediaEmbedCab="yes"' entry (removed the MediaTemplate entry), and
added the
I don't believe your interpretation of 1638 is correct. As far as I know
this error is returned when a product defined by a ProductCode is installed
and you try to install the same ProductCode from an MSI with a different
product version. You can't install the same ProductCode twice from a normal
c
Yes, the bundle version and the package version number changes for each
build.
Does anyone know if the bootstrapper _should_ work similarly to an MSI?
That is, does it consider only the upgrade code and the version number (not
the bundle name) when determining if an older version exists that shoul
A patch that is an update to installed components doesn't need to know
folder locations unless you need to specify them for some other reason. For
an update of component C-Guid of product code P-Guid it can locate the path
to any component (as can any program) by calling MsiGetComponentPath
(P-Guid
While I was using WiX 3.5 it detected changes of JScript file that is
included as Binary element and included it in msp patches. Now with WiX 3.7
it seem that only way I can make that JScript file to be included in msp
patch is to create another Binary element which points to it . I tried
changing
On 10/22/2013 3:00 PM, Tony wrote:
>
>
>
To avoid the signature going invalid when the certificate expires, you
probably want to add a timestamp:
http://timestamp.verisign.com/scripts/timstamp.dll />
(that isn't a typo - "timstamp.dll" is 8.3 format).
If you have a Globalsign cert,
I wonder when running a patch bundle how the patch bundle (acatually the
MSP) knows what is the install folder used by the RTM?
Looks like we are missing this values in the MSP and many of the
registration we do use a directory defined
in wix msp project
Thanks in advance
--
View this mes
Your application binaries aren't stored in the MSI. Your applications binaries
are stored in a Cabinet file. You can choose to embed this Cabinet in the MSI
itself (by setting the EmbedCab attribute on your Media elements) so you and
your users never actually see anything resembling a .cab file
Thanks.
I understand the "SignMsi" element, but the "SignCabs" description is not
what I'd expect. It reads like it is used to sign "external" CAB files,
not for signing our application's binaries stored within the msi.
Though, I guess I could change the suggested command-line (see below) to
sig
I see that msiexec returns 1638 if the usual MajorUpgrade tag does its stuff
and prevents a downgrade. Is there any way to distinguish between the case that
the MajorUpgrade did nothing because the versions were equal versus a version
strictly less than the already installed version was attempte
Awesome, thanks!
So for anyone else here is what i did created a PropertyGroup with the
paths to WixToolPath
$(WorkingFolder)\..\tools\wix\3.7.1124.0\
$(WixToolPath)Wix.targets
$(WixToolPath)wixtasks.dll
Then
It works like a charm.
On Tue, Oct 22, 2013 at 1:14 PM, John Ludlow wrote:
> T
Through a mixture of trial and error we identified 6 properties that we
needed to provide. We actually do this on the msbuild command line which
calls our solution build rather than a .proj file but the concept is the
same.
WixToolPath=g:\BuildSoftware\Wixv3.6.3303.0\
WixTasksPath=g:\BuildSoft
How would i set WixToolPath, WixTargetsPath and WiXTasks path from another
proj file (not wixproj)?
Right know i have another project.proj with
But would like to set paths to Wix binaries from this proj so that when
it's build from cmd (build server) it uses Wix that i have checked in, and
This is covered on the "insignia" page in the docs ->
http://wixtoolset.org/documentation/manual/v3/overview/insignia.html
You'll need to manually add those Elements to the relevant .wixproj as last
time I checked there were no fields for them in the project view in Visual
Studio.
Palbinder Sa
It may well do that but that makes no difference to the end user as at the
point it's downloading the file, the bundle is running from the users TEMP
directory.
The issue is that if before I run the bundle, I have the mpi_x64.msi in the
redist directory (along with the .NET 4.0 installer) the bu
Hi all,
I got a bit confused when developing a custom BA using MFC.
I've created a UI thread to show the installer UI, and will call the
engine's method from this UI thread.
Now there are two thread using the same engine, from the BA class and the
UI.
Should I protect the call with a lock? O
Hello everybody,
I put the logs on dropbox here:
https://www.dropbox.com/s/ket07aq5wcbb6kc/wixlogs.rar
Thank you for your help, it is very much appreciated
Best
Edmondo
-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: 21 October 2013 20:37
To: General discuss
34 matches
Mail list logo
