See these blog posts. Both of these have a note about progress on 3.10
https://www.firegiant.com/blog/2015/6/2/wix-online-meeting-68-highlights/
https://www.firegiant.com/blog/2015/6/16/wix-online-meeting-70-highlights/
On 22 June 2015 at 17:55, Rob Mensching r...@firegiant.com wrote:
PS: WiX
And a slightly more recent one:
http://www.wrightfully.com/part-1-of-writing-your-own-net-based-installer-with-wix-overview/
On 28 February 2015 at 12:09, John Ludlow john.ludlow...@gmail.com wrote:
Here's some links to articles about managed BAs:
http://blogs.msdn.com/b/heaths/archive/2011
action concept and how properties get read and set?
This was just a stab at what I thought would work.
Jeff
-Original Message-
From: John Ludlow [mailto:john.ludlow...@gmail.com]
Sent: Thursday, February 26, 2015 2:33 PM
To: General discussion about the WiX toolset.
Subject
When you say not working, what do you mean exactly? Is it just not
calling your CA, not finding the file, not getting any results, or is it
throwing an exception?
Here are some things you can try:
Check whether there any evidence in the log that the custom action has been
called, and what the
properties get read and set?
This was just a stab at what I thought would work.
Jeff
-Original Message-
From: John Ludlow [mailto:john.ludlow...@gmail.com]
Sent: Thursday, February 26, 2015 2:33 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] using
We have the following code in our Run method:
#ifdef DEBUG
Debugger.Launch();
#endif
When we compile as debug and then run the bundle, we get a prompt to attach
a debugger from this Debugger.Launch() call. On the dev box (with Visual
Studio installed) this would normally be a list of
I saw some install failures when I tried this but this may have been down
to some incorrect handling in my custom BA. I haven't tried this with a
package based on the WixStdBA
You will also get the child package listed as an entry in the ARP because
there's no way for the parent bundle to tell
Do you mean that if you install the bundle, then uninstall the packages
individually (not using the bundle) then the bundle is still registered?
If so, that's expected, and no there's no action in the bundle that gets
invoked if you uninstall each package outside the bundle.
On 3 October 2014
Pay attention to when these actions are sequenced. In particular, as the
linked article mentions, any action that relies on these conditions should
be sequenced after CostFinalize.
On 13 May 2014 23:03, b.ras...@leonit.nl wrote:
Dit mailadres is niet meer in gebruik. Mail kan je voortaan
Hi,
When I add a reference to WixUtilExtension in my WiX project, this is what
gets added to the .wixproj:
ItemGroup
WixExtension Include=WixUtilExtension
HintPath$(WixExtDir)\WixUtilExtension.dll/HintPath
NameWixUtilExtension/Name
/WixExtension
/ItemGroup
When my colleague
This may be a silly question, but have you also cleared out your temp
directories? Also, did you
I think it should be possible to export the DLL using Orca to a file on
disk, and then examine it to see what exported functions it has (say, with
Dependency Walker). This should settle the question
That's probably because the MSI is running in the just-a-progress-bar mode
during uninstall. MSI message boxes are being suppressed.
On 19 March 2014 22:56, Pavan Konduru pavan.kond...@accelrys.com wrote:
Did you declare the custom action in the .wxs file?
-Original Message-
From:
With regard to creating bootstrapper applications, the official
documentation is a little lacking but here are some resources which may
help:
http://bryanpjohnston.com/2012/09/28/custom-wix-managed-bootstrapper-application/
You would need to define the table schema using the CustomTable element.
Try using dark.exe on an msi which has thay merge modules and seeing what
CustomTable elements you get in the output.
Hope that helps
On 11 Mar 2014 02:15, Dmitry Nechaev
dmitry.nech...@objectconsulting.com.au wrote:
Hi
http://stackoverflow.com/questions/1805405/find-vista-language-using-wix
This SO question might be helpful
On 1 Mar 2014 10:15, Bin Yin ybdes...@gmail.com wrote:
is there any logic in WiX as:
if (OSLanguage==en-US)
{
copy file1 to dir1
}
else if(OSLanguage==zh-CN)
{
copy file2
No problemo :)
On 26 February 2014 13:17, Steven Ogilvie steven.ogil...@titus.com 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
BTW, you did mention the scheduling in your original mail - I missed it. My
bad.
On 26 February 2014 15:39, John Ludlow john.ludlow...@gmail.com 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
Um, yes.
Have you considered using *afterInstallExecute *or *afterInstallExecuteAgain
*instead?
On 26 February 2014 15:49, faujong fiefie.ni...@gmail.com wrote:
Hi John,
No existing file is because prior to it the installation removed the file
MSI (s) (00:9C) [09:59:20:624]: Executing op:
Is this just for logging purposes? Is the normal MSI log not sufficient?
If it's not, then depending on your situation, there's a number of options:
* The XmlFile element in the Util extension can be tied to a component and
update a target file when that component is installed or uninstalled.
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
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 fiefie.ni...@gmail.com
I think you may need to use something like this:
http://wixextba.codeplex.com/
On 13 February 2014 11:21, Hans De Groot hans.degr...@nice.com wrote:
Hello,
I'm trying to a second location + browse button the standard bootstrapper
application. I currently have this:
Page Name=Options
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
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
binaries off to a signing service to get
signed. Never saw two organizations implement signing the same way.
sigh/
-Original Message-
From: John Ludlow [mailto:john.ludlow...@gmail.com]
Sent: Monday, December 2, 2013 10:09 AM
To: General discussion about the WiX toolset
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
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
for
encapsulating 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 to each bundle
.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, December 2, 2013 8:07 AM
To: General discussion about the WiX
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 documentation, but I tend to
prefer to stay out of those because any changes to the .wixprojs
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
From: John Ludlow
Sent: Monday, December 02, 2013 9:49 AM
To: General discussion
the 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. sigh/
-Original Message-
From: John Ludlow [mailto:john.ludlow...@gmail.com]
Sent
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
That should have read:
If you make this change, you can also remove the following line:
RegistryValue Root='HKCU' Key='Software\[Manufacturer]\[ProductName]'
Type='string' Value='' KeyPath='yes' /
On 19 November 2013 08:34, John Ludlow john.ludlow...@gmail.com wrote:
That's because
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 referring to this
path:
C:\Program Files (x86)\WiX Toolset v3.7\bin\trunkdb.wxs
This probably shouldn't
/aa368961.aspx and
ICE48http://msdn2.microsoft.com/en-us/library/aa368977.aspxhappy. 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 14:05, John Ludlow wrote:
That should have read:
If you make
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:
Directory Id='DesktopFolder' Name='PFiles'
I haven't tried that though, so I'm not 100% sure. If not, you can also
try a custom action which
am really stuck
and any help would be much appreciable. Let me know if you are on Skype,
that would be helpful.
Regards,
SuvraJyoti
Regards,
SuvraJyoti
On 15-11-2013 19:19, John Ludlow wrote:
I think you're getting confused between two separate issues. If you're
getting the ICE
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
suvrajyo...@contata.co.insuvrajyo...@contata.co.in To:
John Ludlow john.ludlow...@gmail.com
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 files in the same.
Regards,
SuvraJyoti
On 18-11-2013 19:00, John Ludlow wrote:
Do those files exist at compilation time? They are C
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
I'd recommend this book:
http://www.amazon.co.uk/WiX-3-6-Developers-Windows-Installer-ebook/dp/B009YW82A0/ref=sr_1_1?ie=UTF8qid=1383827565sr=8-1keywords=wix
It covers both Windows Installer using WiX, and bundles using burn and
custom bootstrapper applications.
On 6 November 2013 21:42, Nick
...@joyofsetup.com 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 WixStdBA.
--
sig://boB
http://joyofsetup.com
that registry entry or not.
Thanks anyway
On 26 Oct 2013 03:35, santhosh yalamuri santhu@gmail.com wrote:
When the user selects another folder the variable is updated.
On 25 Oct 2013 00:47, John Ludlow john.ludlow...@gmail.com wrote:
Thanks for that
Does that prevent the user from selecting
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
Value=/
On Thu, Oct 24, 2013 at 3:31 PM, John Ludlow john.ludlow...@gmail.com
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 server.
During the MSI install
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\
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
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/2013
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 phildgwil...@gmail.com wrote:
Your copy custom action is immediate - that means it will always happen
before any files are
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
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
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
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
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 nkshirsa...@gmail.com wrote:
Hi John,
I'm doing it this way as of now ..
InstallExecuteSequence
Custom Action=RunInstallScript
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
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)
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 toolset.
Subject: Re: [WiX-users] Component Rules
As long
RemoveFiles may also get around that issue.
On 29 August 2013 15:28, tyler.w.r...@accenture.com 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 use
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 Wilson
On Thu, Aug 29, 2013 at 7:00 AM, John Ludlow john.ludlow...@gmail.com
wrote:
Of course
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
and get 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
To: General discussion for Windows
Glad I could help
On 28 August 2013 14:13, Simon Gerhold simon.gerh...@cetis.si 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 [mailto:john.ludlow
You would need an immediate custom action to read the .config file, find
the appropriate connection string, and set its value to a property.
CustomAction Id=MyAction
ExeCommand=cmd.exe /C MyDatabaseInstaller [CONNSTR]
Execute=deferred
Return=check /
If
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 pally.sand...@iesve.com wrote:
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
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 July 2013 17:44, John
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
@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
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
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
.
Thanks for your help
On 30 May 2013 20:43, John Ludlow john.ludlow...@gmail.com 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 phil.wil...@mvps.org wrote:
Have a look at the vital
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
package.
GenerateBootstrapper ApplicationFile=MyInstaller.msi
ApplicationName=My App BootstrapperItems=@(BootstrapperFile)
ComponentsLocation=Relative CopyComponents=True
OutputPath=$(OutputPath) Path=..\..\Bootstrapper /
Mark Freedman
-Original Message-
From: John Ludlow
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
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, 2013 6:08 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Error 1308
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 afor...@cmu.edu wrote:
Now I'm
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
May 2013 11:36, Benjamin Mayrargue benja...@vapolia.fr wrote:
100% understood !
This means a 'bundle' creates a msi bootstrapped in an exe.
B.
2013/5/29 John Ludlow john.ludlow...@gmail.com
I think where you're getting confused is that there are more than one
type
of variable in WiX
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:
Control Id=myEdit Type=Edit Property=IP_ADDRESS Height=17 Width=
100 X=50 Y=50 Indirect=yes Text=[IP_ADDRESS]/
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
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 davidm...@omprompt.com wrote:
Just for a bit of extra
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
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
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
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 t...@scanvaegt.dk wrote:
Hello,
I am
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
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:
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 hoshis...@gmail.com wrote:
Thanks, I think I have it working!
On Thu, Apr 18, 2013 at 2:13 PM, Alain Forget
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
Forgot to mention - I'm using WiX 3.6
On 2 April 2013 11:59, John Ludlow john.ludlow...@gmail.com 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/2013/01/part-1
.
On Tue, Apr 2, 2013 at 4:08 AM, John Ludlow john.ludlow...@gmail.com
wrote:
Forgot to mention - I'm using WiX 3.6
On 2 April 2013 11:59, John Ludlow john.ludlow...@gmail.com wrote:
Hi,
I've been looking at developing a custom managed bootstrapper
application,
based
Nice, I'll play with that tomorrow.
Thanks
On 2 April 2013 19:02, tom tomer.d...@intergraph.com 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
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
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:
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
1 - 100 of 158 matches
Mail list logo
