Bah, just re-read your original message. Yes, you'll need a custom
action to control this. If you are using the feature tree, you will
want MSI 3.0+ I believe so that you'll have access to the extra events
for the feature tree in those versions.
On 6/13/06, Joannic Laborde [EMAIL PROTECTED]
Title: Message
Hi,
Yes,
I was talking about Help 2.0 Hxs files.
I implemented the functionality by modifying
MSHelp2_RegTables__RTL_---_---.msm file appropriately
and also I used HTML_Help_Registration__RTL_---_---.msm.(which are distributable)
And now I am able to register and
MSI2XML and Dark are different in that MSI2XML only attempts to transform MSI schema and data into XML format while Dark attempts to translate MSI schema/data into an entirely different schema that just happens to be in XML format.InstallShield uses MSI2XML ( there is even a credit in the help
Its probably good to note that msizap should be used sparingly because it's
a bit dangerous - it sometimes goes overboard in what it removes - so you
really want to make sure this tool is only used on development machines.
Derek
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
I made this comment because Rob said:"Have you looked at dark (the WiX toolset decompiler)? Dark v3 is particularly solid. It will drop all of the files and .wxs authoring in such a way that the compiler and linker can put it all back together."This implied an IJW symbiosis between Dark and Candle
In a previous message I talked about Dark not extracting the Package ID from MSM's.Try this: ( Using Dark 3.0.1703.0 ) and Orca 3.0.3709.371Create a New MSI database using ORCA and look at the Summary Information Stream to validate that it was a ProductCode. Save the database as an MSM.
The PID_REVNUMBER thing
sounds like a bug in dark.
If you have a valid
MSI/MSM file I do expect dark.exe to be able to decompile it. However, candle
appears to be far more exact about what it allows one to put into an MSI/MSM
than some of the other authoring tools out there (I know this
Upon further investigation into this
issue, you appear to be correct about the correlation of the Revision Number
summary info property and the modularization guid. This means that the
way WiX currently generates merge modules is wrong (and has been wrong for a
very wrong time).
I need
You have to forgive me,many terms are overloaded or expressed differently when you go from InstallShield to MSI to WiX.( For example SystemSearch, AppSearch, RegLocator, RegistrySearch) I tried to make sure that I understood the way WiX expresess things before posting but unfortunatly I
Theres an open bug against simple
xsd types not working for now you should just use wix.chm instead
it should have no broken links.
Derek
From: Christopher
Painter [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 13, 2006 5:48
PM
To: [EMAIL PROTECTED];
Hi,
First just a warning - this is my first foray into wix.
I am trying to build a wxs file to install an asp.net web service and an
asp.net web app that is a front end to it.
If I understand the logical component and feature constructs
correctly then each of these is a component and because I
I agree about VSI MSM's... unfortunatly I'm stuck with about 700 of them. I'm also have about 80 MSM's that were statically written using ORCA because it couldn't be done in VSI and the developer didn't want to use InstallShield. It was killing me to be storing MSM's in ClearCase so I tried
More generally Components are small and Features are things users can
turn on and off. So, typically a Feature contains many Components.
Also, Components install everything to a single directory. So if you need
to install to different Directories you need different Components.
Does that help?
If I remember the ref counting properly, and looking at the MSI docs for the
msidbComponentAttributesSharedDllRefCount bit:
MSI ref counting just works, on components, and I don't know if the OP was
thinking of MSI ref counts or the SharedDlls ref counting (which can cause
files to remain after
14 matches
Mail list logo
