Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS
with no warranties, and confer no rights. Additionally, views expressed
herein are my own and not those of my employer, Microsoft.
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.....
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...
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!
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.
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:
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....
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....
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.....
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:
Stuff I found very useful though I didn't need to use them daily:
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?
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.
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......