John Calcote wrote: > Funny - you'd think that Microsoft would be using these same > merge modules for their own applications that want to install > the MSVC runtime libraries in the side-by-side. In that case, > wouldn't they have worked out all the bugs long ago?
Well, it's not exactly bugs, it just raises lots of warnings. So it is "useable" and "works". Then, I wouldn't think they'd use merge modules extensively thmenselves. I think I read something on this list here that use of merge modules is discouraged in general. I have not bookmarked it, though. > I guess I'm being a bit sardonic here - it's clear to me that when > things like this happen, it shows that the provider has their > own way of doing things. [Sure. And Microsoft has a long record of not doing things the Microsoft way. I have a book in front of me called "Windows User Experience" printed by Microsoft Press. It basically describes the do's and don't's of Windows UI development. I have yet to see a single (recent or not) MS application that comes even close to adhering the rules given there... And my long time favourite (which might be an urban legend, though...) is that MS does not use SourceSafe for version control themselves... But I think they are not to be blamed (alone). I guess there are only a few software companies out there that eat their own dog food exclusively ;-)] > I don't like the idea of working around the issue by > statically linking library support - the entire purpose of > the side-by-side cache is to allow multiple versions of a > library to be installed - in effect, it's Microsoft's answer > to Linux/Unix's built-in library versioning system. Since > DLL's aren't normally named "something.dll.x.y.z" (and even > if they were, the operating system wouldn't try to interpret > the values), they needed a secure way of installing multiple > versions of a library and have apps use the ones they care > about without conflicts. Right. And I think the proper solution would be to use the merge modules in the final installers. Nobody ever got fired for doing it the MS way *cough* > Anyway, I just wondered if there were some WIX approved way > of adding the redistributable package. It appears that we > just use the merge-module technique, or statically link the libraries. *shrug* I am a novice. I have successfully incorporated a third party .msm (some dongle driver), the MS merge modules also work (as stated above). Merge modules generated by VS deployment projects do not seem to work well, though. Within my own setup from my (very short!) experience I'd say Fragments are the first choice, followed by <?include?>. No need for merge modules internally. > BTW, there is also a separate installation utility (.exe) for > redistributables - vcredist... .exe, but I'm fairly certain > this is not the proper way to integrate into WIX installers. Uh... never heard of that... Andre' ------------------------------------------------------------------------- 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
