Software Installation Technologies - Windows Installer

Member Area

May 17th

Home

External Blogs

Windows Installer

Windows Installer
DeploymentEngineering.com

100% Frustrated A very interesting thread is going on over at the WiX-Users list: `yep - back to being 100% frustrated` It's a very good read. Basically it started with Chris Mumford complaining that MSI sucks and that WiX doesn't make it any easier. At first there was just your typical rude fan boy comment ( yes Rob, WiX fan-boys DO exist and not everyone who disagrees with you is a troll or a newbie ): well.. the local supermarket here .. is looking for a Security Guard??? if u want i can help pass ya resume... Then follows a back and forth an interesting discussion of the pains of Windows Installer and WiX. [More] Problems with MS VC++ 8 SP1 Merge Modules [updated 5-16-08, see end of blog] I've had to explain this problem in detail to Microsoft Tech Support so I thought I'd go ahead and blog the details in case anyone else is using the MS VC++ 8 SP1 merge modules in their MSI installation and are unable to reference the assemblies at runtime after updating their product using an MSI major upgrade on a Vista [pre-SP1] system. Now, in fairness to the Visual Studio team, this problem is most likely an issue with MSI 4.0. I say 'most likely' because I don't know that for sure yet - MS tech support is still working with the MSI team on my case (# SRZ080507000538). However, I feel it's an educated guess based on the fact that installing Vista SP1 fixes the issue and that Vista SP1 contains fixes to MSI 4.0 [nice of the MSI team to slip undocumented fixes to MSI 4.0 into Vista SP1 - see the MSI team blog for a list of changes]. So, we're in the final stages of testing an update to our application (I'll call it OurApp SP1 and you should note that it is an MSI major upgrade with the Upgrade table entry set to uninstall the previous [FCS] install) when QA discovers that running OurApp SP1 on a Vista [pre-SP1] system where OurApp FCS is already installed results in the Win32 assemblies from the MS VC++ 8 SP1 merge modules (Microsoft_VC80_CRT_x86.msm and policy_8_0_Microsoft_VC80_CRT_x86.msm) not being published globally on the Vista system. This was causing one of our java apps to fail because it couldn't load msvcr80.dll when it started [and I know I can install the msvc80.dll binaries as side-by-side assemblies to the same folder and have the app work - but that's not the point of this blog]. Oddly enough, running an installation repair immediately after the upgrade install completes does* publish the assemblies globally. Furthermore, running the OurApp SP1 on a Vista [pre-SP1] system that does not already have OurApp FCS installed results in the assemblies being properly published. To make it even more interesting, installing Vista SP1 on the system before running the OurApp SP1 update results in the assemblies being properly published. Now, I'm not a novice. I did a thorough comparison of MSI logs from all three scenarios described above and, except for the expected time stamps and property values related to the different system configurations, the log files are exactly the same. BTW, I opened the MS support incident because I need to know whether or not the fixes to MSI 4.0 that were snuck into Vista SP1 can be applied independently of Vista SP1 (via a hotfix or redistributable) as it doesn't make sense for us to document that our customers should upgrade to Vista SP1 prior to applying our update. However, based on the fact that previous MSI updates have only been made available as redistributables, I'm not going to hold my breath. But I will update the blog once MS figures out the answer. [UPDATE 5-16-08] Evidently, this is caused by a known issue with the latest version of msvcr80.dll made available via merge modules (8.0.50727.762), see http://support.microsoft.com/?kbid=905238. However, MS isn't providing a means to incorporate the updated msvcr80.dll (8.0.50727.1434) into your installation via merge modules so the only way to get the update is to have your customer apply either the .NET Framework 2.0 SP1 or .NET Framework 3.0 hotfix (or Vista SP1, which applies the hotfix). The other way to resolve the problem, as mentioned in the KB article, is to move execution of the RemoveExistingProducts standard action so that it occurs after InstallFinalize. I think it's a pretty lousy decision on the part of Microsoft to not update their damn merge modules. I didn't find this issue until the tail end of the QA process so I can't change the location of RemoveExistingProducts without potentially introducing additional issues and requiring my customers to apply the .NET Framework update when my application doesn't use the .NET Framework is ridiculous. I should be able to incorporate the updated files directly into my application since MS provided a means for me to incorporate the bad files in the first place! Goodness or Badness? I've noticed a disturbing trend that I've also been guilty of and I'd like my readers opinions. As we all know, MSI databases are an open format. It's very easy to inspect them and transform them to fit the consumers needs. This is a good thing and yet it's a bad thing. It seems that various Windows Installer Experts/Bloggers seem to think it's within their right to stand up on their soapbox, proclaim to be the all knowing expert of "Setup Goodness(TM)" and then proceed to mercilessly judge the authors of packages who don't meet their exacting standards. Typically the packages being reviewed are from companies that are competitors of Microsoft. Granted, their are valid technical points, but I believe the message comes across in a very arrogant, vicious manner. So I'd like my readers opinion. Below are a few of examples for you to judge yourself. Afterwords, head over and vote on my new poll. VirtualBox 1.6.0 setup another example of the second law of thermodynamics Google Earth setup experience Google App Engine delivered to Windows by WiX. Google Toolbar Beta for Enterprise a "Trojan horse" MSI package ComponentID GUID Sloppiness Observation Welcome Back SeBackupPrivilege Back in October 2006 I reported about an undocumented security change in MSI 4.0/Vista that prevented Deferred NoImpersonate CA's from having the same security rights as they had previously had on downstream operating systems. The story was picked up by Microsoft's Vista Compatibility blog and justified as an attempt to tighten OS security. Maarten van de Bospoort of the MSFT AppCompat team said that it was `design decision made by the installer folks.` The argument was naturally pointless since any elevated process ( including MSI CA's themselves or bootstrappers ) could easily tweak the registry and restart the MSI service to get around the restriction. As an aside, my discovery was also cited by Microsoft MVP Stefen Kruger. Tonight I read on the Windows Installer team blog that after 1 1/2 years, Microsoft is finally correcting this issue an restoring SeBackupPrivilege. You Can't Escape .NET There is a reason that the experts are all unanimously saying that managed custom actions are a bad idea. You are free to ignore all that accumulated expertise but it doesn't seem like a wise thing to do. - Rich Thomson And BTW, this topic is obviously an old beaten horse... http://robmensching.com/blog/archive/2007/04/19/Managed-Code-CustomActions-no-support-on-the-way-and-heres.aspx - Holmgren Mathias The conversation of Managed Code Custom Actions once again came up on the WiX-Users list and naturally the thought police were out in full force faithfully enforcing the will of their Master, Rob Mensching. Rich's comment is my personal favorite. Has he really polled EVERY Windows Installer Expert or is he just taking the opinion of a few vocal experts who happen to work for Microsoft as settled law? I know many of the experts that I speak to are in favor of Managed Code CA's as are (currently) 72% of my readers who have voted on the topic. This question isn't a dead horse, it's an 800lb Gorilla that will not go away, will not be ignored and will not keep quite. Managed Code is the future of Windows development and it's time MSI recognizes that 100% declarative is a great goal but it will never succeed and that writing tomes of C++ code is not what developers expect in 2008. Thank God InstallShield feels differently. And just so I know I'm not loosing my mind, here is the opinion of GreenAJ as expressed on the WiX-Users list: I have head people preach diligently about the evil of managed custom actions. Let me just say a few things. Often we need tools such as SMO to better configure a database and the "in-box" custom action in Wix don't do quite what you need. In some of the installs I have worked on, I need to migrate old databases, Restore, Detach, Attach, run very large batch scripts, hook into the batches to echo "Print" SQL statements to the MSI logs. Also, setting up a Web Service in IIS7 is unsupported. In comes .NET in a Custom Action to the rescue. This logic can now be coded in a more affordable way than vast tomes of C++. What I have font to work greatly is to use a Unmanaged C++ harness to load .NET assemblies and run the custom action logic. The C++ harness uses the unmanaged .NET API for setting up the app domain and firing off the .NET code in the assembly. All the .NET code is run as a DLL custom action. NOTE: These are not the "Installer Components" that leave their carcasses in the installed product. They are simple extracted in the install, ran, and then deleted (the DLLs are loaded by the unmanaged C++ in another App Domain so they can be chucked). -GreenAJ Where would you go? I've been a bit exhuasted and cranky lately as we get into the tail end of my wife's chemotherapy treatments. (Only 3 more to go!) We really need a vacation badly but we probably won't get a chance until this fall. Other then the obvious answer ( Wherever your wife wants to go! ) Where would you go spend a week to relax if you had a chance? As an aside, I sometime look at my referral logs and some of you guys live in places I'd really love to visit. Having a Clue Shouldn't Be Optional I was browsing the blogosphere tonight when I came across this frustrating blog post from a frustrated blogger who fits a growing stereotype: a hubris software developer who is clueless about Setup Development and loves to blame his own shortcomings on InstallShield. He posts twice ( here and here ).... I'm trying to be gentle tonight but here a goes dissection: It's a .NET 2.0 Winform project, which for some god-awful reason uses InstallShield instead of the free installer that comes with Visual Studio I guess just because VDPROJ is part of Visual Studio ( which, btw, is not free ) is must be good, right? I mean, it's obviously the better choice then InstallShield and anyone who would think otherwise must be an idiot! ( Do I need to enumerate it's weaknesses here? ) So in order to add any kind of logging or streamlining to this abomination of an application, I have to learn this language. Hmm, he never says what project type he's using but I'm guessing it's not Windows Installer. If he was, InstallShield has a project setting to turn logging on automatically and if that's not enough information, a call to MsiProcessMessage() here and there would certainly add any additional information you could need without requiring a whole lot of coding. Why don't I like it? Well, first there's the obvious: Nobody should have to learn a whole extra language just for their installer; it costs money when we already have a free product that works better Oh I see, Setup Development isn't Development! You shouldn't have to actually learn anything, it just be super easy. OK fine...he's got a little bit of a clue here, that sure would be great... but it's still SETUP DEVELOPMENT. Oh but VDPROJ works better (not). Then there's the less obvious stuff: No Framework accessibility, needing to deal with handles and memory pointers (Unsafe code; oh noes!), and no try/catch/finally block equivalent. This thing is just a big ol' turd. I'm sorry, is this guy using the same tool that I'm using? InstallShield has THE BEST .NET framework accessibility model out there. For a couple years now you can instantiate .NET classes using CoCreateObjectDotNet() and DotNetCoCreateObject() and in InstallShield 2009 you've got the ability to declarative invoke .NET code including passing the handle and using Interop to communicate back with the Installer. This kicks the ass out of the crappy InstallUtil pattern that the .NET Framework and VDPROJ dumped on the world. Also InstallScript has had exception handling since about 1999 or so when IS 6.0 came out. (PS: Maybe he should come vote Yes for my Managed Code Custom Action Poll ) Project Newgood, which will replace Project Convergence, will use the installer built into Visual Studio. When coding a VB.NET application, does it not make sense to code your installer in VB.NET as well? Code your Install in VB.NET? Oh my, it sounds like he's going to be using InstallUtil and VDPROJ. May the force be with him.... So by now your either laughing, nodding your head up or down or already surfed to your next web page. If you've hung in this long I promise I'm almost done.... just a few more thoughts: 1) Part of this problem is Microsoft/InstallShields fault. So little has been done to foster the professionalism and education in this space. Search for help from your local development ecosystem and you'll likely hardly find anything. No code camps, no user groups, few few few MVP's ( seriously, every software shop in the world ships product but there are around a dozen MVP's worldwide! ) You'll find precious few books on the shelves of your local bookstore; the ones that exist are ancient and/or completely get it wrong. I want to say college courses barely touch this area but I'll leave that to Colby to comment on since he's got a better perspective. There is also no certification tracks. For the last 12 years I've been writing Installs I've seen over and over that you get very little respect. Every time I change jobs I have to once again destroy misconceptions and ignorance and show the mighty developers ( who typically want write anti patterns into the requirements if there is a requirements document ) how to do things correctly. Almost always there has never been a dedicated installation professional following industry best practices. It's always some junior CM analyst or developer who gets stuck writing the installs and is now happy to dump it like a hot potato. 2) Another part of the problem is InstallShield has a really positive yet really negative image problem. On one hand they are THE brand name trusted product and yet they are also a huge target of developers who get frustrated and then blame InstallShield instead of blaming themselves. They then flood the blogosphere with `InstallShield Sucks`. This is read by other equally clueless developers and a vicious feedback cycle is formed. This probably wasn't a problem 10 years ago, but in today's ever connected world, the damage will penetrate more and more regardless of whether the complaints are based on reality. InstallShield can't risk keeping quite like they have in the past. Real efforts need to occur to educate and foster loyalty from the development community or otherwise I see a really bad future. Especially once Visual Studio comes out with a decent WiX authoring tool. VSTO Lessons Learned A few months ago I was asked to write an Install that deployed a few .NET 3.5 features: Tray Application (required) Office 2003 Word Add-In ( Optional ) Office 2007 Word Add-In ( Optional) At the time I blogged I was exploring these technologies and asked if anyone had already done it. Lately several people have emailed me asking if I ever figured it out. I have figured it out and during the process I confirmed that ClickOnce/VSTO Installer/Per-User Installs are STILL a BAD IDEA!! Using this process you can streamline (merge) multiple VSTO add-ins, other system components and related setup prereqs into a single All-Users install that can be deployed using traditional techniques. I've been meaning to write a white paper with sample code on this subject but I've been too busy. Until then, here's a quick recipe using InstallShield 2008 ( InstallShield 2009 would be a little cooler using chained feature conditioned Setup Prereqs to streamline the relationship between the prereqs and the features. ) You'll need to bring a bunch of things together: 1) Download the .NET 3.5 Prereq ( Web downloader of Full Install from InstallShield ) 2) Create the VSTO 2005SE and Office 2003 PIA Prereqs ( Conditioned for installation if Office 2003 Installed and made optional) 3) Create the VSTO 3.0 Prereq ( Conditioned for installation if Office 2007 Installed and made optional) 4) Blocking SystemSearch/Launch Conditions to check .NET 3.5 is installed. 5) SystemSearch / FeatureConditions to disable Add-In features if related Office versions aren't installed. 6) `Feature Constraints` to not allow the user to select the Office-Addins if the related Office versions aren't installed. 7) A .NET Class for calling referencing the System.Security.Cryptography namespace for calling the BCL methods for installing various certificates. These will be needed to backup the add-in manifest for run time verification purposes. ( Get rid of an annoying dialog that is bad if the user says no. ) 8) A .NET class for calling the System.Random class to generate a random number. 9) Office 2007 doesn't allow Add-Ins to be installed Per-Machine but it does expose a rather interesting pattern for migrating data down to the user profile without invoking an MSI repair scenario. Unfortunately this pattern requires that you create a registry key during the uninstall ( which MSI doesn't support ) so you'll need a custom action for that also. To understand this registry migration pattern, how Office loads Add-In manifests and the roll of signing, read through the following articles.... ( make your .NET developer read it also so that he can get on the right track of knowing how to build his code and where to expect the runtime execution to occur on the file system ) Deploying your VSTO Add-In to All Users (Part I) Deploying your VSTO Add-In to All Users (Part II) MSDN Forums: Merge (VSTO) Setups New Poll: Managed Code Custom Actions I have a new poll, are you in support of Manged Code custom actions? Note: I'm not talking about horrible Installer Class CA's here, I'm talking about CA's that can actually communicate with the MSI handle and truly support silent operation without 1001 error message pop-ups even in silent mode. If you aren't sure or don't understand the debate, please research the topic before voting. Blog Articles Pro Managed Code Custom Actions: Writing managed code custom actions A New Approach to Managed Custom Actions More Fun with CoCreateObjectDotNet Managed Code CAN Access the MSIHANDLE InstallShield 2009 Beta Part II ( Managed CA's ) .NET CA's are NOT (always) Evil Blog Articles Against Managed Code Custom Actions: Managed Code CustomActions, no support on the way and here's why. Don't use managed code to write your custom actions! Custom Action Guidelines Dealing with Bullies In the past, I've made observations that WiX doesn't do a whole lot to help setup developers create a UI for their package. I mentioned that most `Hello World` examples show a simple Component element snippet as evidence of how `easy` WiX is. Unfortunately the resultant packages don't actually have a UI. Professionally, I think this is unacceptable for the vast majority of situations. I've always been a fan of the patterns discussed by Leslie Easter long before MSI ever came out. The concept of interviewing the user and having a point of no return. I don't like the click, fire in the whole pattern unless the user opts in for this behavior via a /s or /qn type command. Of course the author of WiX couldn't possibly admit that this was a weakness. While he and his cronies will judge everyone else to exacting standards, this no-UI story was just completely fine. After all, he's a self-professed command line / notepad kind of developer so why would anyone else need a UI? Unfortunately newbie setup developer pick up his tools and follows the provided examples and assume that the resultant packages are normal best practice. Why do I think this? Read this article where I found a trend of UI less packages authored in WiX. The trend was so powerful that I could `identify` a WiX package just by the fact that it installed without ever showing a UI. Over time,WiX has improved (some) and does now provide a basic UI experience. Of course most WiX packages all look the same because making changes to that UI experience is less then easy since the tool doesn't have any designers. InstallShield on the other hand lets you completely extend the UI experience ( either using Basic MSI or by using InstallScript MSI with an external UI handler ) and also allows you to pick default skins/templates to make fast and radical changes to the appearance. The other day, the author of WiX was talking about how it was obvious Google used WiX because the UI was Red instead of Blue. Now I probably read into this a bit, but based on previous comments of "I never cared much for InstallAware. Their MSI authoring tool just looked like an InstallShield clone..." I detected a certain bit of pride that WiX packages were somehow better looking because they are all red while the rest of the industries use blue. After all, he's hates InstallShield clones and all of the WiX toolset ( icons, votive, ectera ) is all branded in a red color scheme. Sure, I might have read into this too much, but I don't think I'm that far off the mark here. Well, I think the whole red vs blue thing is silly. I decided to post a blog showing how much farther InstallShield can take the UI experience. Well, I obviously struck a nerve with Rob because he decided to post a personal attack against me calling me a troll and claiming that all of my points have no merit. Well, I have several thoughts in response to his unprofessional, shameful hit job: 1) I'm not surprised Rob resorted to such personal attacks. After all, the fact that he would take a confidential business meeting between employees of Microsoft and InstallAware ( negative impression, sleazy and unprofessional ) and post it on his blog tells a lot. 2) My observations about the shortcomings of WiX are very valid no matter how much he attempts to dismiss them as troll posts. I've been doing installation work for 12 years and whether he believes it or not, my knowledge of this space is well vetted. 3) His characterization of me as a `troll` is completely invalid. Per his own linked definition: An Internet troll, or simply troll in Internet slang, is someone who posts controversial and usually irrelevant or off-topic messages in an online community, such as an online discussion forum, with the intention of baiting other users into an emotional response[1] or to generally disrupt normal on-topic discussion. This website isn't an online discussion forum. It's MY blog where I post MY observations and opinions. I also invite other setup developers whom I trust to contribute their observations and opinions and allow readers to provide their feedback via comments to help balance the perspective. But there is no attempt to disrupt normal discussion because we choose what to discuss, not the online community. Therefore, I can not be a troll ( in this context at least ). It's up to my readers to judge my content and decide to visit again or not. Based on the feedback I get and the growing number of repeat visitors, I believe I'm doing fine. However, if Rob finds my opinion so objectionable, he is more then welcome to not visit my blog. I will continue to visit his blog though because while I don't agree with much of his ideological rhetoric ( custom actions are (generally) an admission of failure ) I have enough knowledge and experience to pick apart what I read and adopt the pieces that I find reasonable. Anyways, that's the last I'm going to say on this matter. I'm much more interested in blogging about pushing the boundries of MSI to support managed code custom actions rather then simply accepting that it's wrong to do so. While certain people at Microsoft don't seem willing to step up and support this, the people at InstallShield have been stepping up I'm very busy putting together some sample projects to demonstrate why this is a good thing.

DevInstall's Recent

Visitors: 501078

Extended Menu

MSI 4.0: Latest Blogs