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 br...@cran.org.uk wrote:
On 28/04/2012
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 kristjan.la...@gmail.comwrote:
Dear fellow developers,
-- 1 --
I am using the Wix setup
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
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. smile/
On Sat, Apr 28, 2012 at
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
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
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 ani.banti.24...@gmail.comwrote:
I have attached the log file.
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
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
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
I did find a work around:
util:RegistrySearch Id=RegistrySearch32 Condition=NOT VersionNT64
Root=HKLM Key=SOFTWARE\Microsoft\Windows\CurrentVersion
Value=ProgramFilesDir Variable=PlatformProgramFilesFolder /
util:RegistrySearch Id=RegistrySearch64 Condition=VersionNT64 Root=HKLM
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 n...@x2systems.comwrote:
Not sure I explained this
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:
BootstrapperApplicationRef
Id=WixStandardBootstrapperApplication.HyperlinkLicense
Payload
'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 r...@robmensching.com wrote:
NOTE: Win2k was out of support before WiX v3.6 even started development. We
obviously don't test the code
At least until the documentation is updated to be correct. smile/
On Sun, Apr 29, 2012 at 2:54 AM, Neil Sleightholm n...@x2systems.comwrote:
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:
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
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 -
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
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
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
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
21 matches
Mail list logo
