Re: [WiX-users] Fwd: LGHT1055 InstallUISequence warning

Wed, 26 Jul 2006 01:07:56 -0700

Inlining back :)

On 7/25/06, Derek Cicerone <[EMAIL PROTECTED]> wrote:

inline

 

From: Shmarya Rubenstein [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 25, 2006 10:20 AM


Subject: Re: [WiX-users] Fwd: LGHT1055 InstallUISequence warning

 

Derek,

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).

[DerekC] In WiX 2.0, a wixlib is basically just a concatenation of the xml from several wixobj file.  In WiX 3.0, we also allow a wixlib to carry localization strings and full binaries in a cabinet file (making this very similar to a merge module).

[Shmarya] Ok... I'll look into this... I assume it's documented in the chm?

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...

[DerekC] You should absolutely be able to reference a single component from multiple features using multiple ComponentRef elements under each feature.  In WiX 3.0, it's also possible to create groups of components to be included under a feature by using the ComponentGroup element (this brings you extremely close to what you'd get with a merge module).

[Shmarya] I know that I had difficulty with this... kept getting errors about components being referenced from more than one feature... perhaps it was a bug which is now fixed?
 

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 ;)

[DerekC] I see.  Why not just install your extensions next to wix.dll so that the assembly name is enough to find them?  Also, if you run wix under .net 2.0, it should be possible to have wix use an extension targeted to .net 2.0.  You'll want to be very careful about creating a private fork of the wix sources – it can become difficult to keep up with latest source drops over time as the changes collide.  In a group I used to work for, we originally took wix source drops but eventually found that the integration costs of moving to newer versions became so expensive that it was a lot easier to just stop making custom modifications and just ensure all the stuff we wanted was supported by the main toolset (this is where the wix extensions came from actually – a desire to release binaries that still allowed custom authoring).  So, if there is a good reason to support loading extensions by path, perhaps it should be supported in the wix toolset directly.


[Shmarya] I don't see my  work as a fork really... But I completely agree with you... I'd prefer to have my mods implemented in the official binaries. Unfortunately, I'm having trouble getting my employer to allow me to sign the Assignment Agreement... :(

Just out of interest, the documentation says that path based loading of extensions is allowed... so the fact that it doesn't work is probably a bug...

On 7/25/06, Derek Cicerone <[EMAIL PROTECTED] > wrote:

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 Ludlow

Subject: 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,
Shmarya

On 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




--
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

Reply via email to