Menu
▾
▴
RE: [WiX-users] register COM component using tallow output
|
From: Rob M. <ro...@us...> - 2004-12-22 09:58:12
|
1. Ideally a COM server is always installed to the same location to prevent the registry keys from needing to point at two files at the same time (obviously an impossibility). Also, as you noted, SystemFolder is not to be used as a dumping ground for anything but system stuff. Your own directory under CommonFilesFolder is a much better place to place shared COM servers. I mentioned a previous email that a few years ago, over holiday break, I and another developer did a lot of work to move much of Office's shared COM servers to CommonFilesFolder. 2. Actually, the problem I described with the Class and ProgId tables can occur with perfectly valid authoring being used in unexpected ways. For example, there was a scenario in OfficeXP where if you installed the Speech Control Panel Applet (yeah, I know, who uses speech input?) then installed OfficeXP, the next time you launched the Speech Control Panel Applet then you would get an install on demand that would prompt for the OfficeXP CD (talk about confusing users). That would install (or repair <sigh/>) approximately 100 Megs of speech calibration data for Office before the Speech Control Panel Applet would launch. The problem comes down to the fact that the Windows Installer registers the COM advertisement with the last product installed. If you use shared COM servers (like the Speech API) and it was installed via the Windows Installer Class or ProgId tables then your application alone does not in control of its installation behavior. This is why I personally recommend not using the Class table and using the ProgId table very carefully (only for publishing/assigning Extensions/Verbs). Unfortunately, the Speech team decided to ignore the warning and picked up some PSS hits for it (note: PSS is expensive). 3. On a related thread, I believe Michael mentioned that the current Office installations use the Class and ProgId tables. There are two reasons for this. First, the side-effects of the Class and ProgId table were not well understood until Office 2003 was underway. "Renovating" all of the existing CLSIDs and ProgIds was not an option at the time and we were not clear in our messaging to developers about the side-effects of advertising the COM registration so many of them did it "by default". From what I've been told, the Office setup team got in earlier this time around and is trying to prevent the Class and ProgId tables from growing (and may shrink them). Second, to get assigning/publishing to work via programmatic activation, the ProgId (and sometimes Class table) is required. -----Original Message----- From: wix...@li... [mailto:wix...@li...] On Behalf Of Michael Sanford Sent: Tuesday, December 21, 2004 12:59 PM To: 'Orion Edwards' Cc: ro...@us...; wix...@li... Subject: RE: [WiX-users] register COM component using tallow output I'm not on a warpath, I've just found a lot to talk about here! ;-) Seriously, I don't have any bones to pick with anyone, but then, I don't do politics either. If I think you're wrong, I'll call you on it. I'd expect you to do the same in return, and believe me, I make plenty of mistakes! Just one follow-up to what I said about "last in wins": I'm aware of the default versioning rules and was not referring to that. You are right that by default an older version will not overwrite a newer version, but only if they are installed to the exact same location. Microsoft discourages dumping stuff into System32 now, so the possibility of this happening is extreme. People tend to dump dll's into their app folder, which means that in that case, an older version of a COM component DOES replace newer version (at least as far as the two apps using it are concerned). The problems about these repairs kicking in that you and Rob have mentioned are the result of crappy authoring, not (per se) a flaw in Windows Installer. The thing that gets me is that tools like WiX are supposed to empower you to do things the right way, not abandon them cause some other moron did it wrong. I may be the only one, but I believe in healthy debates. A healthy debate is not a flame war. I believe in holding Rob to his laurels and calling him out if I think he's slipping. Just cause I debate a point doesn't mean I don't like or respect you. It's not a sport for me either. I know this stuff inside out and want to see it advance, not flail. Debating makes both people stronger and smarter, and solid solutions are born from healthy debates. -----Original Message----- From: wix...@li... [mailto:wix...@li...] On Behalf Of Orion Edwards Sent: Tuesday, December 21, 2004 3:20 PM To: Michael Sanford Cc: ro...@us...; wix...@li... Subject: RE: [WiX-users] register COM component using tallow output Quoting Michael Sanford <msa...@70...>: > Which Merge Modules? The 43 or so that Microsoft makes available for VS6 > developers, plus XML, Soap, VBA, FoxPro, Crystal, etc... > http://www.microsoft.com/downloads/details.aspx?familyid=f9d19334-61ec-48cf- > bb4e-3aec65edd50b&displaylang=en I have used the MSXML4 merge module and that seems to work fine, but some of the other ones which ship with VS.net (perhaps not VS6, I can't comment on that as I haven't used VS6 for a long long time now) have exhibited strange behaviour - like not installing to the directory you tell them to unless you mangle things up a bit, etc. > I understand your reasoning, but I disagree. Resiliency is one of the key > features of Windows Installer and not one I am ready to dismiss. The > approach you are using (last in wins) is only a very slight hair better than > using self-registration, and does nothing to solve the dll-hell issues that > abound. The solution to the problem is not figuring out how prevent msi > repair dialogs from popping up, it is figuring out how to install App2 > without breaking App1, and you are taking us backwards, not forwards... Not quite... If you tie the registry entries to the component containing the COM server exe/dll then the installer versioning rules will mean that it's not 'last in wins' but 'greatest version wins' which is the way it should be... As far as advertisement goes - I think it's a nice feature, but it's not something I've ever wanted to use as whenever I've encountered it (I hit it the other day in access when I tried to open the 'Linked Table Manager' - default install of access) it's been a pain in the backside - All I wanted to do is open the damn thing but I ended up having to find a cd, wait for 5 minutes for it to install, the whole shebang... pissed me off. Oh and the 'constantly repairing' bit - my platform sdk MSDN library bit is doing that right now whenever I try use the library to view stuff. F&$^ing annoying and as such I'm all in favour of whatever feature causes these problems to be binned :-) > Yesterday you were advocating going "by the book" and following Microsoft's > documented recommendations, but today you seem to be perpetuating the > "gossip" you warned us about yesterday. Don't get me wrong Rob, I love WiX > and what you're doing here, but you have two roles that you need to balance > here. As a Microsoft employee and "the WiX guy", you need to make a very > clear distinction between what is Rob Mensching's personal opinion, what is > Microsoft's official position. When you say something, people tend to think > you are stating Microsoft's position. > > Lastly, I just want to point out that your pals on the Windows Installer and > Office teams seem to disagree with your conclusions. Office has one of the > most complex installations around, and they don't seem to share your > sentiments. They use the hell out of the Class, ProgId and TypeLib > tables... In defence of rob here, as you seem to be on the warpath at the moment michael (yeah I read your blog entries about smoke), IIRC he was on the office installer team for a long long time. Re: Going By The Book - As I understood it, it was a push to make people pay attention to the documentation - if MSDN says to do something a certain way, then there must be some kind of reason behind it, so don't just dismiss it with a wave and a sneer. However, I for one have encountered MANY scenarios where going by the book didn't turn out the right way, and in addition to that, MSDN amongst other MS resources often has multiple ways of doing the same thing, so 'the official microsoft position' is usually fuzzy and covered in mud at best :-) So as far as development (of installers or anything else) goes, my stance is this: Try to find out how to do it correctly, if that fails, apply common sense and gather up all the information you can find from whatever sources you can find, weigh them all up objectively and go from there - Rather than being dogmatic about what comes from where, and trying to attack the posts of others and start a flame war... this is a development mailing list, not a counter-strike forum, but it is the internet and a bit of patience and a sense of humour goes a long way. -Orion ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ WiX-users mailing list WiX...@li... https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ WiX-users mailing list WiX...@li... https://lists.sourceforge.net/lists/listinfo/wix-users |