Re: [WiX-users] how to add code signing to build script
Thanks very much, Jacob - it’s working!
In case it helps anyone else: it works to use kSignCMD.exe (free download from
K Software) in place of the 2 calls to signtool.
On Jul 6, 2015, at 4:13 PM, Hoover, Jacob jacob.hoo...@greenheck.com wrote:
The error you are getting is: FDIERROR_NOT_A_CABINET
(This would go after your last call to light.)
http://neilsleightholm.blogspot.com/2012/05/wix-burn-tipstricks.html
Signing a package
insignia -ib Setup.exe -o engine.exe
signtool engine.exe (extra parameters excluded for simplicity)
insignia -ab engine.exe Setup.exe -o Setup.exe
signtool Setup.exe
Though it's easier to use a wixproj and the MSBuild tasks, and then just
override the targets.
-Original Message-
From: David Burson [mailto:david_bur...@ntm.org]
Sent: Monday, July 06, 2015 1:01 PM
To: General discussion about the WiX toolset.
Subject: [WiX-users] how to add code signing to build script
Hi,
I’m brand new to code signing. Just got my certificate through K Software, a
Comodo reseller. I tried adding a call to kSignCMD.exe at the end of my
build script, and it appears to work: the properties for my installer show
my certificate, and the UAC prompt when I install also shows me as the
publisher.
However, the installer fails. The start of the log looks fine as far as I
can see, but here’s how the log ends:
Apply begin
Creating a system restore point.
Created a system restore point.
Caching bundle from:
'C:\Users\david\AppData\Local\Temp\{e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}\.be\MapCreatorSetup-x64-1.1.3.exe'
to: 'C:\ProgramData\Package
Cache\{e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}\MapCreatorSetup-x64-1.1.3.exe'
Registering bundle dependency provider:
{e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}, version: 1.1.3.0 Acquiring container:
WixAttachedContainer, copy from: C:\mc\MapCreatorSetup-x64-1.1.3.exe
Setting string variable 'WixBundleLastUsedSource' to value 'C:\mc\'
Error 0x80070001: Failed to extract all files from container, erf: 1:2:0
Error 0x80070001: Failed to wait for operation complete.
Error 0x80070001: Failed to open container.
Error 0x80070001: Failed to open container: WixAttachedContainer.
Failed to extract payloads from container: WixAttachedContainer to working
path:
C:\Users\david\AppData\Local\Temp\{e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}\F0BE7EF5275BEDA1781A0DC8690CC9EBB929A6A8,
error: 0x80070001.
Error 0x80070001: Failed while caching, aborting execution.
Removed bundle dependency provider: {e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}
Removing cached bundle: {e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}, from path:
C:\ProgramData\Package Cache\{e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}\
Apply complete, result: 0x80070001, restart: None, ba requested restart: No
I’ve examined this Insignia documentation:
http://wixtoolset.org/documentation/manual/v3/overview/insignia.html but I
don’t really understand what I’m supposed to do to get code signing to be
part of my build script. Here are what I assume is the pertinent information
about my build script:
After my build script builds all the components and produces an .exe, it
calls candle.exe on about a dozen .wxs files, representing various components
such as localization, help file, license, and finally the actual product.
Next, it calls light.exe with the .wixobj’s produced in the previous steps,
to create an msi.
Then it calls candle.exe on my bundle.wxs.
Finally, it calls light.exe on the bundle.wixobj.
Where in these steps should I insert call(s) to sign my code, and what should
those calls look like? Also, is there any command I can add to the script
that will output whether code signing worked?
Thanks,
David
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that you
need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools
[WiX-users] how to add code signing to build script
Hi,
I’m brand new to code signing. Just got my certificate through K Software, a
Comodo reseller. I tried adding a call to kSignCMD.exe at the end of my build
script, and it appears to work: the properties for my installer show my
certificate, and the UAC prompt when I install also shows me as the publisher.
However, the installer fails. The start of the log looks fine as far as I can
see, but here’s how the log ends:
Apply begin
Creating a system restore point.
Created a system restore point.
Caching bundle from:
'C:\Users\david\AppData\Local\Temp\{e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}\.be\MapCreatorSetup-x64-1.1.3.exe'
to: 'C:\ProgramData\Package
Cache\{e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}\MapCreatorSetup-x64-1.1.3.exe'
Registering bundle dependency provider: {e3cdbd3a-6ab1-4f6c-94b2-4f005172e581},
version: 1.1.3.0
Acquiring container: WixAttachedContainer, copy from:
C:\mc\MapCreatorSetup-x64-1.1.3.exe
Setting string variable 'WixBundleLastUsedSource' to value 'C:\mc\'
Error 0x80070001: Failed to extract all files from container, erf: 1:2:0
Error 0x80070001: Failed to wait for operation complete.
Error 0x80070001: Failed to open container.
Error 0x80070001: Failed to open container: WixAttachedContainer.
Failed to extract payloads from container: WixAttachedContainer to working
path:
C:\Users\david\AppData\Local\Temp\{e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}\F0BE7EF5275BEDA1781A0DC8690CC9EBB929A6A8,
error: 0x80070001.
Error 0x80070001: Failed while caching, aborting execution.
Removed bundle dependency provider: {e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}
Removing cached bundle: {e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}, from path:
C:\ProgramData\Package Cache\{e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}\
Apply complete, result: 0x80070001, restart: None, ba requested restart: No
I’ve examined this Insignia documentation:
http://wixtoolset.org/documentation/manual/v3/overview/insignia.html but I
don’t really understand what I’m supposed to do to get code signing to be part
of my build script. Here are what I assume is the pertinent information about
my build script:
After my build script builds all the components and produces an .exe, it calls
candle.exe on about a dozen .wxs files, representing various components such as
localization, help file, license, and finally the actual product.
Next, it calls light.exe with the .wixobj’s produced in the previous steps, to
create an msi.
Then it calls candle.exe on my bundle.wxs.
Finally, it calls light.exe on the bundle.wixobj.
Where in these steps should I insert call(s) to sign my code, and what should
those calls look like? Also, is there any command I can add to the script that
will output whether code signing worked?
Thanks,
David
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how can I set InstallCondition based on whether my bundle is 32 or 64 bit?
Thanks Jacob,
Here is what I now have, in case it is helpful to someone else. I wasn’t able
to find an UpgradeCode, so I’m using the ProductCode. It seems to work fine
with x86 as best as I can understand the logs (haven’t verified 64-bit yet):
In the Bundle element:
?if $(var.Platform) = x86 ?
util:ProductSearch Variable=VCInstalledx86
ProductCode={13A4EE12-23EA-3371-91EE-EFB36DDFFF3E}/
?else?
util:ProductSearch Variable=VCInstalledx64
ProductCode={929FBD26-9020-399B-9A7A-751D61F0B942}/
?endif?
Chain
?if $(var.Platform) = x86 ?
ExePackage
SourceFile=$(var.KarteDir)\install\win\vcredist_x86.exe PerMachine=yes
Permanent=yes Vital=yes Compressed=yes InstallCommand=/quiet /norestart
InstallCondition=VCInstalledx86 = v0.0.0.0/
?else?
ExePackage
SourceFile=$(var.KarteDir)\install\win\vcredist_x64.exe PerMachine=yes
Permanent=yes Vital=yes Compressed=yes InstallCommand=/quiet /norestart
InstallCondition=VCInstalledx64 = v0.0.0.0 /
?endif?
Thanks for your help!
David
On Jul 2, 2015, at 3:59 PM, Hoover, Jacob jacob.hoo...@greenheck.com wrote:
1. Strange, though on a version I would compare it to a very.x.y.z
2. My way is the old way, and will fail if the product has been patched.
Upgrade code should be more reliable.
3. Poke around from
http://blogs.msdn.com/b/astebner/archive/2007/01/16/mailbag-how-to-detect-the-presence-of-the-vc-8-0-runtime-redistributable-package.aspx?Redirected=true
I know it's the wrong version but he should have a post for the version you
want.
4. Possible, but it would imply downloading the exe every time. You're also
relying on their detection, which should be solid but it is wasted
do/execution time.
Sent from my phone
On Jul 2, 2015, at 1:11 PM, David Burson
david_bur...@ntm.orgmailto:david_bur...@ntm.org wrote:
oops -
3. “this site” is
https://allthingsconfigmgr.wordpress.com/2013/12/17/visual-c-redistributables-made-simple/
4. “this post” is
http://stackoverflow.com/questions/23832713/how-to-check-that-visual-c-2013-redistributable-is-already-installed-using-wix
On Jul 2, 2015, at 1:46 PM, David Burson
david_bur...@ntm.orgmailto:david_bur...@ntm.orgmailto:david_bur...@ntm.org
wrote:
Thanks Jacob,
Btw, I’m using WiX 3.9 R2, hoping to go to 3.10 when it is stable.
Your solution appears to work, but I have 4 questions about it:
1. The log is strange when I upgrade. I installed version 1.1.4 of my app,
then built version 1.1.5, and installed it. In the log for the upgrade, the
pertinent lines (I think) are, after detect begin:
Setting version variable 'VCInstalledx86 ' to value ’12.0.21005.0'
and a few lines down:
Plan begin, 3 packages, action: Install
Condition 'NOT VCInstalledx86' evaluates to true.
I would have expected it to evaluate to false - so I’m not sure what’s going
on?
2. In ProductSearch, I’m using the ProductCode attribute. However, I notice
in the WiX Toolset
documentationhttp://wixtoolset.org/documentation/manual/v3/xsd/wix/productsearch.html,
there is no ProductCode attribute for ProductSearch. There is a required
UpgradeCode. Yet your solution works, so I assume the documentation is
wrong? If so, should that be reported to someone?
3. I’m not clear what ProductCodes to use. I’m using the 2013 versions. I
found this site, which for 2013 lists 2 guids for x64 and 2 for x86. How can
there be 2 product codes each? What do I really need to check?
4. According to a comment on this post, it sounds like I don’t need to check
at all - just run the appropriate vcredist, and it will do its own checking
to see if it’s already there. Is that true?
Also, in case it is useful to others, a few things I did to get this solution
to build:
1. add attribute xmlns:util=http://schemas.microsoft.com/wix/UtilExtension”
to the WiX element
2. delete the spaces in ? else ?
3. create an identical if..else at the same level as Chain for the
ProductSearch’s, to get around this error:
error CNDL0203 : The Chain element contains an unsupported extension element
'util:ProductSearch'. The Chain element does not currently support extension
elements. Is the util:ProductSearch element using the correct XML Namespace?
So in my Bundle element I have:
?if $(var.Platform) = x86 ?
util:ProductSearch Variable=VCInstalledx86
ProductCode={13A4EE12-23EA-3371-91EE-EFB36DDFFF3E}/
?else?
util:ProductSearch Variable=VCInstalledx64
ProductCode={929FBD26-9020-399B-9A7A-751D61F0B942}/
?endif?
Chain
?if $(var.Platform) = x86 ?
ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x86.exe
PerMachine=yes Permanent=yes Vital=yes Compressed=yes
InstallCommand=/quiet /norestart
Re: [WiX-users] how can I set InstallCondition based on whether my bundle is 32 or 64 bit?
Thanks Jacob,
Btw, I’m using WiX 3.9 R2, hoping to go to 3.10 when it is stable.
Your solution appears to work, but I have 4 questions about it:
1. The log is strange when I upgrade. I installed version 1.1.4 of my app,
then built version 1.1.5, and installed it. In the log for the upgrade, the
pertinent lines (I think) are, after detect begin:
Setting version variable 'VCInstalledx86 ' to value ’12.0.21005.0'
and a few lines down:
Plan begin, 3 packages, action: Install
Condition 'NOT VCInstalledx86' evaluates to true.
I would have expected it to evaluate to false - so I’m not sure what’s going
on?
2. In ProductSearch, I’m using the ProductCode attribute. However, I notice in
the WiX Toolset
documentationhttp://wixtoolset.org/documentation/manual/v3/xsd/wix/productsearch.html,
there is no ProductCode attribute for ProductSearch. There is a required
UpgradeCode. Yet your solution works, so I assume the documentation is wrong?
If so, should that be reported to someone?
3. I’m not clear what ProductCodes to use. I’m using the 2013 versions. I
found this site, which for 2013 lists 2 guids for x64 and 2 for x86. How can
there be 2 product codes each? What do I really need to check?
4. According to a comment on this post, it sounds like I don’t need to check at
all - just run the appropriate vcredist, and it will do its own checking to see
if it’s already there. Is that true?
Also, in case it is useful to others, a few things I did to get this solution
to build:
1. add attribute xmlns:util=http://schemas.microsoft.com/wix/UtilExtension” to
the WiX element
2. delete the spaces in ? else ?
3. create an identical if..else at the same level as Chain for the
ProductSearch’s, to get around this error:
error CNDL0203 : The Chain element contains an unsupported extension element
'util:ProductSearch'. The Chain element does not currently support extension
elements. Is the util:ProductSearch element using the correct XML Namespace?
So in my Bundle element I have:
?if $(var.Platform) = x86 ?
util:ProductSearch Variable=VCInstalledx86
ProductCode={13A4EE12-23EA-3371-91EE-EFB36DDFFF3E}/
?else?
util:ProductSearch Variable=VCInstalledx64
ProductCode={929FBD26-9020-399B-9A7A-751D61F0B942}/
?endif?
Chain
?if $(var.Platform) = x86 ?
ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x86.exe
PerMachine=yes Permanent=yes Vital=yes Compressed=yes
InstallCommand=/quiet /norestart InstallCondition=NOT VCInstalledx86/
?else?
ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x64.exe
PerMachine=yes Permanent=yes Vital=yes Compressed=yes
InstallCommand=/quiet /norestart InstallCondition=NOT VCInstalledx64 /
?endif?
Thanks,
David
On Jul 1, 2015, at 5:49 PM, Hoover, Jacob
jacob.hoo...@greenheck.commailto:jacob.hoo...@greenheck.com wrote:
You could use a preprocessor condition. IE:
?if $(var.Bitness) = x86 ?
util:ProductSearch Variable=VCInstalled ProductCode={}/
ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x86.exe
PerMachine=yes Permanent=yes Vital=yes Compressed=yes
InstallCommand=/quiet /norestart InstallCondition=NOT VCInstalled/
? else ?
util:ProductSearch Variable=VCInstalled ProductCode={}/
ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x64.exe
PerMachine=yes Permanent=yes Vital=yes Compressed=yes
InstallCommand=/quiet /norestart InstallCondition=NOT VCInstalled /
?endif?
-Original Message-
From: David Burson [mailto:david_bur...@ntm.org]
Sent: Wednesday, July 01, 2015 2:37 PM
To: General discussion about the WiX toolset.
Subject: [WiX-users] how can I set InstallCondition based on whether my bundle
is 32 or 64 bit?
Hi,
I have a single bundle.wxs I use when I’m creating either a 64-bit and a 32-bit
installer for my app. In my Chain, I have:
ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x64.exe
PerMachine=yes Permanent=yes Vital=yes Compressed=yes
InstallCommand=/quiet /norestart InstallCondition=VersionNT64/
ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x86.exe
PerMachine=yes Permanent=yes Vital=yes Compressed=yes
InstallCommand=/quiet /norestart InstallCondition=NOT VersionNT64/
So, the InstallCondition is checking the hardware my users are installing on to
see which vcredist to install. Instead, I want the InstallCondition to decide
which vcredist to install based on whether the installer is build as 32 or 64
bit. That way my users can install the 32-bit version of my app on a 64-bit OS
if they want.
I have a variable I pass in to the bundle that is set to either “x86” or “x64”.
But I can’t figure out the syntax for how to use that variable in the
InstallCondition for the vcredist’s, or how to create a boolean variable (e.g.,
Bundle_is_x64) that I can set based on the value of the string variable I pass
in.
Can someone point me in the right direction? Or maybe there’s a better way
than using my own variable?
Thanks
David
Re: [WiX-users] how can I set InstallCondition based on whether my bundle is 32 or 64 bit?
oops -
3. “this site” is
https://allthingsconfigmgr.wordpress.com/2013/12/17/visual-c-redistributables-made-simple/
4. “this post” is
http://stackoverflow.com/questions/23832713/how-to-check-that-visual-c-2013-redistributable-is-already-installed-using-wix
On Jul 2, 2015, at 1:46 PM, David Burson
david_bur...@ntm.orgmailto:david_bur...@ntm.org wrote:
Thanks Jacob,
Btw, I’m using WiX 3.9 R2, hoping to go to 3.10 when it is stable.
Your solution appears to work, but I have 4 questions about it:
1. The log is strange when I upgrade. I installed version 1.1.4 of my app,
then built version 1.1.5, and installed it. In the log for the upgrade, the
pertinent lines (I think) are, after detect begin:
Setting version variable 'VCInstalledx86 ' to value ’12.0.21005.0'
and a few lines down:
Plan begin, 3 packages, action: Install
Condition 'NOT VCInstalledx86' evaluates to true.
I would have expected it to evaluate to false - so I’m not sure what’s going
on?
2. In ProductSearch, I’m using the ProductCode attribute. However, I notice in
the WiX Toolset
documentationhttp://wixtoolset.org/documentation/manual/v3/xsd/wix/productsearch.html,
there is no ProductCode attribute for ProductSearch. There is a required
UpgradeCode. Yet your solution works, so I assume the documentation is wrong?
If so, should that be reported to someone?
3. I’m not clear what ProductCodes to use. I’m using the 2013 versions. I
found this site, which for 2013 lists 2 guids for x64 and 2 for x86. How can
there be 2 product codes each? What do I really need to check?
4. According to a comment on this post, it sounds like I don’t need to check at
all - just run the appropriate vcredist, and it will do its own checking to see
if it’s already there. Is that true?
Also, in case it is useful to others, a few things I did to get this solution
to build:
1. add attribute xmlns:util=http://schemas.microsoft.com/wix/UtilExtension” to
the WiX element
2. delete the spaces in ? else ?
3. create an identical if..else at the same level as Chain for the
ProductSearch’s, to get around this error:
error CNDL0203 : The Chain element contains an unsupported extension element
'util:ProductSearch'. The Chain element does not currently support extension
elements. Is the util:ProductSearch element using the correct XML Namespace?
So in my Bundle element I have:
?if $(var.Platform) = x86 ?
util:ProductSearch Variable=VCInstalledx86
ProductCode={13A4EE12-23EA-3371-91EE-EFB36DDFFF3E}/
?else?
util:ProductSearch Variable=VCInstalledx64
ProductCode={929FBD26-9020-399B-9A7A-751D61F0B942}/
?endif?
Chain
?if $(var.Platform) = x86 ?
ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x86.exe
PerMachine=yes Permanent=yes Vital=yes Compressed=yes
InstallCommand=/quiet /norestart InstallCondition=NOT VCInstalledx86/
?else?
ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x64.exe
PerMachine=yes Permanent=yes Vital=yes Compressed=yes
InstallCommand=/quiet /norestart InstallCondition=NOT VCInstalledx64 /
?endif?
Thanks,
David
On Jul 1, 2015, at 5:49 PM, Hoover, Jacob
jacob.hoo...@greenheck.commailto:jacob.hoo...@greenheck.commailto:jacob.hoo...@greenheck.com
wrote:
You could use a preprocessor condition. IE:
?if $(var.Bitness) = x86 ?
util:ProductSearch Variable=VCInstalled ProductCode={}/
ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x86.exe
PerMachine=yes Permanent=yes Vital=yes Compressed=yes
InstallCommand=/quiet /norestart InstallCondition=NOT VCInstalled/
? else ?
util:ProductSearch Variable=VCInstalled ProductCode={}/
ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x64.exe
PerMachine=yes Permanent=yes Vital=yes Compressed=yes
InstallCommand=/quiet /norestart InstallCondition=NOT VCInstalled /
?endif?
-Original Message-
From: David Burson [mailto:david_bur...@ntm.org]
Sent: Wednesday, July 01, 2015 2:37 PM
To: General discussion about the WiX toolset.
Subject: [WiX-users] how can I set InstallCondition based on whether my bundle
is 32 or 64 bit?
Hi,
I have a single bundle.wxs I use when I’m creating either a 64-bit and a 32-bit
installer for my app. In my Chain, I have:
ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x64.exe
PerMachine=yes Permanent=yes Vital=yes Compressed=yes
InstallCommand=/quiet /norestart InstallCondition=VersionNT64/
ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x86.exe
PerMachine=yes Permanent=yes Vital=yes Compressed=yes
InstallCommand=/quiet /norestart InstallCondition=NOT VersionNT64/
So, the InstallCondition is checking the hardware my users are installing on to
see which vcredist to install. Instead, I want the InstallCondition to decide
which vcredist to install based on whether the installer is build as 32 or 64
bit. That way my users can install the 32-bit version of my app on a 64-bit OS
if they want.
I have a variable I pass in to the bundle that is set to either “x86
[WiX-users] how can I set InstallCondition based on whether my bundle is 32 or 64 bit?
Hi, I have a single bundle.wxs I use when I’m creating either a 64-bit and a 32-bit installer for my app. In my Chain, I have: ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x64.exe PerMachine=yes Permanent=yes Vital=yes Compressed=yes InstallCommand=/quiet /norestart InstallCondition=VersionNT64/ ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x86.exe PerMachine=yes Permanent=yes Vital=yes Compressed=yes InstallCommand=/quiet /norestart InstallCondition=NOT VersionNT64/ So, the InstallCondition is checking the hardware my users are installing on to see which vcredist to install. Instead, I want the InstallCondition to decide which vcredist to install based on whether the installer is build as 32 or 64 bit. That way my users can install the 32-bit version of my app on a 64-bit OS if they want. I have a variable I pass in to the bundle that is set to either “x86” or “x64”. But I can’t figure out the syntax for how to use that variable in the InstallCondition for the vcredist’s, or how to create a boolean variable (e.g., Bundle_is_x64) that I can set based on the value of the string variable I pass in. Can someone point me in the right direction? Or maybe there’s a better way than using my own variable? Thanks David -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how to define a custom variable in bundle.wxs, and get its value in BAFunctions.dll?
Thanks for the tip, Phil. A couple questions about that: I assume without bal:Overridable=“yes”, my Variable’s are really constants? In this particular case, I just need constants. I have to declare them in my bundle.wxs so I can use them in my .wxl’s that localize my theme. For example, I declare a separate Variable for the translation of my application’s name into each language I support. I use bafunctions.dll to set WixBundleName to the appropriate one, depending on the user’s language. That makes the correct translated name show up in Programs Features. Putting the translations in Variable’s in bundle.wxs gives me 2 advantages over hard-coding the translations in WixBootstrapperBAFunction.cpp. First, if I were to change a translation (highly unlikely), I would not have to rebuild bafunctions.dll. Second (and more importantly), I have to use the Variable’s to set the Caption in my .wxl’s, since according to answers I've received on this email list (and my experience), the Caption is determined before bafunctions.dll gets involved. Am I correct, then, that in this case there’s no reason to use bal:Overridable=“yes”? Also, I know nothing about the recovery functionality you mention. Are you saying that if I add a 'Persisted=“yes”’ attribute to my variables, then if there is a reboot during install, the install could pick up where it left off, and the .wxl’s would use my Variable’s? But that if I don’t have Persisted=yes for my Variable’s, then the install could pick up where it left off, but not have the values of those variables, so where I use them in my .wxl’s it would show the name of the variable or something like that instead of the value? Really appreciate the help! On Apr 15, 2015, at 9:47 AM, Phill Hogland phogl...@rimage.com wrote: You posted: lt;Variable Name=MyVariable Value=MyValue / I set bal:Overridable='yes' on any variable I create in the Bundle and interact with in the bafunctions.dll or mba. lt;Variable Name=MyVariable Value=MyValue bal:Overridable='yes'/ And since I also read threads about Burn's functionality to recover if an interruption/reboot happens in the middle of the chain, I also set Persisted='yes' for most variables. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/how-to-define-a-custom-variable-in-bundle-wxs-and-get-its-value-in-BAFunctions-dll-tp7599844p7599973.html Sent from the wix-users mailing list archive at Nabble.com. -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] UserLanguageID vs. WixStdBALanguageId
Ok, that makes sense. Apparently it’s smart enough to select an appropriate theme, thankfully. I don’t have to have a separate theme for every culture-language combination: my bundle.wxl only has 1 French theme, 1036 (French-France). When I install on a Windows 7 box with the Region and Language..Format set to French (Canada), the installer runs in French, and WixStdBALanguageId = 1036, as you indicated it should. So I don’t have to have a separate theme for French (Canada). So, if we have to release with WiX 3.9 R2, I’ll use UserLanguageID, but if we can wait for Wix 3.10, I’ll use WixStdBALanguageId. Thanks for your help! On Apr 12, 2015, at 7:37 PM, Sean Hall r.sean.h...@gmail.com wrote: If you don't have a theme for the language id of the user's machine, then WixStdBALanguageId won't be set. WixStdBALanguageId is set to the language id of the theme that StdBA is actually using. On Thu, Apr 2, 2015 at 3:26 PM, David Burson david_bur...@ntm.org wrote: * UserLanguageID - gets the language ID for the current user locale. * WixStdBALanguageId - gets the language in effect for the WixStdBA user interface. When would these have different values? I’m wondering if, since WixStdBALanguageId is new in v3.10, can I use UserLanguageID with v3.9 R2 in my BAFunctions.dll in order to set WixBundleName according to the user’s language. What would be the practical effect for my users if I use UserLanguageID instead of WixStdBALanguageId? -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] BAFunctions.dll to set WixBundleName from the language of the user's computer
ok thanks Sean! Good to know. On Apr 12, 2015, at 7:59 PM, Sean Hall r.sean.h...@gmail.com wrote: The Window text is set too early to do anything about it from IBootstrapperBAFunction. You should localize that with a string in the wxl file. On Tue, Apr 7, 2015 at 2:17 PM, David Burson david_bur...@ntm.org wrote: In case it’s helpful to anyone, I posted how I got this working on SO: http://stackoverflow.com/questions/29266905/wix-toolset-how-to-create-a-single-exe-with-product-name-localized-for-multiple/29499382#29499382 If anyone sees any improvements or problems, please post! Thanks again for everyone’s help. David On Apr 2, 2015, at 2:35 PM, David Burson david_bur...@ntm.orgmailto: david_bur...@ntm.org wrote: It works in OnDetectComplete!!! Thanks everyone for all the help. One question though: In my HyperlinkSidebarTheme wxl's, I use [WixBundleName] in several strings (Caption, Title). If I use one of those strings in value of Window in my HyperlinkSidebarTheme.xml, what is shown at install time in the installer window titlebar is the value I hardcoded into the Name attribute of my Bundle element. Using those same strings in a text element on the Install page, the value I set in BAFunctions.dll is shown. So, I assume OnDetectComplete is too late for Window. Can anyone tell me if WixStdBALanguageId is guaranteed to be set to the user’s language at an earlier stage? Is OnDetect a safe place to check WixStdBALanguageId and set WixBundleName? Also, there is no OnDetectBegin in WixBootstrapperBAFunction.cpp. If that’s what I should use, I assume I just create it patterned after OnDetect? On Apr 2, 2015, at 9:01 AM, Phill Hogland phogl...@rimage.commailto: phogl...@rimage.com wrote: OnDetectComplete handler is safe. OnDetectBegin if you know that WixStdBALanguageId has been initialized prior to OnDetectBegin. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/BAFunctions-dll-to-set-WixBundleName-from-the-language-of-the-user-s-computer-tp7599747p7599812.html Sent from the wix-users mailing list archive at Nabble.com http://Nabble.com. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.netmailto:WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.netmailto:WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http
Re: [WiX-users] how to define a custom variable in bundle.wxs, and get its value in BAFunctions.dll?
Don’t know what I was doing wrong, but since you guys said it should work I
tried again, and it did.
Thanks very much - that really simplifies things!
David
On Apr 12, 2015, at 7:52 PM, Sean Hall r.sean.h...@gmail.com wrote:
This should just work. I'm guessing you've put the Variable in a Fragment
that isn't getting pulled in. Does the variable show up at the end of the
log?
On Fri, Apr 3, 2015 at 5:17 PM, roberthyang robert_y...@agilent.com wrote:
This worked fine for us inside OnDetectComplete on Wix 3.8 (released
version). For example :
// Check if Acrobat is installed by reading variable.
LPWSTR sczAcrobatValue = NULL;
BalGetStringVariable(LAcrobatInstalled, sczAcrobatValue);
BalExitOnFailure(hr, Failed to get AcrobatInstalled burn
variable.);
// Show warning state if Acrobat variable is empty.
if ((sczAcrobatValue == NULL) || (wcslen(sczAcrobatValue) == 0))
{
hr = m_pEngine-SetVariableString(LAcrobatWarningState,
L);
BalExitOnFailure(hr, Failed to set AcrobatWarningState burn
variable.);
}
AcrobatInstalled is read using Util: registry searches, and
AcrobatWarningState just controls visibility of a warning text box in our
custom theme. What specifically doesn't work ?
David Burson wrote
In the bundle I’ve tried
Variable Name=MyVariable Value=MyValue /
, and tried reading it in bafunctions.dll with
LPWSTR my_variable = NULL;
BalGetStringVariable(LMyVariable, my_variable);
But that doesn’t work. Is there any way to do it?
--
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
by Intel and developed in partnership with Slashdot Media, is your hub
for
all
things parallel software development, from weekly thought leadership
blogs
to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@.sourceforge
https://lists.sourceforge.net/lists/listinfo/wix-users
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/how-to-define-a-custom-variable-in-bundle-wxs-and-get-its-value-in-BAFunctions-dll-tp7599844p7599846.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for
all
things parallel software development, from weekly thought leadership blogs
to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] BAFunctions.dll to set WixBundleName from the language of the user's computer
In case it’s helpful to anyone, I posted how I got this working on SO: http://stackoverflow.com/questions/29266905/wix-toolset-how-to-create-a-single-exe-with-product-name-localized-for-multiple/29499382#29499382 If anyone sees any improvements or problems, please post! Thanks again for everyone’s help. David On Apr 2, 2015, at 2:35 PM, David Burson david_bur...@ntm.orgmailto:david_bur...@ntm.org wrote: It works in OnDetectComplete!!! Thanks everyone for all the help. One question though: In my HyperlinkSidebarTheme wxl's, I use [WixBundleName] in several strings (Caption, Title). If I use one of those strings in value of Window in my HyperlinkSidebarTheme.xml, what is shown at install time in the installer window titlebar is the value I hardcoded into the Name attribute of my Bundle element. Using those same strings in a text element on the Install page, the value I set in BAFunctions.dll is shown. So, I assume OnDetectComplete is too late for Window. Can anyone tell me if WixStdBALanguageId is guaranteed to be set to the user’s language at an earlier stage? Is OnDetect a safe place to check WixStdBALanguageId and set WixBundleName? Also, there is no OnDetectBegin in WixBootstrapperBAFunction.cpp. If that’s what I should use, I assume I just create it patterned after OnDetect? On Apr 2, 2015, at 9:01 AM, Phill Hogland phogl...@rimage.commailto:phogl...@rimage.com wrote: OnDetectComplete handler is safe. OnDetectBegin if you know that WixStdBALanguageId has been initialized prior to OnDetectBegin. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/BAFunctions-dll-to-set-WixBundleName-from-the-language-of-the-user-s-computer-tp7599747p7599812.html Sent from the wix-users mailing list archive at Nabble.comhttp://Nabble.com. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.netmailto:WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.netmailto:WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] m_pEngine-GetVariableString syntax?
I just tested: BalGetStringVariable in BAFunctions.dll does NOT work to get a custom variable defined in the bundle using Variable Name=“var_name” Value=“my value” / On Apr 3, 2015, at 9:20 AM, David Burson david_bur...@ntm.org wrote: Yes, thanks, I did use that for WixBundleName. But I’m talking about getting a custom Variable from my bundle.wxs, not a burn variable (which I assume means the built-in variables, which I believe in the Bundle are referenced as WixVariable, not Variable). Or can I use BalGetStringVariable to get a custom variable from my bundle, too? On Apr 3, 2015, at 9:12 AM, Phill Hogland phogl...@rimage.com wrote: Look at the sample, in src\burn\Samples\bafunctions\readme.txt, it even gives you the following example: //- // Example of reading burn variable. BalGetStringVariable(LWixBundleName, sczValue); BalExitOnFailure(hr, Failed to get variable.); -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/m-pEngine-GetVariableString-syntax-tp7599831p7599837.html Sent from the wix-users mailing list archive at Nabble.com. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] how to define a custom variable in bundle.wxs, and get its value in BAFunctions.dll?
In the bundle I’ve tried Variable Name=MyVariable Value=MyValue /, and tried reading it in bafunctions.dll with LPWSTR my_variable = NULL; BalGetStringVariable(LMyVariable, my_variable); But that doesn’t work. Is there any way to do it? -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] m_pEngine-GetVariableString syntax?
Yes, thanks, I did use that for WixBundleName. But I’m talking about getting a custom Variable from my bundle.wxs, not a burn variable (which I assume means the built-in variables, which I believe in the Bundle are referenced as WixVariable, not Variable). Or can I use BalGetStringVariable to get a custom variable from my bundle, too? On Apr 3, 2015, at 9:12 AM, Phill Hogland phogl...@rimage.com wrote: Look at the sample, in src\burn\Samples\bafunctions\readme.txt, it even gives you the following example: //- // Example of reading burn variable. BalGetStringVariable(LWixBundleName, sczValue); BalExitOnFailure(hr, Failed to get variable.); -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/m-pEngine-GetVariableString-syntax-tp7599831p7599837.html Sent from the wix-users mailing list archive at Nabble.com. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] UserLanguageID vs. WixStdBALanguageId
* UserLanguageID - gets the language ID for the current user locale. * WixStdBALanguageId - gets the language in effect for the WixStdBA user interface. When would these have different values? I’m wondering if, since WixStdBALanguageId is new in v3.10, can I use UserLanguageID with v3.9 R2 in my BAFunctions.dll in order to set WixBundleName according to the user’s language. What would be the practical effect for my users if I use UserLanguageID instead of WixStdBALanguageId? -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] BAFunctions.dll to set WixBundleName from the language of the user's computer
It works in OnDetectComplete!!! Thanks everyone for all the help. One question though: In my HyperlinkSidebarTheme wxl's, I use [WixBundleName] in several strings (Caption, Title). If I use one of those strings in value of Window in my HyperlinkSidebarTheme.xml, what is shown at install time in the installer window titlebar is the value I hardcoded into the Name attribute of my Bundle element. Using those same strings in a text element on the Install page, the value I set in BAFunctions.dll is shown. So, I assume OnDetectComplete is too late for Window. Can anyone tell me if WixStdBALanguageId is guaranteed to be set to the user’s language at an earlier stage? Is OnDetect a safe place to check WixStdBALanguageId and set WixBundleName? Also, there is no OnDetectBegin in WixBootstrapperBAFunction.cpp. If that’s what I should use, I assume I just create it patterned after OnDetect? On Apr 2, 2015, at 9:01 AM, Phill Hogland phogl...@rimage.com wrote: OnDetectComplete handler is safe. OnDetectBegin if you know that WixStdBALanguageId has been initialized prior to OnDetectBegin. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/BAFunctions-dll-to-set-WixBundleName-from-the-language-of-the-user-s-computer-tp7599747p7599812.html Sent from the wix-users mailing list archive at Nabble.com. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] m_pEngine-GetVariableString syntax?
Is there such a thing as m_pEngine-GetVariableString, and can it be used to get Bundle Variable values in BAFunctions.dll? If so, what is the syntax? Thanks very much! David -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] BAFunctions.dll to set WixBundleName from the language of the user's computer
Neither the wix39-debug.zip from https://wix.codeplex.com/releases/view/610859 nor the wix310-debug.zip from http://wixtoolset.org/releases/v3-10-0-1519/ included an SDK directory. Where does the SDK directory come from? What is the proper way to get the source for 3.9 R2 and 3.10 so I can build the BAFunctions sample with both? On Mar 30, 2015, at 11:31 PM, Sean Hall r.sean.h...@gmail.commailto:r.sean.h...@gmail.com wrote: The sample is supposed to build with VS2010. IBootstrapperBAFunction.h should be in the SDK directory with the other WiX header files like dutil.h. Worst case scenario you can copy it from source at https://github.com/wixtoolset/wix3/blob/develop/src/libs/balutil/inc/IBootstrapperBAFunction.h . On Mon, Mar 30, 2015 at 3:52 PM, David Burson david_bur...@ntm.org wrote: ok thanks Rob. That explains why I haven’t found an easy way to do this. I’m trying to replace our old InstallAware installer with WiX. Generally I’m much happier with what I have localized with WiX than with InstallAware. However, with InstallAware we did localize the Program Features name for previous releases, so if possible I’d like to localize it with WiX, so our non-English users aren’t confronted with in incomprehensible (English) name in Programs Features. Do I understand correctly that to localize the name in Programs Features, I need to create a BAfunctions.dll in which I set WixBundleName based on the current language of the user’s computer? If so, I’m back to this question: When building the BAFunctions sample program at src\burn\Samples\bafunctions, I get: Error 1 error C1083: Cannot open include file: 'IBootstrapperBAFunction.h': No such file or directory c:\downloads\wix39-debug\src\burn\samples\bafunctions\precomp.h 51 1 bafunctions With VS2010 I get the same error whether I use the latest WiX v3.10 or 3.9 R2. Is the sample supposed to build? I’m not sure where to start. Any guidance would be appreciated! Thanks, David On Mar 30, 2015, at 4:26 PM, Rob Mensching r...@firegiant.com wrote: Often the Programs Features contains the name of the product which is typically a trademark (or treated like a brand in any case) and thus not localized. It's possible to change the name but wixstdba doesn't really expose it easily. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: David Burson [mailto:david_bur...@ntm.org] Sent: Monday, March 30, 2015 9:53 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] BAFunctions.dll to set WixBundleName from the language of the user's computer Thanks Phil, I’m just trying to make sure that when a user tries to uninstall my software, they can find it in Programs Features (or when they are looking through Programs Features, they don’t uninstall it because they don’t know what it is). That means the name that Programs Features displays needs to be what they think of as the name of my program, which is different for each language. I’d obviously rather not write my own BAfunctions.dll if I can avoid it. I’m new to all this so I appreciate your patience as I try to understand my options. I’ve studied the link you provided and the other links in it, but still have not come up with a working solution. Towards the beginning of the discussion you referenced below, you provided a link on how to localize the Product name of an msi, and said (It happens to be in a MSI Product element but also could be implemented in a Bundle element.)” But when I add a string for “WixBundleName” to my wxl’s, it seems to be ignored. Here http://stackoverflow.com/questions/29266905/wix-toolset-how-to-create-a-single-exe-with-product-name-localized-for-multiple/29270124?noredirect=1#comment46810219_29270124 is my SO question, which led me to think I need to create a BAfunctions.dll. I thought it might be more appropriate to move my ongoing questions to this email list, rather than continue in SO - please correct me if I’m wrong! Anyway, thanks to a number of posts by you and others (and the wix toolset site), my installer works great. All strings (including the name of my program) are presented in the user’s language. The one issue left is the name that is displayed in Programs Features. In my SO question above the original answer mentioned a cool feature not yet being worked on that, if I understand correctly, will localize the name in Programs Features even if the user changes languages after installing the program. While that may be ideal, it’s more than I need. Really, all I need is for Programs Features to display the same name I show to the users at install time. Currently that is a variable I define for each language I support, since I’ve not been able to figure out how to change [WixBundleName]. Some of my constraints: - I cannot go the route of including different msi’s in my bundle (one per
Re: [WiX-users] BAFunctions.dll to set WixBundleName from the language of the user's computer
oops, last 2 lines should read:
hr = m_pEngine-SetVariableNumeric(L”WixBundleName, bundle_name);
BalExitOnFailure(hr, Failed to set WixBundleName variable.”);
On Apr 1, 2015, at 2:35 PM, David Burson
david_bur...@ntm.orgmailto:david_bur...@ntm.org wrote:
That was the problem - I had an old version of WiX on my VS 2010 vm. I
installed 3.10 and the sample builds now.
If I understand correctly, to set the WixBundleName I need something like this
somewhere in BAFunctions.dll:
LPWSTR bundle_name = NULL;
switch (WixStdBALanguageId) {
case 1036:
case 2060:
case 3084:
bundle_name = L”My App Name - French”
break;
case 1057:
bundle_name = L”My App Name - Indonesian”
break;
case 1046:
case 2070:
bundle_name = L”My App Name - Portuguese”
break;
default:
bundle_name = L”My App Name - English”
}
hr = m_pEngine-SetVariableString(LVariable1, LString value”);
BalExitOnFailure(hr, Failed to set variable.”);
Is that the idea? If so, where should this code go?
Thanks for all your help!
David
On Apr 1, 2015, at 12:35 PM, Sean Hall
r.sean.h...@gmail.commailto:r.sean.h...@gmail.commailto:r.sean.h...@gmail.com
wrote:
When you install WiX, it creates the WIX environment variable which is used
in that sample project. It should point to the install directory,
typically C:\Program Files (x86)\WiX Toolset v3.10\. The header file
should be in the SDK\VS2010\inc directory in that install directory.
On Wed, Apr 1, 2015 at 9:27 AM, David Burson
david_bur...@ntm.orgmailto:david_bur...@ntm.orgmailto:david_bur...@ntm.org
wrote:
Neither the wix39-debug.zip from
https://wix.codeplex.com/releases/view/610859 nor the wix310-debug.zip
from http://wixtoolset.org/releases/v3-10-0-1519/ included an SDK
directory. Where does the SDK directory come from? What is the proper way
to get the source for 3.9 R2 and 3.10 so I can build the BAFunctions sample
with both?
On Mar 30, 2015, at 11:31 PM, Sean Hall
r.sean.h...@gmail.commailto:r.sean.h...@gmail.commailto:r.sean.h...@gmail.commailto:
r.sean.h...@gmail.commailto:r.sean.h...@gmail.commailto:r.sean.h...@gmail.com
wrote:
The sample is supposed to build with VS2010. IBootstrapperBAFunction.h
should be in the SDK directory with the other WiX header files like
dutil.h. Worst case scenario you can copy it from source at
https://github.com/wixtoolset/wix3/blob/develop/src/libs/balutil/inc/IBootstrapperBAFunction.h
.
On Mon, Mar 30, 2015 at 3:52 PM, David Burson
david_bur...@ntm.orgmailto:david_bur...@ntm.org
wrote:
ok thanks Rob. That explains why I haven’t found an easy way to do this.
I’m trying to replace our old InstallAware installer with WiX. Generally
I’m much happier with what I have localized with WiX than with
InstallAware. However, with InstallAware we did localize the Program
Features name for previous releases, so if possible I’d like to localize it
with WiX, so our non-English users aren’t confronted with in
incomprehensible (English) name in Programs Features.
Do I understand correctly that to localize the name in Programs
Features, I need to create a BAfunctions.dll in which I set WixBundleName
based on the current language of the user’s computer? If so, I’m back to
this question:
When building the BAFunctions sample program at
src\burn\Samples\bafunctions, I get:
Error 1 error C1083: Cannot open include file:
'IBootstrapperBAFunction.h': No such file or directory
c:\downloads\wix39-debug\src\burn\samples\bafunctions\precomp.h 51 1
bafunctions
With VS2010 I get the same error whether I use the latest WiX v3.10 or 3.9
R2. Is the sample supposed to build? I’m not sure where to start. Any
guidance would be appreciated!
Thanks,
David
On Mar 30, 2015, at 4:26 PM, Rob Mensching
r...@firegiant.commailto:r...@firegiant.com wrote:
Often the Programs Features contains the name of the product which is
typically a trademark (or treated like a brand in any case) and thus not
localized.
It's possible to change the name but wixstdba doesn't really expose it
easily.
_
Short replies here. Complete answers over there:
http://www.firegiant.com/
-Original Message-
From: David Burson [mailto:david_bur...@ntm.org]
Sent: Monday, March 30, 2015 9:53 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] BAFunctions.dll to set WixBundleName from the
language of the user's computer
Thanks Phil,
I’m just trying to make sure that when a user tries to uninstall my
software, they can find it in Programs Features (or when they are looking
through Programs Features, they don’t uninstall it because they don’t
know what it is). That means the name that Programs Features displays
needs to be what they think of as the name of my program, which is
different for each language. I’d obviously rather not write my own
BAfunctions.dll if I can avoid it. I’m new to all this so I appreciate
your patience as I try to understand my options.
I’ve studied the link you
Re: [WiX-users] BAFunctions.dll to set WixBundleName from the language of the user's computer
That was the problem - I had an old version of WiX on my VS 2010 vm. I
installed 3.10 and the sample builds now.
If I understand correctly, to set the WixBundleName I need something like this
somewhere in BAFunctions.dll:
LPWSTR bundle_name = NULL;
switch (WixStdBALanguageId) {
case 1036:
case 2060:
case 3084:
bundle_name = L”My App Name - French”
break;
case 1057:
bundle_name = L”My App Name - Indonesian”
break;
case 1046:
case 2070:
bundle_name = L”My App Name - Portuguese”
break;
default:
bundle_name = L”My App Name - English”
}
hr = m_pEngine-SetVariableString(LVariable1, LString value”);
BalExitOnFailure(hr, Failed to set variable.”);
Is that the idea? If so, where should this code go?
Thanks for all your help!
David
On Apr 1, 2015, at 12:35 PM, Sean Hall
r.sean.h...@gmail.commailto:r.sean.h...@gmail.com wrote:
When you install WiX, it creates the WIX environment variable which is used
in that sample project. It should point to the install directory,
typically C:\Program Files (x86)\WiX Toolset v3.10\. The header file
should be in the SDK\VS2010\inc directory in that install directory.
On Wed, Apr 1, 2015 at 9:27 AM, David Burson
david_bur...@ntm.orgmailto:david_bur...@ntm.org wrote:
Neither the wix39-debug.zip from
https://wix.codeplex.com/releases/view/610859 nor the wix310-debug.zip
from http://wixtoolset.org/releases/v3-10-0-1519/ included an SDK
directory. Where does the SDK directory come from? What is the proper way
to get the source for 3.9 R2 and 3.10 so I can build the BAFunctions sample
with both?
On Mar 30, 2015, at 11:31 PM, Sean Hall
r.sean.h...@gmail.commailto:r.sean.h...@gmail.commailto:
r.sean.h...@gmail.commailto:r.sean.h...@gmail.com wrote:
The sample is supposed to build with VS2010. IBootstrapperBAFunction.h
should be in the SDK directory with the other WiX header files like
dutil.h. Worst case scenario you can copy it from source at
https://github.com/wixtoolset/wix3/blob/develop/src/libs/balutil/inc/IBootstrapperBAFunction.h
.
On Mon, Mar 30, 2015 at 3:52 PM, David Burson david_bur...@ntm.org
wrote:
ok thanks Rob. That explains why I haven’t found an easy way to do this.
I’m trying to replace our old InstallAware installer with WiX. Generally
I’m much happier with what I have localized with WiX than with
InstallAware. However, with InstallAware we did localize the Program
Features name for previous releases, so if possible I’d like to localize it
with WiX, so our non-English users aren’t confronted with in
incomprehensible (English) name in Programs Features.
Do I understand correctly that to localize the name in Programs
Features, I need to create a BAfunctions.dll in which I set WixBundleName
based on the current language of the user’s computer? If so, I’m back to
this question:
When building the BAFunctions sample program at
src\burn\Samples\bafunctions, I get:
Error 1 error C1083: Cannot open include file:
'IBootstrapperBAFunction.h': No such file or directory
c:\downloads\wix39-debug\src\burn\samples\bafunctions\precomp.h 51 1
bafunctions
With VS2010 I get the same error whether I use the latest WiX v3.10 or 3.9
R2. Is the sample supposed to build? I’m not sure where to start. Any
guidance would be appreciated!
Thanks,
David
On Mar 30, 2015, at 4:26 PM, Rob Mensching r...@firegiant.com wrote:
Often the Programs Features contains the name of the product which is
typically a trademark (or treated like a brand in any case) and thus not
localized.
It's possible to change the name but wixstdba doesn't really expose it
easily.
_
Short replies here. Complete answers over there:
http://www.firegiant.com/
-Original Message-
From: David Burson [mailto:david_bur...@ntm.org]
Sent: Monday, March 30, 2015 9:53 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] BAFunctions.dll to set WixBundleName from the
language of the user's computer
Thanks Phil,
I’m just trying to make sure that when a user tries to uninstall my
software, they can find it in Programs Features (or when they are looking
through Programs Features, they don’t uninstall it because they don’t
know what it is). That means the name that Programs Features displays
needs to be what they think of as the name of my program, which is
different for each language. I’d obviously rather not write my own
BAfunctions.dll if I can avoid it. I’m new to all this so I appreciate
your patience as I try to understand my options.
I’ve studied the link you provided and the other links in it, but still
have not come up with a working solution. Towards the beginning of the
discussion you referenced below, you provided a link on how to localize the
Product name of an msi, and said (It happens to be in a MSI Product
element but also could be implemented in a Bundle element.)” But when I
add a string for “WixBundleName” to my wxl’s, it seems to be ignored.
Here
http
Re: [WiX-users] BAFunctions.dll to set WixBundleName from the language of the user's computer
ok thanks Rob. That explains why I haven’t found an easy way to do this. I’m trying to replace our old InstallAware installer with WiX. Generally I’m much happier with what I have localized with WiX than with InstallAware. However, with InstallAware we did localize the Program Features name for previous releases, so if possible I’d like to localize it with WiX, so our non-English users aren’t confronted with in incomprehensible (English) name in Programs Features. Do I understand correctly that to localize the name in Programs Features, I need to create a BAfunctions.dll in which I set WixBundleName based on the current language of the user’s computer? If so, I’m back to this question: When building the BAFunctions sample program at src\burn\Samples\bafunctions, I get: Error 1 error C1083: Cannot open include file: 'IBootstrapperBAFunction.h': No such file or directory c:\downloads\wix39-debug\src\burn\samples\bafunctions\precomp.h 51 1 bafunctions With VS2010 I get the same error whether I use the latest WiX v3.10 or 3.9 R2. Is the sample supposed to build? I’m not sure where to start. Any guidance would be appreciated! Thanks, David On Mar 30, 2015, at 4:26 PM, Rob Mensching r...@firegiant.com wrote: Often the Programs Features contains the name of the product which is typically a trademark (or treated like a brand in any case) and thus not localized. It's possible to change the name but wixstdba doesn't really expose it easily. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: David Burson [mailto:david_bur...@ntm.org] Sent: Monday, March 30, 2015 9:53 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] BAFunctions.dll to set WixBundleName from the language of the user's computer Thanks Phil, I’m just trying to make sure that when a user tries to uninstall my software, they can find it in Programs Features (or when they are looking through Programs Features, they don’t uninstall it because they don’t know what it is). That means the name that Programs Features displays needs to be what they think of as the name of my program, which is different for each language. I’d obviously rather not write my own BAfunctions.dll if I can avoid it. I’m new to all this so I appreciate your patience as I try to understand my options. I’ve studied the link you provided and the other links in it, but still have not come up with a working solution. Towards the beginning of the discussion you referenced below, you provided a link on how to localize the Product name of an msi, and said (It happens to be in a MSI Product element but also could be implemented in a Bundle element.)” But when I add a string for “WixBundleName” to my wxl’s, it seems to be ignored. Herehttp://stackoverflow.com/questions/29266905/wix-toolset-how-to-create-a-single-exe-with-product-name-localized-for-multiple/29270124?noredirect=1#comment46810219_29270124 is my SO question, which led me to think I need to create a BAfunctions.dll. I thought it might be more appropriate to move my ongoing questions to this email list, rather than continue in SO - please correct me if I’m wrong! Anyway, thanks to a number of posts by you and others (and the wix toolset site), my installer works great. All strings (including the name of my program) are presented in the user’s language. The one issue left is the name that is displayed in Programs Features. In my SO question above the original answer mentioned a cool feature not yet being worked on that, if I understand correctly, will localize the name in Programs Features even if the user changes languages after installing the program. While that may be ideal, it’s more than I need. Really, all I need is for Programs Features to display the same name I show to the users at install time. Currently that is a variable I define for each language I support, since I’ve not been able to figure out how to change [WixBundleName]. Some of my constraints: - I cannot go the route of including different msi’s in my bundle (one per language), since each msi is about 250 MB. - I cannot simply have my users download the appropriate msi for their language. Typical distribution (which I can’t control) is an English speaker installs the software for themselves, and gives their installer to nationals who don’t speak English. So the single installer needs to “just work” for the languages I support. - Additionally, many of my users have no reliable internet connection. My program does not use .NET. I’m not currently using Visual Studio, though if necessary in order to solve this issue I have VS 2010 and of course the free VS 2013 available. I just can’t add .NET or other large dependencies. Another path
[WiX-users] BAFunctions.dll to set WixBundleName from the language of the user's computer
Hi, I’m trying to create my own BAFunctions.dll. All I want to do with it is set WixBundleName based on the language of the user’s computer. Does something like that already exist somewhere? If not: I’ve tried to build src\burn\Samples\bafunctions VS2013 and VS2010. Lots of errors with VS2013, only 1 error with VS2010: Error 1 error C1083: Cannot open include file: 'IBootstrapperBAFunction.h': No such file or directory c:\downloads\wix39-debug\src\burn\samples\bafunctions\precomp.h 51 1 bafunctions With VS2010 I get the same error whether I use the latest WiX v3.10 or 3.9 R2. Is this sample suitable as a template to create my own BAFunctions.dll? If so, where do I get IBootstrapperBAFunction.h? Thanks, David -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
