Aaron Stebner's WebLog

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

  • Aaron Stebner's WebLog

    Random thoughts from DevCon

    • 1 Comments

    Well, I've been here in San Diego since Monday and attended the first 2 days of the Embedded DevCon 2004 show.  I sometimes forget how tiring it can be just to be on your feet all day since I'm used to spending most of my work day sitting in front of a computer.  But it has been amazing to get a chance to meet so many customers and talk about the wide variety of directions people are going with the embedded tools and different development and deployment strategies.

    So far, I haven't presented (since I got “lucky” enough to have both of my talks on the last day of the show), so instead I have been acting as a proctor for the hands-on labs other folks in my group have been presenting.  I also went to a lunchtime Q&A session called “ask the experts” today, though I don't know that I can really consider myself anywhere near an expert given my relatively short time on the embedded team and the wide range of issues that our customers see every day.  Overall though, this was a great chance for me to see some of the specific pain points and give me some ideas to take back to Redmond when I head back on Friday.

    Here is a list of the things I took notes on during the Wednesday “ask the experts” session that I specifically want to research and come up with plans for addressing:

    1. SOURCE CONTROL (typed in all caps for big emphasis) - Microsoft has not done a good job of recognizing the importance of being able to maintain solid version control for component SLD files and image SLX files.  We need to figure out a set of best practices and create a white paper and possibly supporting tools to make the pain of source control for XP embedded much less in the future
    2. We should consider creating some kind of living FAQ document that contains top issues and solutions and is auto-posted to the newsgroups.  There have been several cases where answers to common problems get buried in the newsgroup, never to be heard from again
    3. We need an FAQ or guide for troubleshooting odd event log entries that are generated when booting an embedded device.  Lots of times these are caused by missing dependencies but how can they be tracked down?

    This afternoon I went to my colleague Nandini's talk about First Boot Agent (FBA).  I thought she did a great job of presenting her material and fielding the questions at the end of the session, I only hope that my talks tomorrow go half as well as hers.  What struck me about the questions was the amount of interest in resealing and cloning.  These are aspects of XP Embedded that I haven't explored very much yet in my time on the team and I'm going to make a point to get a greater understanding of how these work and where the problems are in our current cloning support.

    Wow, I've let the time get away from me while typing out this stuff and I still need to practice my presentations one more time before I fall asleep so I'm going to sign off for now.

  • Aaron Stebner's WebLog

    DevCon here we come!

    • 0 Comments

    Hey all, I have been working to finish up the presentations, demo applications and lab machines for the presentations that I'll be giving at Embedded DevCon next week.  Both of my presentations are on Thursday the 1st, so I'll be spending time meeting folks, answering questions and seeking better understanding of what we're currently doing well and where we can improve in the end-to-end Windows XP Embedded user experience.

    Currently it appears you can only access the full contents of my presentation if you are officially registered for the conference.  You can see the abstracts by going to http://www.windowsembeddeddevcon.com/tech_sessions.asp and http://www.windowsembeddeddevcon.com/tech_hands_on.asp and navigating to the “Track: Application Development” sections.  I'll be presenting XPEA Hands-on Lab 1 (application development for XP Embedded) and XPEA-300 (remote debugging on XP Embedded).  I'm really excited to share some of the tips and tricks I've learned during my time on the Visual Studio and .NET Framework team and combine that knowledge with resources specific to XP Embedded to enable easier and faster application development on this platform.

    I hope to see you all at the conference!

    I will be posting more later this week about some ideas around application repackaging, so stay tuned for that if you're looking here for setup technology discussions.  The really interesting thing is that I've found that application repackaging is something that affects the embedded problem space just like it does for the desktop OS problem space, just with some different implications.  In the next couple of days when I'm less tired I'll type up more and see where my thought processes go..... 

  • Aaron Stebner's WebLog

    A couple more Windows Installer links I found

    • 0 Comments

    Hey all, I'm sure most of you have already seen these but just in case, here are a couple more links that I found related to Windows Installer on various Microsoft websites:

    I also borrowed a copy of a book called Administrator's Introduction to Application Repackaging and Software Deployment using Windows Installer from a guy on my former team here at Microsoft (the link is not necessarily an endorsement of Amazon.com, just what I usually use to send info about books electronically).  I'm planning on taking a look at this book over the weekend.  If anyone has gone through any of this book already, I'd like to hear what you think.

    I'm also thinking of a couple topics for future blog entries as I get time to type them out - thoughts on application repackaging in general, and features that should exist in Windows Installer but don't.

     

  • Aaron Stebner's WebLog

    Custom actions that should be standard actions

    • 18 Comments

    I recently met a Program Manager who joined Microsoft late last year after working at InstallShield for a while.  We got to talking about some of the difficulties involved in creating an MSI-based setup and the lack of solid, documented best practices and even things that would make it easier to build and test setups such as more comprehensive ICE validation test suites.

    One of the interesting discussions we had was to compare lists of actions that are commonly needed in a setup that are not available as MSI standard actions and have to be implemented as custom actions.  Here is his list:

    1. Install kernel mode drivers
    2. Add/remove a line from a text file that is not in INI file format (such as a .NET Framework .config file)
    3. Create user accounts
    4. Change ACLs (since the LockPermissions table does not honor existing ACL’s)
    5. Create a virtual directories in IIS
    6. Create web sites in IIS
    7. Create SQL server databases
    8. List SQL server databases
    9. Create SQL server user accounts
    10. Validate PIDKEY values
    11. To display billboards
    12. An MSI package cannot use mapped drives when an administrator installs an MSI package through a remote session to a terminal server (http://support.installshield.com/kb/view.asp?articleid=q108613)
    13. Post data to an HTTP server to post information to a organization's web server to record user registration information or other data
    14. Set ALLUSERSPROFILE and USERPROFILE variables in different operating systems
    15. Install a Plug and Play device driver (http://www.installshield.com/news/newsletter/0312-articles/plug.asp?ISCS12NL=16702602)
    16. User profile creation when a new user logs in

    In addition, he made the good point that for every custom action, a setup author has to essentially create 3 custom actions (install, rollback, uninstall) and potentially a 4th (uninstall rollback).

    Of the things on this list it was interesting to see that in my experience on the Visual Studio and .NET Framework setup team, we ended up writing custom actions or equivalent code to do items 1, 2, 3, 4, 5, 6, 10, 11, 13 and 16.  Also, the team is working on new custom actions for the SQL items (7, 8, 9).

    In addition to the above, I would add the following to the list based on my experience:

    1. Marking folders as hidden (and not just files)
    2. Create user groups
    3. NGEN (pre-JIT) .NET Framework assemblies
    4. Perfomance counter registration
    5. MOF compilation

    I'm curious if there are other common custom actions that folks are using that would be useful to have available as standard actions.

    For .NET Framework setup developers, I would also like to know if anyone is attempting to implement NGEN functionality within your setup, and if so if you have any feedback about your experiences doing so.

    Thanks in advance!

  • Aaron Stebner's WebLog

    Blog I found with useful InfoPath information

    • 0 Comments

    I've been experimenting with using InfoPath recently - it is a new tool that is part of the Microsoft Office family of products and I've found it to be really useful to create form templates for things that I need to write a lot (like weekly status reports, meeting notes, test plans, etc).  I found a blog that has a bunch of useful tips and tricks for using InfoPath that I wanted to pass along for anyone who is interested - http://radio.weblogs.com/0131777/categories/infopathTipsAndTricks/

    Have a great weekend everybody!

  • Aaron Stebner's WebLog

    Cool new Visual Studio product in the works

    • 3 Comments

    Hey all,

    My former group (Visual Studio and the .NET Framework) is working on a new version - Visual Studio 2005, codenamed Whidbey.  One of the new products that will be part of Whidbey is a set of tools for creating, running and tracking results for tests.  As a tester, it is pretty exciting to see Microsoft start working on some enterprise-level tools specifically for testing.  Take a look at the link at http://msdn.microsoft.com/vstudio/teamsystem/tester/default.aspx for some additional “sneak peek” information.....

     

  • Aaron Stebner's WebLog

    New embedded evaluation kit now available!

    • 2 Comments

    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

    • 2 Comments

    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

    Cool article about using Virtual PC for testing XP Embedded images

    • 1 Comments

    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

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

    • 6 Comments

    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

    My first Windows XP Embedded post - DUA feedback?

    • 3 Comments
    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

    Excellent MSI component tutorial

    • 0 Comments

    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....

    http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx

  • Aaron Stebner's WebLog

    Striving for increased consistency in MS setups

    • 1 Comments

    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.....

     

  • Aaron Stebner's WebLog

    MSI tools

    • 19 Comments

    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

    MS setups - inconsistent?

    • 3 Comments

    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

    Here goes nothing.....

    • 7 Comments

    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

Page 48 of 48 (1,191 items) «4445464748