Share via

Growing Windows Installer Experts through Troubleshooting

  • Article

Windows Installer expert Dennis Bareis responded to a previous post, Request for suggestions for updating the 1603 KB article.  As I worked through his points, the problem of "Growing Windows Installer Experts through Troubleshooting" came into focus.

Growing Windows Installer Experts through Troubleshooting
One of the challenges faced by the Windows Installer community is that there are not enough experts with the capacity to go all the way through the stack to the underlying Win32 behavior.

As with most "grow expertise" problems, there are a few high traffic areas in which one has the chance offer a novice the opportunity to build their expertise.

Once one identifies the high traffic areas, one should go to where the traffic is.

Top Three High Traffic Areas for Novices
The top three in my mind are: tools environment, troubleshooting, and design (in order of priority).

The primary instance to grow expertise is where a user of a packaging tool has reached the limit of the tools design and yet still needs to do more.  This opportunity to evolve expertise is generally lost to the Windows Installer because our various tools vendor partners each own their Integrated Development Environment (as they should ;^).

The secondary instance to grow expertise is when there are errors in the underlying experience and one needs to work backward from the low level data into the friendlier higher level constructs.

The tertiary instance to grow expertise is when novices show interest in design.

When I was little...
My goal in updating the KB would be to provide a bit more guidance to the novice that needs (or perhaps even wants) to grow in the direction of becoming an expert.

One of the challenges after reaching the expert level is trying to remember the road traveled so that one might draw a map for those who come after.

It's been so long since I was a novice, I thought it wise to ask for suggestions on how others guide folks on building their Windows Installer expertise through troubleshooting.

Thanks again for the valuable feedback.

[Author: Robert Flaming]
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at https://www.microsoft.com/info/cpyright.htm.

Comments

  • Anonymous
    January 20, 2008
    I don't believe that using a tool like ISHNMET automaticaly prevents a setup developer from gaining windows installer expertise.   I did script installs for about 6 years before I switched over to MSI and while I was making the transition to Basic MSI projects I spent a whole lot of time in the MSI SDK getting to understand how the engine actually worked. You don't have to roll your own to be an MSI expert.  You have to understand how it all works ( especially for design and troubleshooting ) but ultimatly I greatly appreciate the productivity gains provided by the higher level toolsets. Of course ultimatly no matter how well you learn MSI and your toolset, the ability to create installs really rests on the ability to understand an extremely wide variety of windows development technologies.   This is especially true in a repackaging or consulting role because you never know what you'll be asked to package up next.  Win32,COM.NET,Java,PB,Delphi,BDE,ODBC,ADO,ADO.NET,WebServices,IIS,Tomcat,Apache .... I think you get the point.  You really need to understand at atleast a 1000' level each of these technologies so you can come up with a solution. I also think that all of the books on this subject are very out dated.  One of these days I'd love to be involved on a new new book project that takes into account a lot of the lessons learned and does a good job of teaching instead of just being reference material for people who already know the subject.

  • Anonymous
    January 21, 2008
    I think saying that a tool like ISHNMET slows learning of MSI is similar to saying that Visual Studio slows the learning of C#.  You could conceviably write a very simple app in C# typing maybe, what, 30 lines of code?  The same thing applies to ISHNMET regardless of who makes it. The issue, in my mind, is that learning MSI is considered a "solo" venture.  There's no API docs like we have for Win32.  There's no site like the now-defuct gotdotnet.com.  The things that the Standard Actions do is completely obfuscated with virtually no real ability to figure it out other than trial-and-error.  And let's face it, most people aren't in to trial by fire. My opinion is not that the current answers are bad, but rather than the current question is the wrong one.  To be honest, the big thing that sold .NET is the exact thing that's missing in MSI. And yeah - having no reference books of any kind does kinda stink.  The only books out there now tell you to do things that are just outstandingly bad ideas.

  • Anonymous
    January 21, 2008
    Hello, sorry for the off-topic, but does anyone look into the beta feedback for installer 4.5 beta on connect.microsoft.com? that place seems like abandoned since November. thanks, Vadim Rapp

  • Anonymous
    January 21, 2008
    I haven't guided that many others in learning to package, but I do know from my own experience that the best method is definitely trial and error. Of course a good basic understanding of the operating system (Windows) is essential, but I even did learn a true programmer to package, who didn't know a single thing about packaging at first...well it worked out fine: e.g. he knew things about DLL's we didn't knew about and we knew things he didn't know. Just try and don't be afraid to make mistakes. Groupwork is the key to success! However, it would be definitately easier to have a nice recent book about packaging. But good things take time :-) [I am also waiting for the Citrix book about version 4.5 from Brian Madden since a long time].

  • Anonymous
    January 22, 2008
    The comment has been removed

  • Anonymous
    January 23, 2008
    After getting lost with the docs from the sdk, my starting point to learn msi was reading the reimplementation from the wine-project. Unfortante, many things are still missing there.

  • Anonymous
    January 28, 2008
    The language in the Windows Installer SDK help document is way to wordy.  I find it difficult to read the conceptual, and then visualize an actual implementation and know in advance how it behaves.  Here's an example from the Upgrade Table documentation: "ActionProperty When the FindRelatedProducts action detects a related product installed on the system, it appends the product code to the property specified in this field." "appends"?  Does that mean the property's value is now that of the product code?  Or if it finds multiple installs that match the upgrade condition, does it "append" them all together in a comma delimited list?  If it does, it should sure say it's comma delimited.  If it is literally appending, then there would be no delimiter.  Maybe they meant it "sets the value of the property to that of the product code."  Still a little wordy though.  In some technical writer's effort to sound scientific, he forgot who his audience was. That is why I am having a really hard time "growing into an expert".  The power of an example in clarifying things like the above is immense.  Just one example of what the property referrenced in the ActionProperty would look like if product codes were "appended" would have cleared it all up.  Otherwise I have to make my own example, and if I have to create a sandbox project for every piece of vague documentation in the windows Installer, then I will waste a lot of time. I spent all weekend working long nights trying to automate something as simple as doing two different installs one right after the other.  After giving up on it, the nested install feature that I struggled with turns out to be deprecated, but I didn't happen upon that little tidbit until I had already wasted enough time to have already given up on it. If it weren't for everything we have invested in the current installer and deadlines, I would have tossed it all out and used NSIS despite not knowing much about it.  One of my collegues has gone that path already, and he is satisfied with NSIS.

  • Anonymous
    January 28, 2008
    The problem with the doco is that it focuses on learning the API and not on good setup design. To borrow a quote from an ALT.NET blog: "Good design arises from the skillful application of design knowledge.  That leads to valuing knowledge like Design Patterns... For a little too long the .Net community has put too much focus on learning API and framework details (edit: MSI)and not enough emphasis on design and coding fundamentals.  ...most of what we know to be good design originated somewhere else." BTW, when is the next MSI chat?  It seems like it's been an eternity.

  • Anonymous
    January 30, 2008
    No, that's not my URL, and I don't claim any credit whatsoever for the content. But the author took an example app, a bunch of different scenarios, and explained in great detail how to make it work.  This is all done using the WiX toolset. I think they're on to something... We need more documentation in the "operating procedures" format.  It would go something like, "if you would like to install one simple file with a shortcut, then use this starting template, and replace default.txt with the file you want to distribute.  if you encounter error #897947354 then you should have extracted the icon from the executable, replaced every 7th bit with a 0, and put the resulting file into the shortcuts table." "if you would like to make a patch that supersedes all previous patches..."