Following is the content of log file
[0EDC:0810][2012-04-27T11:14:00]: Burn v3.6.2221.0, path: C:\Documents and
Settings\All Users\Application Data\Package
Cache\{afd874f6-129a-4fc6-9646-284d80072674}\WiX36.exe, cmdline:
'/uninstall'
[0EDC:0810][2012-04-27T11:14:00]: Setting string variable 'WixBu
I fundamentally agree with you. However, building the code for a particular
platform is the easiest part of the problem. Keeping the code working
(since the platforms differ in subtle ways) is the real challenge.
Personally, supporting unsupported platforms is very low on my priority
list. I have
Self-healing is a feature of the Windows Installer. There are several ways
to get it to kick in. The most common is through Advertised entry points.
You might decompile your old VS setup/deployment project and see if it has
things Advertised or otherwise organized differently.
You could also get
Hello again
When I used to create my msis through Visual Studio Setup and Deployment
projects then these installers protected the files that got installed i.e.
if I installed the application and then manually deleted a file (such as an
included image content file) then when the next time the main
Is that not the wrong question? Rather than getting caught up in the
ins and outs of which version to support, why not adopt methods that
remove the decision entirely?
Have you considered using CMake, for example, which generates build
files for a vast range of build platforms (including VS 6 - 1
No, we don't forget that. However, at some point you have to trim your tail
or you end up with an enormous support burden that prevents you from moving
forward.
One of the big questions for us in WiX v3.7 is how many versions of VS
should we support? It is expensive to keep VS2005 and VS2008 worki
At least until the documentation is updated to be correct.
On Sun, Apr 29, 2012 at 2:54 AM, Neil Sleightholm wrote:
> Actually I looked at the source and realised the problem. If you don't
> specify a protocol it assumes the file is local, therefore the correct
> syntax is:
> Id="WixStan
'Out of support' is just a marketing term. It doesn't mean it
magically stops working. People forget that often.
Alex
On 29 April 2012 08:06, Rob Mensching wrote:
> NOTE: Win2k was out of support before WiX v3.6 even started development. We
> obviously don't test the code there so I really hav
Actually I looked at the source and realised the problem. If you don't specify
a protocol it assumes the file is local, therefore the correct syntax is:
Must remember - use the source Luke!
Neil
-Original Message-
From: Rob Mensching [mailto:
Oh, sorry, I answered the question the wrong way. Use LicenseUrl attribute
on the WixStandardBootstrapperApplication element and use the same relative
path that you use to add the Payload.
On Sun, Apr 29, 2012 at 1:26 AM, Neil Sleightholm wrote:
> Not sure I explained this correctly, I don't want
I did find a work around:
I think the ideal you be if ProgramFiles64Folder returned ProgramFilesFolder on
x86 (I think this is how it works in Windows Installer).
Neil
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 29 April 2012 08:21
To: General disc
Not sure I explained this correctly, I don't want to display the licence file
on the UI (more correctly it should have been called License.htm) I want it to
be in the bundle and displayed in a browser if the user clicks the link but not
be a reference to a file on the internet (like the WiX dist
Nothing in the engine to do that so the BA would have to handle this case.
Unfortunately, there is nothing in wixstdba to handle this case today.
Seems like a bit of a gap given the way ProgramFilesFolder and the 64-bit
variant works. Feel free to open a bug.
On Tue, Apr 24, 2012 at 7:05 AM, Neil
Can you double check and make sure you are using a matching Theme with what
is in the build? The identifiers may have changed in recent builds.
That's really my only guess. There is nothing magical about the default
theme files. They are carried as is with wixstdba. If you copy them, then
you have
Unfortunately, the log file seems to have been lost in transit. Can you
place it in email. Or maybe, take a look at the log file and if there
appears to be a unique error open a bug?
On Thu, Apr 26, 2012 at 10:44 PM, Anirban Paul wrote:
> I have attached the log file. Please find the attachment.
Oh, well, this is far more advanced scenario than I thought you were trying
to accomplish.
The way I'd accomplish what you described using Burn is via slipstreaming.
You include the MSI and MSP as you have it now but with none of the
conditions. Then you have the MSI be the baseline you expect you
NOTE: Win2k was out of support before WiX v3.6 even started development. We
obviously don't test the code there so I really have no idea how much work
it will be to make any of the native code built by WiX (Burn, and
CustomActions mainly) working on Win2k.
On Sun, Apr 29, 2012 at 12:04 AM, Rob Men
If you vowed never to build WiX again, then it probably is not feasible.
Burn is in wix\src\burn (burn.build) and as Bob noted if you want wixstdba
then you'll need to build wix\src\ext\BalExtension\wixsdtba.
Both are in WiX so that will require breaking your vow.
On Sat, Apr 28, 2012 at 2:01 PM,
I would use the WixBalExtension's WixStandardBootstrapperApplication
element's LicenseFile attribute. Documentation should say something like:
"Source file of the RTF license file. Cannot be used simultaneously with
LicenseUrl."
On Sat, Apr 28, 2012 at 3:01 PM, Neil Sleightholm wrote:
> I would li
IIRC, we chose to install the NETFX that has support for all platforms.
That's why it's "x86_x64" in the file name.
On Sat, Apr 28, 2012 at 5:36 AM, Kristjan Laane wrote:
> Dear fellow developers,
>
> -- 1 --
>
> I am using the Wix setup bundle as a guide for m
And, yes, there is *some* documentation on the calls a BA must make. It's
in the WiX.chm. More is required but Bruce's approach is very good until
we make the shift from fixing bugs to writing documentation.
On Sat, Apr 28, 2012 at 1:55 PM, Bruce Cran wrote:
> On 28/04/2012 21:45, Alexander Lam
21 matches
Mail list logo
