Hi,
My installer has two projects - a Setup Project which emits an .MSI and
contains install metadata, and a Setup Library Project which emits a
.wixlib which contains install components. The latter makes use of a
compiler extension which generates an MSI table based on some child
elements of the
Hi Blair,
Ok, does that mean I've encountered an error in the book, then? The book
suggests adding the wixlib to the extension, and I've done that (means I
should only have to reference the extension, not the wixlib, right?).
However, the sample code in the book does not come with a test install
Blair,
Yes I have the tables.xml correctly referenced as described above. The
error has disappeared. If this pattern is idiomatic for this type of
extension, I'm happy.
My points above were
* The only widely available documentation for this appears to have an
error
* It would have been b
Yup, did that - that's how I know there's no test installer for it.
When I removed that line, the install compiled but without the action.
I'll add a test install to the sample, and see what I get. I just haven't
had time to do that today, unfortunately.
On 10 July 2013 17:47, Nick Ramirez wro
@Nick:
Yes, I'm trying to use the extension in a library which is then used in a
setup project. The resulting project relationships would be something like
this:
https://docs.google.com/file/d/0BzqWyEdx-NBBeDM5ZlJGejRoNE0/edit?usp=sharing
The reason for this is that the setup project is just meta
have been safely ignored, and b) the error
message didn't really point to the reference on the component library
project. It was only when I was ready to give up and abandon the
'wixlib-in-the-dll' idea as a bad job that I spotted this extra reference.
Thanks for the help
On 11 J
Agreed, that's really the only complete reference source for WiX 3.6, and
there's quite a lot that you can only really learn via the book. Be careful
though as I saw a bogus addition flying around on Amazon UK (it's gone now
so maybe it was just a mistake).
In the book, your requirements above mea
Also,
http://msdn.microsoft.com/en-us/library/aa370905(v=vs.85).aspx#operating_system_properties
For example, to tell the difference between server and workstation editions
of Windows, you can use MsiNTProductType.
On 23 August 2013 13:58, Pally Sandher wrote:
> http://msdn.microsoft.com/en-u
Does this ever work or is it failing consistently? If it's intermittent
then unreliable access to that location could still be the cause.
One other question is what does D: map to? You mention network, which makes
me wonder if this is a mapped drive. Does this work if you use an entirely
local pat
You would need an immediate custom action to read the .config file, find
the appropriate connection string, and set its value to a property.
If you're using WiX from Visual Studio, you can go to File > New Project,
and choose Windows Installer XML > C# Custom Action Project. (Or C++ if you
prefe
You have a couple of options:
Firstly, there's the MSI Cleanup Utility
http://gallery.technet.microsoft.com/MSI-cleanup-utility-3889c8db
This is an old tool which I thought had been retired, but it's come in very
handy. Note that this will not perform any uninstall operations or any MSI
logic at
your users (or write a
> stub that) runs it from the command line with the repair and recache msi
> options.
>
> msiexec /fv your.msi /l*v log.txt
>
>
>
> -Original Message-
> From: John Ludlow [mailto:john.ludlow...@gmail.com]
> Sent: 28 August 2013 10:34
>
Glad I could help
On 28 August 2013 14:13, Simon Gerhold wrote:
> Thanks John & David, I used John's third option with orca.exe (I just
> deleted the problematic custom action and all is good).
>
> Thanks :)
>
> -Original Message-
> From: John Ludlow [m
Actually there's not much difference as you get to the same place anyway. A
version of the MSI in your cache that doesn't have the error and can be
upgraded.
The issue you might run into with modifying your package and doing a minor
upgrade is that if you sign your MSIs you won't just be able to e
If the file is packaged inside the MSI, how would anything copy it before
the InstallFiles action?
The only scenario that makes sense here (as far as I can see) is that
you're in an upgrade situation, and you want to copy the version of the
file you're upgrading from to the temp folder and read so
Is the issue that the FilesInUse dialog is popping up before your service
is stopped and declaring files in use when those files will be unlocked
when the service stops?
It's unfortunate but all the information related to whether you are doing a
removal or not is discovered at that point. In theor
Well, it probably won't do what you're expecting. By the time RemoveFiles
runs, the install has already decided it won't install those files, so what
will most likely happen is it will remove the file but not install the new
version.
A trick (well, a horrible hack, really) I've used is called vers
Well, it wouldn't because the REINSTALL property is set during repair and
you're conditioning on NOT REINSTALL.
On 29 August 2013 14:19, nkshirsagar wrote:
> Hi John,
>
> I'm doing it this way as of now ..
>
>
> NOT
> Installed
>
>
> Installed
> AND (NOT REINSTALL)
>
As long as there is an appropriate file to use, I agree, although really it
has the same result. It wouldn't be appropriate to make them a companion of
a file they're unrelated to as that would introduce a bogus dependency and
if that other file ever disappeared, then you could introduce some nasty
Check the logs. That should tell you what REMOVE and REINSTALL are being
set to, and when they are being set. Look for lines like this:
MSI (s) (04:4C) [05:39:56:736]: Command Line: REMOVE=ALL
CURRENTDIRECTORY=C:\Windows\system32 CLIENTUILEVEL=2 CLIENTPROCESSID=1768
or this:
MSI (s) (64:48) [06:
S 66227
> Office: 913-341-3434 x791011
> jocoo...@jackhenry.com
> www.jackhenry.com
>
>
>
>
> -Original Message-
> From: John Ludlow [mailto:john.ludlow...@gmail.com]
> Sent: Thursday, August 29, 2013 8:35 AM
> To: General discussion for Windows Installer XML to
Execute action after
RemoveFiles may also get around that issue.
On 29 August 2013 15:28, wrote:
> @John Ludlow: Ok I was following what I found in a wix email chain by Chad
> Peterson from 2011. The post is below as well as the url to the entire
> email chain.
> Another option is to u
toolset.
> Subject: Re: [WiX-users] Component Rules
>
> If they're not being replaced because of the file modification rules, then
> you could write a custom action to make the creationdate and modifydate
> identical, and run it early before InstallValidate.
>
> Phil Wil
Be aware that if your custom action gets any properties, then you'll need
to push those through by using CustomActionData.
On 18 September 2013 19:07, Phil Wilson wrote:
> Your copy custom action is immediate - that means it will always happen
> before any files are actually copied. If you need
Wix's own bootstrapper is done this way, so you can use that as a sample.
There's also a tutorial with code samples here:
http://bryanpjohnston.com/2012/09/28/custom-wix-managed-bootstrapper-application/
(uses
the MVVM-light framework).
On 19 September 2013 10:23, Ravishankar <
ravishankar.krish
Here's the the link to the publisher's page for that book
http://www.packtpub.com/windows-installer-xml-3-6-developers-guide/book
On 19 September 2013 11:09, Ravishankar <
ravishankar.krishnasw...@idsnext.com> wrote:
> Hi Kobus,
> Please send me the Link.
>
> Thanks and Regards
> Ravi
> On 9/19
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
Hi all,
We have an MSI for a client application which, if you have the server
installed on the same system, must be installed in the same directory as
the server.
During the MSI install wizard for the client application, we use AppSearch
to detect whether the server component is installed. If it
ot;"/>
>
>
> On Thu, Oct 24, 2013 at 3:31 PM, John Ludlow >wrote:
>
> > Hi all,
> >
> > We have an MSI for a client application which, if you have the server
> > installed on the same system, must be installed in the same directory as
> > the
hether we found that registry entry or not.
Thanks anyway
On 26 Oct 2013 03:35, "santhosh yalamuri" wrote:
> When the user selects another folder the variable is updated.
> On 25 Oct 2013 00:47, "John Ludlow" wrote:
>
> > Thanks for that
> >
> > Does
son wrote:
> On 26-Oct-13 05:15, John Ludlow wrote:
> > I don't think the standard bootstapper application's theming is capable
> of
> > that kind of customisation.
> That's correct. It would have to be a feature of WixStd
I'd recommend this book:
http://www.amazon.co.uk/WiX-3-6-Developers-Windows-Installer-ebook/dp/B009YW82A0/ref=sr_1_1?ie=UTF8&qid=1383827565&sr=8-1&keywords=wix
It covers both Windows Installer using WiX, and bundles using burn and
custom bootstrapper applications.
On 6 November 2013 21:42, Nick
I think you're getting confused between two separate issues. If you're
getting the ICE error, then that would stop the build from successfully
completing. You may be using an out of date version of your installer.
Because of that, I would suggest that you do the following
1. Resolve the ICE issue
6)\WiX Toolset v3.7\bin\trunkdb.wxs(1119) : error LGHT0267 :
> Found orphaned Component 'cmp5FAA008684E68756F59591139AA72C60'. If this
> is a P
> roduct, every Component must have at least one parent Feature. To include
> a Com
> ponent in a Module, you must include it dire
Any updates on the below issue. I am still stuck there.
>
> Regards,
> Suvra Jyoti
> Original Message
> Subject: Fwd: Re: [WiX-users] Referring to fragments Date: Mon, 18 Nov
> 2013 15:06:38 +0530 From: Suvrajyoti Panda
> To:
> John Ludlow
matches correctly) or write some build code to tweak the contents of
> this file." if this helps.
>
> Moreover it is not that the error is being shown foll all the files in the
> db directory . It is showing for about 150 files in the db directory. There
> are a total of 379 fil
That should have read:
If you make this change, you can also remove the following line:
On 19 November 2013 08:34, John Ludlow wrote:
> That's because of this:
>
>
>
> This will put files on the users desktop - are you sure that's what you
> want? (Hin
i need to change this file to registry key when generating this file
> from heat? Please suggest as to what the error could be for?
>
> Regards,
> Suvra Jyoti
>
>
> On 18-11-2013 21:31, John Ludlow wrote:
>
> Yeah I didn't explain that path thing very well. I was re
icrosoft.com/en-us/library/aa368961.aspx> and
> ICE48<http://msdn2.microsoft.com/en-us/library/aa368977.aspx>happy. So can i
> ignore those errors and move ahead?
>
> How can i get my directory created to c:\[FolderName]\ ?
>
> Regards,
> SuvraJyoti
>
>
> On 19-11-2013
; EnergySolutionsInternational directory also gets removed. Do you think that
> should be the behaviour.?
>
>
> On 19-11-2013 15:44, John Ludlow wrote:
>
> In theory, just removing this line should do it:
>
>
> I haven't tried that though, so I'm not
If you modify WiX itself, then I'd argue that it's actually in your best
interest to contribute the changes back anyway, regardless of whether you
distribute those binaries. That way, they can be included in future
versions of WiX and you don't have to re-apply the changes every time you
upgrade th
Hi,
We're writing an installer using a bundle to chain two MSIs together. The
bundle should be signed (we generally sign installers and EXEs and DLLs).
Currently, we're using WiX 3.6 (we currently use Visual Studio 2008, and
3.7 didn't support that version of Visual Studio).
We've discovered the
lating all the custom logic for their build.
>
> -Original Message-
> From: John Ludlow [mailto:john.ludlow...@gmail.com]
> Sent: Monday, December 2, 2013 4:23 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Signing bundles - changes needed
ld do that. I tend to add an explicit .props/.targets file to the
> .wixprojs myself but you have options with MSBuild.
>
> Documentation improvements are always appreciated.
>
> -Original Message-
> From: John Ludlow [mailto:john.ludlow...@gmail.com]
> Sent: Monday, Dec
nt’s needs and customs).
>
>
>
>
>
>
> -Blair
>
>
>
>
>
> From: John Ludlow
> Sent: Monday, December 02, 2013 9:49 AM
> To: General discussion for Windows Installer XML toolset.
>
>
>
>
>
> I see - that was the impression I got from the
there’s a preference to one over the other. Each has its
> own costs and risks. Whichever works better in your environment. MSBuild is
> flexible in that regard. (What I do with my clients tends to vary based on
> the client’s needs and customs).
>
>
>
>
>
>
> -Blair
>
he room with the private key at MSFT had a hand print reader. Even
> the WiX toolset submits our binaries off to a signing service to get
> signed. Never saw two organizations implement signing the same way.
>
> -Original Message-
> From: John Ludlow [mailto:john.ludl
t; > On 2 Dec 2013 18:24, "Rob Mensching" wrote:
> >
> > > My experience is that you really want your private key under lock and
> key.
> > > I heard the room with the private key at MSFT had a hand print reader.
> Even
> > > the WiX toolset submits
I'm not seeing any adverts. On Chrome I do have AdBlockerPlus, but it
didn't report a blocked popup, and when I disabled it and refreshed I
didn't see anything.
Of course, it might be that you're hitting a different server than I am.
On 3 December 2013 13:44, Christopher Painter wrote:
>
> Is
Hi,
I'm writing a bundles to chain some installs together. Currently this is
WiX 3.6, though I'll be considering an upgrade to 3.8 at some point. The
bundle uses the RtfTheme theme, customized with the
bal:WixStandardBootstrapperApplication/@ThemeFile attribute.
My question is this: Is there a wa
JCHoover responded to that SO question.
You should also check out these discussion threads on this forum:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Signing-bundles-changes-needed-to-each-bundle-wixproj-td7591050.html
http://windows-installer-xml-wix-toolset.687559.n2.nabble.c
Hi,
It's really up to you, but there's a couple of things to consider:
* Would the reference data ever be installed without the main application?
* How do customers get hold of your application and the reference
data, and relevant updates?
* Have you looked at patching?
Normally, in your si
That would only work at build time, if you were compiling an x86 MSI
and an x64 MSI.
I think you just need to extend your condition to something like this:
Installed OR (SQLSYNCX64SEARCH > "0" AND VersionNT64) OR (NOT VersionNT64)
Installed OR (SQLSYNCX86SEARCH > "0" AND NOT VersionNT64) O
elp... the below from John works like a charm!
> Can't get my head around the logic but it works...
>
> Steve
>
> -Original Message-
> From: John Ludlow [mailto:john.ludlow...@gmail.com]
> Sent: December-19-12 9:24 AM
> To: General discussion for Windows Installer XML to
An upgrade would look like a fresh install unless you've specifically
authored UI to handle upgrades. How many entries for your application
are there in the Programs and Features panel? If there's 2, then you
know you have a problem.
On 20 December 2012 20:30, Steven Ogilvie wrote:
> No I only c
I believe it's a bootstrapper application created using Burn. Heath
Stewart wrote about this on his blog (he talks more about the Visual
Studio 2012 install than WiX's install, but the principle is the
same.)
http://blogs.msdn.com/b/heaths/archive/2011/10/28/introducing-managed-bootstrapper-applic
On 16 January 2013 09:44, Bruce Cran wrote:
> On 16/01/2013 09:26, Rob Hamflett wrote:
>> Doesn't this just bring back DLL Hell? It seems that we have to
>> completely abandon using merge modules for runtime deployment. How is a
>> user performing a command line installation or repair supposed t
The first thing you need to do is read these two topics:
* Aaron Stebner on file replacement :
http://blogs.msdn.com/b/astebner/archive/2005/08/30/458295.aspx
* MSDN docs: http://msdn.microsoft.com/en-us/library/aa368267(v=vs.85).aspx
If the files in question are versioned files (dlls and exes)
I assume the requirement might be for a live tile, like the one that
scrolls through photos every few seconds.
On 4 February 2013 15:51, The Ouizard wrote:
> I don't know much about Windows 8, but isn't the Start Screen basically like
> the Start Menu, such that if you put any shortcuts as
> you
>From my experience, the current license on WiX 3.6+ is fine (there
were some issues with the 2.0 license which prevented us from using
any WiX extensions because it effectively means distributing code from
the WiX project), but your legal situation may be different.
Does your company have a copyr
ublish that back. If you go off and create your own installer using the
> WiX toolset, all your code is your own. That's the intention and remember I
> am not a lawyer.
>
>
> On Fri, Feb 15, 2013 at 2:58 AM, John Ludlow wrote:
>
>> >From my experience, the current license
The issue is that the two directories below actually resolve to
TARGETDIR in the directory table, because if you don't specify a Name
attribute, then it's essentially the same path as the parent
directory.
ade up default value, then
have the directory property set to the real path during install.
Hope that helps
John
On 7 March 2013 17:14, Sean Farrow wrote:
> Hi John,
>
> Can I specify the property in the nae attribute.
> Regards
> Sean.
>
> -Original Message-
> From:
See this:
http://msdn.microsoft.com/en-us/library/ee332502.aspx
Apparently it's a bad idea to run VSIXInstaller from an MSI.
On 13 March 2013 15:31, Rob Mensching wrote:
> That error means the VsixInstaller failed. Doesn't the VsixInstaller create
> a log file somewhere? That's your best bet.
>
Dangit Chris, beat me to it :)
Switch on verbose logging (http://support.microsoft.com/kb/314852),
and look for something like this:
MSI (c) (14:28) [11:56:32:469]: Doing action: FindRelatedProducts
Action 11:56:32: FindRelatedProducts. Searching for related applications
Action start 11:56:32: Fi
That would probably explain it as well.
By default, I believe WiX will use a property called
WIX_UPGRADE_DETECTED. Again, remember that WiX is just a way of
creating MSI files, so that MajorUpgrade element creates entries in
the Upgrade table in the install. One of the columns in this table
define
...And that's not necessarily a bad thing, since major upgrades work
just fine for most scenarios. However, you probably need to include a
check against your upgrade property (which, if you're just using
, is probably WIX_UPGRADE_DETECTED).
On 22 March 2013 17:12, David Watson wrote:
> Product I
That's true in theory but in practice it's often better to change it
every build. This simplifies the upgrade semantics (upgrade is an
upgrade is an upgrade, rather than worrying about whether it's a small
update, minor upgrade or major upgrade) and makes it much easier to
test that your product ca
Hi,
I've been looking at developing a custom managed bootstrapper application,
based on the examples in the following articles:
http://wrightthisblog.blogspot.co.uk/2013/01/part-1-of-writing-your-own-net-based.html
http://bryanpjohnston.com/2012/09/28/custom-wix-managed-bootstrapper-application/
Forgot to mention - I'm using WiX 3.6
On 2 April 2013 11:59, John Ludlow wrote:
> Hi,
>
> I've been looking at developing a custom managed bootstrapper application,
> based on the examples in the following articles:
>
>
> http://wrightthisblog.blogspot.co.uk/201
gt; "close when complete"). That means all the customizations you can do to
> wixstdba, you can do to the mbapreq.
>
>
> On Tue, Apr 2, 2013 at 4:08 AM, John Ludlow >wrote:
>
> > Forgot to mention - I'm using WiX 3.6
> >
> >
> > On 2 April 2013 11:5
Nice, I'll play with that tomorrow.
Thanks
On 2 April 2013 19:02, tom wrote:
>
> Also search in this forum for /AutoDebugAttacher/ class
> This is a utility class created by one of the forum members which
> automatically attach the active debugger
> To the bootstarpper
>
>
>
>
> --
> View this
<> is also the syntax in Visual Basic, and VB / VBA has always had strong
ties to Office, which is where MSI originated from IIRC.
On 18 April 2013 13:35, Hans ter Horst wrote:
> Thanks, I think I have it working!
>
>
>
> On Thu, Apr 18, 2013 at 2:13 PM, Alain Forget wrote:
>
> > <> is the MyS
You probably have the action sequenced incorrectly. Make sure it comes
after CostFinalize, because it's only at this point that the install
understands the parent-child relationship between the directories.
Also, read this to see whether the issues described apply to you:
http://blogs.msdn.com/b/h
I don't think the version number of a binary is taken into account when
analysing differences for byte-level patches. Try setting
WholeFilesOnly=yes (
http://wix.sourceforge.net/manual-wix3/wix_xsd_patchcreation.htm).
On 2 May 2013 10:31, Thomas Due wrote:
> Hello,
>
> I am trying to grasp the
It would be interesting, but I'm struggling to imagine out how the syntax
would work in your .wxs code if you were able to override this
behaviour. You could have two integer attributes on each package (one for
install order and one for uninstall order) but I bet that would be hard to
maintain if y
Hi Natalie,
Have you seen the tutorial at http://wix.tramontana.co.hu/? You may want to
emulate this, since it's a good tutorial for general use, but you may want
one tailored to your team and your product. You should include topics on
things that you use (for example, Burn, patching and early REP
This is probably because your CA is scheduled as immediate, rather than
deferred. You need to set Execute=deferred, and Impersonate=no on your
CustomAction element.
However, this presents a problem - deferred CAs do not get access to
properties. Instead, you need to use the CustomActionData specia
You should be able to do something along these lines:
foreach (var k in session.CustomActionData.Keys)
{
session.Log(k + " = " + session.CustomActionData[k]);
}
But you would have to have set the CA data property for that custom action,
I think.
On 20 May 2013 18:26, Freedman, Mark
Your question isn't entirely clear - do you want to have a text box for
an IP address in your install UI (which would depend on whether it's
Wix/MSI-based or Burn-based), or do you just want to include a
configuration file in your install to be installed along with your app?
Or something else...?
The simplest method is to use a text edit control:
You can also use the MaskedEdit control, with PIDTemplate set to the format
for an IP address. This will allow you to have a formatted control that
will only accept IP addresses. See the doc for that type of control:
http://msdn.microsoft.com/en
Do you have any duplicate GUIDs in your installer? Also, is the
installation path changing when you do the upgrade? (by which I mean, do
those files end up in a different folder on the target machine?)
On 23 May 2013 15:37, Dave Moss wrote:
> Just for a bit of extra information if I run the boo
I think where you're getting confused is that there are more than one type
of "variable" in WiX. Firstly, there are preprocessor variables and
condition, which are referenced like this:
$(var.VariableName)
!(var.LateBoundVariableName)
$(env.EnvironmentVariableName)
!(loc.StringID)
These a
lement?
On 29 May 2013 11:36, Benjamin Mayrargue wrote:
> 100% understood !
>
> This means a 'bundle' creates a msi bootstrapped in an exe.
>
> B.
>
>
>
> 2013/5/29 John Ludlow
>
> > I think where you're getting confused is that there are
We're looking at simply making WiX part of the toolkit you need to build
our solutions. We've tried this with some smaller projects and it's worked
really well. Developers can follow up on their own impacts, and they can
tell when they've broken the install. This increases build quality and
frees
Hi,
I have one MSI, with a bunch of compressed files in an embedded cab, and
one readme next to the install as an uncompressed file. This file is still
in the installer, it's just got the nonCompressed bit set. This is so we
can update the readme right up until release with late-breaking informati
have Visual Studio installed, or whatever puts them in the default
> Microsoft SDK package.
>
> ApplicationName="My App " BootstrapperItems="@(BootstrapperFile)"
> ComponentsLocation="Relative" CopyComponents="True"
> OutputPath="$(Outpu
Hi,
While I was looking at refactoring our wxs code, I noticed something odd.
I have a structure like this
File\File.wixproj
File.wxs
Install\Install.wixproj
Product.wxs
CustomAction1.wxs
CustomAction2.wxs
InstallExecuteSequence.wxs
(Note th
hash in the MSI
> file to not match the actual file, so turn it off for that file unless you
> are fixing the MsiFileHash table when you replace the file.
>
> Phil
>
> -Original Message-
> From: John Ludlow [mailto:john.ludlow...@gmail.com]
> Sent: Thursday, May 30, 2
I think probably using burn to chain both the JRE installer and the MSI is
the best idea.
I'm pretty sure the JRE installer is just a bootstrapped MSI, so including
it in your MSI won't work (the nested MSI transaction issue).
On 30 May 2013 21:06, Alain Forget wrote:
> Now I'm really confused
ally a big deal.
Thanks for your help
On 30 May 2013 20:43, John Ludlow wrote:
> Thanks Phil, I'll take a look when I get a chance. I have a feeling it's
> still in the hash table.
>
> Thanks again.
>
>
> On 30 May 2013 19:28, Phil Wilson wrote:
>
>> Have a
Hi all,
We have a custom action which processes rows in a custom table (the details
of this don't matter, but suffice to say some code is run for each record).
Currently we are using a CustomTable element in our wxs to implement this,
and I think we could do better with a WiX extension. I want to
@Blair: I did download WixContrib and the WiX code (which is why I know
about the existence of tables.xml). To be honest, I feel like trying to
reverse engineer the WixContrib code is a bit futile. In order to
understand it, you need to understand certain things about WiX extensions
so you know why
Unsubscribe, then:
https://lists.sourceforge.net/lists/listinfo/wix-users
On 21 June 2013 15:38, Wesley Wells wrote:
> Stop sending me this useless stuff!!!
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Friday, June 21, 2013 9:30 AM
> To: General
I think you may need to use something like this:
http://wixextba.codeplex.com/
On 13 February 2014 11:21, Hans De Groot wrote:
> Hello,
>
> I'm trying to a second location + browse button the standard bootstrapper
> application. I currently have this:
>
> FontId="2">#(loc.OptionsH
Have a read of this:
http://msdn.microsoft.com/en-us/library/aa370531(v=vs.85).aspx
Now, before you do your upgrade, have a look at the file's modified and
creation dates. If they match, then MSI takes that as a signal that they
can be overwritten (because it sets those dates to the same value du
Follow the instructions here:
http://support.microsoft.com/kb/223300
The simplest way for logging a single session is to start the installer
with the /l switch
msiexec /i c:\path\to\myinstall.msi /l*v c:\path\to\myinstall.log
On 25 February 2014 23:56, fiefie.niles wrote:
> Where can I g
No problemo :)
On 26 February 2014 13:17, Steven Ogilvie wrote:
> Ravi,
>
> Please provide verbose logging of where it is failing...
>
> http://support.microsoft.com/kb/223300
>
> The simplest way for logging a single session is to start the installer
> with the /l switch
>
> msiexec /i c:\pa
BTW, you did mention the scheduling in your original mail - I missed it. My
bad.
On 26 February 2014 15:39, John Ludlow wrote:
> Aha!
>
> MSI (s) (00:64) [09:59:21:043]: File: C:\Program
> Files\WixWindowsService2012\WixWindowsService2012.exe.config; To be
> installed;
Aha!
MSI (s) (00:64) [09:59:21:043]: File: C:\Program
Files\WixWindowsService2012\WixWindowsService2012.exe.config; To be
installed; Won't patch;No existing file
MSI (s) (00:64) [09:59:21:043]: Source for file
'WixWindowsService2012.exe.config' is compressed
So why is there "No existin
1 - 100 of 183 matches
Mail list logo
