Aaron Stebner's WebLog

Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio

May, 2004

  • Aaron Stebner's WebLog

    MSI tools


    There are quite a few good tools and resources for MSI setup creation and debugging in the Platform SDK.  I figured I'd list the ones I use most often, and I would really like to know what everyone else uses and if there are any holes in that you've found where new tools are needed.....

    Descriptions for all of the tools in the PSDK can all be found at http://msdn.microsoft.com/library/en-us/msi/setup/windows_installer_development_tools.asp by the way....

    Stuff I used every day when I worked on the VS and .NET Framework setup team:

    • MSI.chm - the help file for Windows Installer, this is indispensible for looking up error codes, command line parameter permutations, descriptions of fields in the various tables, bitmask descriptions for things like file and component attributes, etc.  There is one thing that drives me crazy though - trying to figure out the meaning of the different custom action attributes to determine exactly what you should expect for any given CA
    • Orca - graphical viewer for the contents of an MSI, I have this installed on all of my machines, even on my new team.  It can be scary to open up and look at random setups though - I've seen all sorts of horror stories over the past few years - both within MS and elsewhere.

    Stuff I found very useful though I didn't need to use them daily:

    • MSIZap - removes the remnants of a failed install/uninstall from your machine.  I strongly recommend using this only as a last resort - most of the times I use this it is because someone installed a daily build or an early beta of one of our products that had some kind of uninstall bug.
    • MSIVal2 - performs internal consistency validation for MSI tables, this can be useful for catching MSI authoring errors that may not always manifest themselves in the form of a failure and roll-back of your setup. 
    • MSITran - lets you easily take the delta between 2 MSI packages and create a transform containing the differences.  What I've used this for in the past is to modify some of the UI and add/remove launch conditions as a one-off for customers who weren't familiar with the internal workings of an MSI in Orca.

    There is a log analyzer tool on the site (wilogutl) that can help narrow down failures in your setup - it can be especially useful for verbose logs for large products such as Visual Studio (those logs are 40+ megs....)  I usually take shortcuts before I use that tool though, most of the errors can be found by searching for “return value 3“ in your MSI verbose log file.  This doesn't work for non-English products because that string is translated, and it also relies on the setup author to log useful information for things like custom actions that may end up failing.

    The other tools on the PSDK site sound like they'd be very useful as well but I don't have first-hand experience with them.

    What other stuff is out there that folks are using?  What stuff is missing that needs to be written in this space?  Thoughts?


  • Aaron Stebner's WebLog

    Excellent MSI component tutorial


    Hey all, I found a really nice write-up of MSI component rules in a blog from another MS employee (Rob Mensching) that I wanted to add a specific link to.  I've seen the setup team I worked on burned by a lack of understanding of these types of rules many times, it is highly recommended reading for anyone writing an MSI-based setup, especially one that shares anything with any other setup package....


  • Aaron Stebner's WebLog

    Device Update Agent Script Generator (DUAScriptGen) v1.0 beta - try it now!


    When I joined the Windows Embedded team a few months ago, I set out to learn about my team's features, and one of the first things I started working with was Device Update Agent (DUA).  I found the documentation very helpful, but felt a lot of pain trying to use Notepad as an IDE to create DUS scripts and get them to compile.  I started thinking about some way to create a tool to hide the details of the script syntax from the user to make it easy to create and compile update scripts.  Then I started talking to folks and found out that Mike Hall had already coded up a demo app that did exactly that.  So for the past few weeks I've been working with him to finish implementing functionality, fix bugs, add a few features, and of course test it out.

    We've finally got something that we're ready to unveil to everyone.  Click on the image below to download the DUAScriptGen.exe tool and try it today!  You will need to have the .NET Framework 1.1 installed on your machine for it to work correctly since we wrote the tool in C#.

    Here is a list of the cool things that the tool can do:

    1. Import the information in an XP Embedded QFE .RTF file to auto-generate script file - you can download the .RTF files on the same page as each of the QFE's for XP Embedded (http://msdn.microsoft.com/embedded/downloads/xp/default.aspx)
    2. Drag/Drop files onto the application (or use the import button) to add additional files to the script
    3. Location setting for files - set individual files to specific folders on the target device (folders will be created if they don't exist)
    4. Drag/Drop .REG files  (or use the import button) to add groups of registry keys to the script
    5. Add specific .REG keys through DUAScriptGen UI
    6. Specify commands to execute as part of a script
    7. Specify the polling location, local DUA directory, and the name of the next script to poll for when an update completes
    8. Optionally reboot at the end of an update
    9. Reload scripts previously created by DUAScriptGen and modify them and recompile

    Mike and I are really excited about this tool, and we hope that it will help folks more easily use DUA in their XP Embedded images.  We would love to hear your feedback - bug reports, additional feature suggestions, usability improvements.  Please post comments on either of our blogs....


    Download DUAScriptGen Now!

  • Aaron Stebner's WebLog

    Here goes nothing.....


    Well, here I am with my first blog entry.  First, a little bit about myself.....I've been working at Microsoft for almost 5 years.  The first 4 and a half years were spent on the Visual Studio and .NET Framework setup team.  During that time, I've gained a lot of random knowledge about Windows Installer, OCM-based setups that form the basis of OS installation, hACkME setup, etc, etc.  I also gained an understanding of how the setup developer thinks, including how to work around limitations in existing installers and how to get bits on a machine by any means necessary.  Above all though, I develped an understanding and empathy for the pain that Microsoft customers face as they try to implement setup and deployment solutions for our products in their corporate, education, individual, and redistributable environments.

    While on the setup team, I helped ship Visual Studio 2002 and 2003 and the .NET Framework 1.0 and 1.1.  My proudest accomplishment was my leadership role in porting the .NET Framework setup from MSI to INF for inclusion as part of Windows Server 2003.

    Along with this knowledge, I've also accumulated a wide range of pet peeves and best/worst practices related to setup creation and functionality.  If I'm able to use this forum to influence even one person to create a simpler setup that strives to get bits on the machine in as painless a means as possible and to consider it to be a success if the user doesn't notice anything about the setup itself, then I'll consider my blog efforts successful.

    After I moved on from the developer tools setup team, I joined the Windows embedded team to work on Windows XP Embedded and Longhorn Embedded - specifically on embedded enabling features (AKA EEFs).  Fortunately, I worked on the embedded components for the .NET Framework 1.0 and 1.1 when I worked on the setup team, so I didn't join the embedded team completely blind.  After 2 months on the embedded team, I attended the ESC West conference in San Francisco.  It was absolutely enlightening to get a chance to meet real world customers and see how you're using our tools to create products and solutions that are being deployed world-wide.

    I don't know what direction these blog entries are going to take, and I have my doubts that anyone would even care about reading what I have to say.  I do know I'll be back to give some random thoughts about embedded Windows, setup features and functionality, and deploying the .NET Framework (1.0 and 1.1) as part of managed application setup packages.  In the meantime, here are some links that I regularly send out to Microsoft employees and our customers to help them with setup, deployment and embedded solution development:

    Until next time......


  • Aaron Stebner's WebLog

    My first Windows XP Embedded post - DUA feedback?

    OK, I know I've focused my posts thusfar on setup experiences and technologies, but I've been working on a project on my new team - Windows Embedded - and I am hoping to solicit some feedback here.  Are there folks out there using Device Update Agent (DUA) to maintain their Windows XP Embedded images?  I have run across some oddities and difficulties as I ramp up on the technology and I'm curious what experiences everyone else is having.  If you have any comments, suggestions, complaints, feedback of any kind please let me know.  I'd like to pool all of the feedback I get and all of the things I can find on newsgroups, etc and figure out what we can improve on specifically in the area of servicing and adding new components to existing embedded images.  Thanks in advance!
  • Aaron Stebner's WebLog

    Cool article about using Virtual PC for testing XP Embedded images


    I'm sure many of you may have already found this, but I wanted to link to an interesting article that Mike Hall wrote last month about using Microsoft Virtual PC to test XP Embedded images - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnembedded/html/embedded04232004.asp

    The cool thing about this idea is that if you only have a single machine and you want to be able to remote debug from your development machine or your machine doesn't happen to be partititioned for dual-booting, you still can.

    I'm going to be delivering a hands-on-lab about application development for XP Embedded at Embedded Devcon 2004 (http://www.windowsembeddeddevcon.com/) and I'm planning to discuss some of these Virtual PC techniques for this lab.

  • Aaron Stebner's WebLog

    New embedded evaluation kit now available!


    Hey all, if you are new to Windows CE and/or Windows XP Embedded and want to see what it is all about, there is a new evaluation kit available.  It contains evaluation copies of Windows XP Embedded, Windows CE 5.0, a bunch of cool resources and a coupon for $400 off admission to Windows Embedded DevCon 2004 at the end of June in San Diego.

    Click the link below for more information...

    Download the Windows Embedded Evaluation Kit Now!

  • Aaron Stebner's WebLog

    DUAScriptGen v1.0002 is now available


    Hey all, there is an updated version of DUAScriptGen now available at http://www.winisp.net/scrat/DUAScriptGen/DUAScriptGen.zip.  It contains a bug fix for the REGSETVALUE command (it was incorrectly writing blank size values for registry data types that did not need size values at all), some UI polish and clean-up work, and a new document describing how to use the tool.  As always, feedback and suggestions (positive and negative) are greatly appreciated!

  • Aaron Stebner's WebLog

    MS setups - inconsistent?


    I received this question in response to my introductory blog entry - "Why are MS Installer all so different, why do many of them have problems with unattended installation - and why do they sometimes need a user logged on?"

    These are all really good questions and ones that I have asked myself many times since I've been working at Microsoft.  The fact that setups produced within Microsoft are so inconsistent is one of my pet peeves. It seems like there isn't an established standard for how to create a good or well-behaved MSI setup, even within Microsoft. For example, a lot of the stuff we learned on the setup team I worked on came from feedback for our released products. Visual Studio 2002 was the first version of VS to use MSI, and we missed some key scenarios - specifically related to Active Directory and other types of unattended deployment.

    So, to answer these questions based on my experiences so far - I believe it is because so many teams are creating their own setups from scratch that leads to some differences in look-and-feel and functionality. Unattended installation is too often left until the end in product design and testing and not enough focus is put on deployment scenarios. This is not true across the board, some of our products do a really good job addressing these scenarios I think, but many do not.

    Requiring a logged on user is very dependent on what the setup itself is trying to do to configure the product it is installing. There are cases where some level of elevated privileges are needed, but there are also cases where it is enforced by a setup but not truly needed and it just happened to be easier to author the setup that way.

    Hope this helps....and thank you for the question and interest.

  • Aaron Stebner's WebLog

    Striving for increased consistency in MS setups


    This is in response to a couple of comments in my earlier post about inconsistencies in MS setups.  First - is Microsoft going to address issues of inconsistency.  This is a problem that has been rattling around my mind for a while and I'm finally starting to get some of my ideas in writing.  I've still got some research that I need to do to find out what other similar efforts exist elsewhere in the company (if any).  Depending on what I find, I'm going to jump into some kind of virtual team to get this effort moving or try to start my own bandwagon and try to find others to jump on with me.  I'm not sure where it will lead at this point but I'm finding myself energized to at least explore and see where it leads me.

    Traditionally, I've seen setup treated as an afterthought (example quote - “all it does is copy files and set registry keys, what is so hard about that?“)  I've come to recognize that it is not just about getting the bits on the machine, it is the first chance you have to make an impression on your customer - if setup does its job, it will not even be noticed, but if something goes wrong the entire relationship with that customer is changed.

    It is also not just about the end-user, you have to also recognize and make it as easy as possible for the administrator to roll out your product to labs, corporate campuses, etc.  This is a big area where best practices that are shared across MS and the industry can provide a big bang for the buck I think.  This also ties into the 2nd comment to my previous post - what is MS doing to make it easier to tie setups together?  This is something I've seen us struggle with internally - some MS teams want to be able to execute SQL scripts like the comment mentions or they want to chain together several MSI-based setups into one seamless experience.  There is  more and more recognition - particularly from teams that build setups that are intended to be redistributable and chained with other setups - that this problem needs to be solved.  What I haven't seen yet is a lot of momentum to push out the tools and fixes needed to do this - I'm hoping I just haven't found these efforts yet and the research I'm embarking on (mentioned above) will lead me to them.  We'll see though....stay tuned.....


Page 1 of 1 (10 items)