Re: [WiX-users] Accessing MSI description / feature info from burn BootstrapperApplication

2013-03-29 Thread mark222
In this way it's possible to access the properties such as Title and Description in the current language of the msi, but if I have a multi language msi is there any simple way to read the localized Text and Description even for the other languages? I need to change the language of my installer from

[WiX-users] Custom Tasks and WixTasks.dll dependency

2013-03-29 Thread Maillet, Ed
Hey all, I have a custom Heat task, aka. a class derived from HeatTask. It works fine under Wix3.5 and Wix3.6 in Visual Studio 2008. A problem arises is under Wix3.6 and VS2012. When building in VS2012, the WixTasks.dll dependency can't be found. It would appear (from using ProcMon) that in VS

Re: [WiX-users] obain the name of components using msi/wix functions

2013-03-29 Thread Marco Tognacci
If you use Burn, you could parse the BootstrapperApplicationData.xml that is copied in the temp folder in which are copied the files of the bootrstrapper, like show in this blog http://wrightthisblog.blogspot.it/2013/01/part-3-of-writing-your-own-net-based.htmlIn this way you could access some

[WiX-users] Advice on using remote RemotePayload properly

2013-03-29 Thread ptr
hey all I have successfully built a custom managed boostrapper. My bootstrapper chains the following packages 1) Embedded .NET 4 framework as EXEPackage 2) A microsoft prereq msi ( VS2005,2008,2010 runtimes) around 8MB 3) Some third party binaries we depend on another msi around 200 MB 4) An msi

Re: [WiX-users] obain the name of components using msi/wix functions

2013-03-29 Thread Phil Wilson
...but if you mean the installed data about the components, I think you need to use MsiEnumComponents() and then for each component guid you can use MsiEnumClients to find out which product guids they belong to (they may be shared between several). MsiGetComponentPath() will give you the path (ma

Re: [WiX-users] obain the name of components using msi/wix functions

2013-03-29 Thread Rob Mensching
"Name"? You mean like the "Component/@Id"? That is basically an internal implementation detail. You'd have to open the MSI and query the table to get it. All the MSI APIs for talking about installed products use the "Component/@Guid". On Fri, Mar 29, 2013 at 7:54 AM, Sean Farrow wrote: > Hi al

Re: [WiX-users] Unable to get bal condition to work in custom bootstrapper

2013-03-29 Thread Rob Mensching
The engine can evaluate a condition. The wixstdba pulls the conditions out of the BootstrapperApplicationData.xml then evaluates each one (by calling into the engine). Check out the code, it's pretty straight forward (of course, I may have written a bunch of it so take my opinion with a grain of sa

Re: [WiX-users] Unable to get bal condition to work in custom bootstrapper

2013-03-29 Thread ptr
Thanks ...But it seems like IBootstrapperEngine,Engine don't have a EvaluateConditions at all. Is there a way to get all conditions from a managed bootstrapper or Would you recommend that I do it all in code by not having any bal conditions but use Engine.EvaluateCondition Thanks Raj On Fri, Ma

[WiX-users] obain the name of components using msi/wix functions

2013-03-29 Thread Sean Farrow
Hi all, I need to access the name of the components installed for a specific product. I've already got the products enumerated. What I need now is to enumerate the components and obtain the name of each component. Any help appreciated. Regards Sean. ---

Re: [WiX-users] Unable to get bal condition to work in custom bootstrapper

2013-03-29 Thread Rob Mensching
Yes, a custom BA would need to evaluate the conditions. wixstdba has a function called EvaluateConditions() that does that. On Fri, Mar 29, 2013 at 7:35 AM, ptr wrote: > hey all > > I am trying to add a condition to my bundle and it doesn't seem to work > > I have something like this in my bund

[WiX-users] Unable to get bal condition to work in custom bootstrapper

2013-03-29 Thread ptr
hey all I am trying to add a condition to my bundle and it doesn't seem to work I have something like this in my bundle 1 >= 2 The bundle references WixBalExtension and I have added xmlns:bal=" http://schemas.microsoft.com/wix/BalExtension to the root Wix xml node. The inst

[WiX-users] Help with component not installing.

2013-03-29 Thread tyler.w.reid
Hello, Basically I have a component group in my installer that will not get installed when doing an upgrade. Now we have found that the upgrade only doesn't work when we upgrade from a version that didn't previously contain these components. In our example the initial install is version

Re: [WiX-users] $(TargetPath) in PostBuildEvent does not point to correct location of MSI (with Culture)

2013-03-29 Thread Rob Mensching
Sounds like the bug is not yet fixed. Would be great if you could open it. PS: The WiX documentation provides a better way to do signing than trying to handle it as a PostBuildEvent. *Highly* recommend going that route instead. On Fri, Mar 29, 2013 at 12:00 AM, Michael Pitra wrote: > > Hi all,

[WiX-users] Wix Burn Addon Related Bundle

2013-03-29 Thread Marco Tognacci
I have read in some blogs about the Addon Related Bundle function of Burn. But I haven't found sample or usefull resource for making me able to use it. Is it a good way for installing language packs? I have some txt files that I install as feature in the msi of the main application but I want th

[WiX-users] Create language pack using Burn

2013-03-29 Thread Marco Tognacci
My application use some txt file for the localization of the application, which is the best way to make the user choose the language to install? I can make an msi as installer of my application with some features and the set of language files packed in a feature for language, in this way in the

[WiX-users] $(TargetPath) in PostBuildEvent does not point to correct location of MSI (with Culture)

2013-03-29 Thread Michael Pitra
Hi all, I have trouble signing a MSI generated with WiX 3.8.309.0. I try to achieve this in VS2012 with a PostBuildEvent in the Setup-Project, calling signtool with the $(TargetPath) as parameter. Unfortunately the $(TargetPath) variable resolves to $(ProjectDir)bin\Release\MyProject.msi, but