I hadn't thought of using wixlibs - I'll look into that... How does it work? .wxs are compiled to .wixlib and then can simply be included on a link line? what's the difference between this and .wixobj? Will I still have the same kind of powerful dependency chaining as I have with merge-modules (similar to .net referencing - anything goes except circular references).
I know that I had trouble with Component referenceing because you can't reference a single component from multiple features... at least, I couldn't get it to work...
The reason I'm compiling wix in net2.0 is because I needed to apply a fix to the code which loads extensions (it calls Assembly.Load, when it should conditionally call Assembly.LoadFrom if a path is passed on the -ext cli instead of an assemblyname), and its just easier for me to compile in 2.0... I've also written an internal extension which is 2.0 specific... Other than that, no specific reason ;)
Have you tried using wixlib files and Fragments instead of merge modules for breaking up your authoring into lots of little pieces? I would strongly suggest this solution over lots of merge modules because you will end up with a much smaller msi package (it won't have all the modularization guids), better error messages when problems occur, much faster build times (because you aren't creating tons of cabinets and doing lots of expensive merge operations), and you should be able to support the same scenarios with wixlib files as merge modules.
Also, why is it necessary to custom-compile WiX 3.0 for .net 2.0? WiX is completely capable as-is under .net 2.0 without needing to be natively compiled for it. It can handle all .net 2.0 assemblies fine.
Derek
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Shmarya Rubenstein
Sent: Tuesday, July 25, 2006 6:37 AM
To: John LudlowSubject: Re: [WiX-users] Fwd: LGHT1055 InstallUISequence warning
I'm actually using a very similar pattern, with lots of little merge modules which group different components, and <Dependency/>'s between them. I find this to be a good pattern, as it helps with complex dependency chains - which simple component/feature relationships just don't cover....
A couple of things which I'd like to see in order to make the pattern even better:
1. Automatic merging of module dependencies - ie: if you merge module A, which depends on module B, and B is sitting in a folder next-to A, B should be automatically merged. This should be simple, as a warning is currently issued... replace the warning with the actual merge ;) I've opened a feature request for this one...
2. When deciding whether a module needs to be rebuilt, the timestamps of the included files should also be checked, not just the .wxs file... Otherwise, you end up having to rebuild the modules every time to be certain that they contain the correct versions of the files...
I'd love to see the above implemented....
Re my problem, I'll try and update wix again (using 3.0.1820.0 custom-compiled in .NET2.0)... Maybe that'll help...
Thanks,
ShmaryaOn 7/25/06, John Ludlow <[EMAIL PROTECTED]> wrote:
On 7/25/06, Shmarya Rubenstein < [EMAIL PROTECTED]> wrote:
It doesn't look like there are empty rows... I'll try dropping the table and let you know if that helps...
Ok. The only thing that made me think of that is the fact that, in the error, the name of the action is an empty string.
BTW: isn't it an error that Wix generates empty tables which are optional?
Hmmm, possibly yeah. I know it doesn't include XML or IIS stuff unless it needs to, but then these aren't included in the standard schema - they're WiX-only stuff. I suppose there might be a reason why WiX includes it.
Also, have you tried merging multiple msm's with empty InstallUISequence tables?
Yeah - we have a slightly freaky setup here where every logical group of files gets put into a merge module. The idea is that any file that might at some point become shared should be in a merge module so you can just plug it into the new installer. Well, that applies to pretty much all of our files, so we end up with a gazillion merge modules ;)
The upshot is that every installer is pulling in a bunch of merge modules. I had a quick squiz through a few and it looks like they're all getting a set of blank sequence tables (except the ones that really do have a custom action - those obviously have their sequence tables populated).
--
Shmarya
-----------------------------------------------------------
[EMAIL PROTECTED] - http://shmarya.net
NUnit rocks! http://nunit.com
--
Shmarya
-----------------------------------------------------------
[EMAIL PROTECTED] - http://shmarya.net
NUnit rocks! http://nunit.com
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
