tag:blogger.com,1999:blog-985159635193633235.post4869443348336381894..comments2024-03-25T00:30:02.127-07:00Comments on ISWIX: Chicken and the EggChristopher Painterhttp://www.blogger.com/profile/12167478740431444267noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-985159635193633235.post-18922296078625781082008-06-04T11:29:00.000-07:002008-06-04T11:29:00.000-07:00You are defiantly correct, I was scratching my hea...You are defiantly correct, I was scratching my head the last couple of days, I found the 4.5 story yet incomplete and I was expecting the 4.5 will be pushed via WU but I think MS didn't finish the story for backwards compatibility? Who knows really the reason? But until good deployment solution introduced, the 4.5 will be on my shelve; I'm also looking for InstallShield to come up with yet another better resolution and easier way to resolve the chicken and the egg problem with 4.5 release.<br><br>Wael();Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-985159635193633235.post-45583302620339040232008-06-04T16:21:00.000-07:002008-06-04T16:21:00.000-07:00I seem to recall a comment where the MSI or WiX te...I seem to recall a comment where the MSI or WiX team said that 'custom actions are required because the platform failed you' (or something to that effect). This seems like the MSI platform has failed us in, of all things, the deployment story.JohnWnoreply@blogger.comtag:blogger.com,1999:blog-985159635193633235.post-89785977655288720822008-06-12T23:30:00.000-07:002008-06-12T23:30:00.000-07:00Hi Chris, over the last few weeks I have noticed y...Hi Chris, <br><br>over the last few weeks I have noticed you making lots of comments about the lovely isscript component supplied by IS. <br><br>I see your point's and you always back them up with some good technical standings which i admire. <br><br>But I just have to ask have you ever been on the enterprise side of deployment ? I am making an assumption you are a developer who needs to get out a single application regularly (don't get me wrong i see you as a highly regarded technical person) <br><br>But I have to ask have you ever sat with an enterprise deployment team for a day to see the issues they face with this abomination referred to as install script. <br><br>The day this is a single installer approaches many packagers will be very happy. <br><br>To go over a few points here, installscript offers many developers a nifty little way to get stuff on the machine easily by whipping up a quick bit of code. However do they always need to do this ? I think many times the answer would be no. <br><br>Windows installer is a complex beast but I feel that is not an excuse to use ISScript at every chance when there is a perfectly good native way of approaching the same issue. <br><br>Now some reasons why ISScript is such a pain in the proverbial butt. <br><br>1) it deploys DCOM objects (no issues here)<br><br>2) after doing so it promptly permissions those DCOM objects using APPID registry to allow local access only. <br><br>Now as most enterprise admins do, they try to push these applications remotely. Again no issues there. <br><br>Next the isscript gets deployed DCOM goes down, perms get set on DCOM objects. then the trusty application goes down. Whammo ! your hit with the trusty old ISScript is not installed. <br><br>Why you ask ? i just installed it ? The answer to this dilemna is the installing user doesnt have permission to the DCOM objects because it is not a local user specified in the NTFS of the DCOM.<br><br>From the opposite side of the fence to where you sit its a complete pain. Agreed its the package dev who causes the issue alot of the time but my question is what exactly is the reason it is needed so much when Wise for example doesnt offer a product of the same type nor do wise packagers experience the same pain ? <br><br>Over to you Chris (ps keep up the great work on your blog)John McFadyennoreply@blogger.comtag:blogger.com,1999:blog-985159635193633235.post-50286765351799653312008-06-13T07:09:00.000-07:002008-06-13T07:09:00.000-07:00It might be a useful blog post to give an overview...It might be a useful blog post to give an overview of my career. After all, my desire to write setup comes out of my SysAdmin days.<br><br>To be brief, I spent 2 years at Continental Airlines where I was the team lead for a (re)packaging team that was part of a larger SMS 2003 team and a larger Enterprise Engineering team. In that role I held a broadly defined role of `application integration` for both internal and external proucts deploying to an 18,000+ seat domain forest. I've also put a great many more years in the ISV / Consulting role for everything from one off installs to Product Line Developement environments where we are maintaining dozens of installs using a common code baseline.<br><br>Now, let's talk about InstallScript. The problems you describe come from versions of InstallShield prior to 12.0. Starting with IS12.0 (released 2 years ago ) the entire design was refactored to eliminate all of the problems you describe. <br><br>If you go back through my history of blog posts, you'll find that I've discussed this ad nauseum. :-)<br><br>Yes, the old InstallScript was horrible. It caused the majority of my install failures at Continental, that is until I figured out how to hack the DCOM Launching Impersonation settings. Then it was quite reliable. But now that it's refactored, you'd never even know it's there.<br><br>Now as I recently blogged about while discusing the new Yahoo! Toolbar CrapWare.... it takes a long time to heal from these kinds of mistakes as you are no doubt seeing in production environments.Christopher Painterhttp://www.blogger.com/profile/12167478740431444267noreply@blogger.com