- The path to mastering Windows Installer to get packages to do exactly what you want them to do is not defined very well.
- Getting all of the other developers on your project to care enough about Setup to convince them to go down that path is next to impossible.
- There is really no good ways of assessing and recognizing developer’s efforts in this achieving the above goals.
Below, I’m going to make references to the `Fundamentals` rules 1, 2 and 5 detailed on the Windows Installer Team Blog at
http://blogs.msdn.com/windows_installer_team/archive/2006/05/01/587990.aspx
Rule 1: Learn the Windows Installer Technology
Rule 2: Know Your Way Around the Installer SDK
Rule 5: Build Setup Into Your Application Development from the Start
On the surface I agree with these goals that these `rules` describe. However, I think the problems are oversimplified and anyone claiming to have easily solved them and created a finely tuned distributed setup developing team capable of deploying properly behaving MSI packages is selling you a bill of goods. There is one such particular company that comes to mind that loves to boast this claim, but I'm not here to name names.
First rule #1 states that frequently people author bad packages using GUI based editing tools and that you must first master Windows Installer BEFORE you author packages. I agree! There are a lot of bad packages out there that have been authored by part-time Setup Developers who haven’t bothered to master the Windows Installer API.
However, Windows Installer is just simply WAY too complicated of an API to assume that you can `master` it before you even start authoring packages. This is like saying you must master the Microsoft.NET framework before you can write a C# program. Mastering a technology comes from iteratively gaining knowledge and experience, often at the expense of making mistakes along the way.
I'll agree that blindly using an Industrial Strength Household Name MSI Editing Tool (ISHNMET or InstallShield if you can't read between the lines) and completely disregarding the underlying API is a bad thing, but what’s the alternative here provided by the Windows Installer team? Using ORCA and home built scripts to call the API and create packages?
Rule #2 says the best way to learn Windows Installer is the Windows Installer SDK. It then goes on to say that the SDK is not meant to be read front to back. Combine that with the thinking that `ISHNMET too high level and therefore bad` and WOW, can you say Up The River Without A Paddle? Let me get back to this though...
Rule #5 says that developers should treat Setup as first class development tasks and contribute to the installer source. I completely agree, but according to Rule #1, they can't do so until they `master` MSI. Let’s get back to the Up The River Without a Paddle problem. If it's so difficult for one person who actually CARES enough about Setup to attempt to master MSI, how do you expect dozens of developers who DON'T care about Setup to master MSI? Furthermore, how do we expect them to design integration points into their application that take setup into consideration? Also, how do we expect them to try to learn all this when we say the pretty GUI tool that will help them is `evil` and that they really need to dig deep into the SDK and master MSI before they actually start authoring packages?
Seriously, you might be able to get a group of developers quickly trained how to drag a file into a VDPROJ GUI, but if you expect them to master the various patterns in Windows Installer, you are really in for a long struggle, especially if the SDK documentation is your best resource. The first time a developer wants to remove a file from the package and expect it to disappear he'll just go into VDPROJ and delete the reference. He won't care about such concepts as minor upgrades and transitive components. Another scenario is the first time he needs to install a service; the developer will dig into Installer Class custom actions to get the job done. He’s not going to care about why it’s better to use the ServiceInstall table. He’s certainly not going to care enough to try to write an unmanaged post build process using the Windows Installer API to hack and slash the package. Regardless the end result is another package will be deployed that simply fails to measure up because the developer assumed setup was `easy`.
What I'm really trying to say here is I basically agree with the goals of these best practice rules, but I feel that we are a very long way from being able to solve them. IMHO, authoring tools like WiX and InstallShield are both good in that they try to steer the developer into complying with the intricate patterns of MSI. (Assuming you can get two MSI developers to agree on the definition of compliance.) InstallShield attempts to steer you by abstracting you from the table data with point and click work flows and WiX attempts to do it by abstracting you from the table data with a `safer` schema and a compiler which is pedantic enough to not `let` you author bad table data.
I do agree that authoring tools shouldn't serve as a replacement for understanding the underlying Windows Installer service, but they are critical in accelerating the learning and development curve and shouldn't be looked at as the problem. (I know, you might be saying that WiX isn’t the problem, only ISHNMET is the problem…. B.S.) From the Windows Installer team, what’s the alternative solution? ORCA and the SDK documentation? If so, ugghhh……
Once you are ready to go from ISHNMET 101 to MSI 201 to MSI 301 (and that should be the goal of everyone contributing to a package) then there are very few resources to assist you. The SDK is a bear to read and understand (until about the 20th time you have read it along with blog articles to point things out). There are very few books on the subject. Most material is very informal (such as community forums and blog articles). There is very little training available and absolutely no certification tracks available. If you look at typical C# classes that cover setup (ancillary at best, if they cover it at all ) they might devote a couple paragraphs to VDPROJ or make such over simplified statements as `.NET is XCopy Deployment`. After all the author of the book most likely hasn’t mastered MSI, doesn’t really care about Setup and is merely trying to say that his book `covers` deployment issues.
Finally there is the matter of attempting to assess your progress on the path of mastering MSI. This has been on my mind for awhile but I've hesitated to blog about it. While we are all expected to master MSI, there really is no way to officially demonstrate our comprehension. There is no MCP test or track for MSI. There is no such beast as `Microsoft Certified Setup Developer`. There is no .NET elective in the MCSD track along the lines of `Designing Applications for Deployment` or `Mastering Distributed Setup Development using Windows Installer based tools`.
The only chance we have to be officially recognized as an MSI expert is to gain the MS MSI MVP award. The MVP program really isn't geared for that in the first place. The MVP title is only supposed to show an awardees community involvement in assisting Microsoft users. Either way, Microsoft doesn't really seem to be confirming new MSI MVP's anymore. After all, you can't go around having 100 MVP's for such a small specialty as Windows Installer. Especially considering that few people outside of the setup community realize the importance of setup and MSI in the first place.
Now if you are an MVP please don't be offended by my next statement.... I don’t mean it to apply specifically to you:
Some MVP's seem to have been awarded their status for posting in a newsgroup that they have rolled their own way pattern to accomplish something that could be simply done in a tool like ISHNMET using the Click, Click, Click pattern. An example would be coming up with a way of writing some VBScript to use the Windows Installer automation interface to modify some table data because an upstream tool like VDPROJ isn’t mature enough to handle it for you.
Other potential MVP's who choose to go the ISHNMET route are ignored for MVP consideration because either they must not really understand MSI if they are using ISHNMET (tool bias at its worst). Since when should you have to redesign the wheel to prove you understand that the wheel is round? Finally some people who should be MVP candidates are ignored because their thousands of thousands of contributions are in the `wrong` place. When someone helps an ISHNMET user the thinking seems to be that they haven’t assisted a Microsoft user. Unfortunately that line of thinking assumes that ISHNMET users aren’t really Microsoft Windows Installer users. MSI Rule #1 quickly reminds us that this is simply not true.
I’m really interested in your comments on this subject because frankly, if you made it this far down the article you must really a lot about Setup.
2 comments:
Long time reader, first time poster.
I agree your "rant". But it's taken me a bit to get there.
Starting out, most people learning about installations will do so through tools like InstallShield. I know I did. But I compare the MSI output from InstallShield to the HTML output from FrontPage. It works, but if you look at what was generated, you can certainly make optimizations or just redo certain parts to make it better. But it takes experience to know how. Just like learning any other technology.
I also hear you about Rule #5 and getting Install put into the development schedule from the beginning. But it's hard to do when everyone thinks "that's a two week task to do at the end of the project". It's that "all you need is XCOPY" mentality. But if you can that buy-in from the beginning, the road to installation will be much smoother.
The WI SDK is a beast when you don't know what to look for. I don't know of a guide out there that would be good for a novice to start the process of digging in. You could start with Features and Components and Files, and then you could ramp up to CustomActions and whatnot. It might exist out there online or in print. Maybe I just missed it.
And you hit the nail on the head about certifications. After spending two years on an installation project learning tons of WI SDK and InstallShield and the differences, there was no avenue to show that I actually did anything to my managers. The project got done and it got expanded after I was gone, but there isn't something to quantify that other than a line or two in my resume (and that's not really "official" to some people).
I enjoy your blog, so keep up the good work.
[Throws two pennies on the desk]
For years I've been trying to convince some of my friends to get their feet wet with packaging.
Because of them, I've assembling a variety of docs to introduce people to packaging. My current arrangement is 6 docs culled from different sources:
1. Repackaging Basics from Wise
2. Enterprise Software Packaging Practices, Benefits and Strategic Advantages from Wise
3. Windows Installer Service Overview from MS
4. Windows Installer: Benefits and Implementation for SysAdmins from MS
5. Wise Package Studio for Newbies by Denis St. Pierre
6.Wise Pacakge Studio Getting Started by Wise
Yes, this is Wise-heavy, but some docs are old (I started building this in 98/99) and it covers a lot of the introductory concepts and some hands-on ideas.
It would be great if as a community we could put together a series of docs/books starting with an introduction to packaging concepts and lingo.
Thanks for the blog-it's good to find another resource for our community.
Post a Comment