You could share with us your findings...
-Original Message-
From: gapearce [mailto:mr_gapea...@yahoo.com]
Sent: Friday, December 19, 2014 05:06
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] I swear I looked around before asking about "pragma
message" functionality...
Sorr
Sorry - I was too impatient... I figured it out ;-) Doh!
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/I-swear-I-looked-around-before-asking-about-pragma-message-functionality-tp7598646p7598647.html
Sent from the wix-users mailing list archive a
Is there a way to get something like (In C++) #pragma message("some message")
that I can put in my WiX project file? I want to output in the log the
generated product code each time it is built.
I found but I can't get it to output the value of a variable. I
tried a couple of variations of thi
Sorry, I don't think it's at copy files. It, the "1" appears after progress
is at 100% so I think it's not at copy, but towards the end.
Maybe installfinalize/wixcheckreboot? I didn't see anything funky in the log
either, but there were ALOT of "1"s (=
Thanks for the tips!
--
View this message
Also SchenaVersion gets set to 2.0. I've always wondered if it should be
3.0, but I am not sure what this is used for either.
2.0
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Votive-What-is-purpose-of-ProductVerstion-in-wixproj-tp7598643p7598
When using Votive to create a setup project, the wixproj file includes the
line:
3.9
The wxs indicates that the Product/@Version is Version="1.0.0.0", which I
always edit to implement auto-incremented verssioning system. But since I
started creating projects using Wix 3.7, I still have many proje
It certainly is being used in the .wxs project . The error you see is somewhere
in the .wxs file(not Custom action).
Search for " CommonFilesFolder" in the whole solution.
-Original Message-
From: Majcica, Mario [mailto:mario.majc...@bakerhughes.com]
Sent: Thursday, December 18, 2014 7:4
Well, the latter approach will run the internal custom actions on the
assemblies.
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development
Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050
|jocoo...@jackhenry.com
From: samp
That's true. It should just move on over. So, run heat on the 32-bit versions
and then migrate that output.
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development
Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050
|jocoo.
The COM data (classids etc) is typically the same for both
architectures, so massaging the 32-bit output a little should be all
that's required.
---
Phil Wilson
On Thu, Dec 18, 2014 at 8:21 AM, John Cooper wrote:
> Well, the general problem is that COM registry entries are going to b
As Jacob says, the log might help, and if, as you say, it's
associated with files being copied then it may be the InstallFiles
action. The only other alternative to fixing it would be to try to
find it in the ActionText table of the MSI file, a "1" somewhere
instead of "[1]"
---
Phil W
From: John Cooper
Sent: Thursday, December 18, 2014 10:44 AM
To: sampat magi
Cc: WiX toolset developer mailing list (wix-d...@lists.sourceforge.net)
Subject: Re: [WiX-devs] Heat over 64 bit dll
I used to do something like that when I worked at Microsoft. You need to be
careful that ID’s can on
Well, the general problem is that COM registry entries are going to be in the
32-bit hive (traditionally, COM has been 32-bit). A heat running as a 64-bit
process should be able to see these entries (the converse would not be true).
However, heat hasn't changed much since Wix 3.5, and I suspec
I commented this part of code and I do get the following error:
Error 2 Unresolved reference to symbol 'Directory:CommonFilesFolder' in
section 'Fragment:'.
E:\delivery\Dev\wix37_public\src\ext\VSExtension\wixlib\HTML_Help_Registration__RTL_X86.wxs
Seems that is used somewhere. Any i
Thanks Stephan,
It seems an orphan peace of code. No fragments are using it and no reference to
that Help folder is anywhere in the project.
Seems to me safe to remove it.
I will try to get rid of it and verify if the installation is still working as
expected.
I was scared about Bogus_HHRegCA_
It is ensuring that an empty directory named
"Program Files\Common Files\Microsoft Shared\Help"
It seems a bit odd that DirectoryRef elements aren't being used. We would need
to see more of the Fragment/file to know EXACTLY where this directory structure
will land.
is created.
Stephen Tun
Hi all,
I inherited in maintenance a WiX project and unfortunately who created can't be
asked about it.
All of the code is clear except the following:
Can anyone help
Note that you are subject to PowerShell execution policy. Before Server 2012
R2, the default was Restricted which will block all PowerShell execution
outside of a PowerShell Concole or ISE. Many networks have GPO that will
detect changes to the ExecutionPolicy and revert it back.
With Server
I have programmed a bootstrapper project with WiX 3.8.
In my setup i create in my MSI a new local user (if he doesn't exist).
Then i'm installing (as a prerequisite) SQL Server Express and create a SQL
Server instance called "SQLEXPRESS".
After this i want to create a SQL Server login with SQLAuthe
19 matches
Mail list logo
