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.
A lot of you probably know this already, but I wanted to list these steps for the record. If you are debugging an application issue or just want to make a quick change to your image and redeploy it without needing to open Target Designer and rebuilding your image, you can do the following:
After following these steps, you can deploy your image and any registry changes you made will take effect in your embedded OS. Hope this helps.....
While searching for orca.msi earlier today to try to determine whether or not it is available outside of the Platform SDK, I stumbled upon a really cool list of MSI tips, tricks and tools. There is one tool in there that rates the complexity of an MSI, I'm going to have to run that against the Visual Studio MSI when I have some time tomorrow, I'm really curious to know what that will come back as. I would think it has to be more complex than the Office setup package :-)
As a side note - I've gotten a couple of mails from internal folks about posting orca.msi and I'm not quite sure if it is intended to be posted outside of the Platform SDK so I may have to take it down. I can't think of a reason why we wouldn't make such a critical MSI debugging tool harder to obtain than it needs to be so hopefully I can convince the right people that we should be making it available for direct download. But we'll see.....
Stephane Rodriguez posted an interesting comment that I hadn't thought of - it isn't the easiest thing in the world to download Orca. You have to go through the Platform SDK web-based installer tool and also install a bunch of pieces of the core SDK to get orca.msi which lets you install Orca. I have a copy of it that I downloaded and posted at http://cid-27e6a35d1a492af7.skydrive.live.com/self.aspx/Blog%5E_Tools/orca.zip for easier access. I hope this makes things easier for you as you debug your setup packages.
<update date="4/9/2010"> Fixed broken link to orca.zip. </update>
While I was on the Visual Studio and .NET Framework setup team, a colleague and I took a trip to visit 2 universities - MIT and USC - to validate the plans and designs we were working on to add support to our setup UI to generate transforms for Active Directory deployment for the Whidbey version. During this trip, I was struck by the level of MSI knowledge that the system administrators at both of these schools possess, and also by how willing they were to reverse engineer setups to do any/all of the following:
The universities that we visited and many others that I've talked to who are in charge of software deployment simply need to roll out standard OS images with specific applications, and too few app developers understand the implications of their setup development decisions on things like admin deployment.
Then, when I joined the Windows Embedded team, I found a common theme among embedded customers - they need to install drivers and applications onto their embedded images, but they do not ship components that can be used by Target Designer and the embedded tools. This leaves the following options
It really struck me to think about the similarities in the problem spaces between the 2 teams that I have worked on at Microsoft. It also got me thinking because I have been working with and studying setup technologies for the 5 years I've been working at Microsoft, and over that time I've learned to think the way a setup developer thinks so that I can take apart a setup and figure out what it does. However, despite all of this experience, I still haven't seen any 2 setups that behave in exactly the same way.
I have come up with some tricks that can be useful to take apart a setup and figure out what it does, debug issues, and reassemble it in new ways. I'll list out some of the MSI-specific tips and tricks I've seen and used, and then some more general ideas:
Reverse Engineering MSI-based Setups
Random Tricks for Packaging and Reverse Engineering
It seems like I have more tricks that I've used but I can't seem to remember them all right now. I'm getting tired tonight, but I think tomorrow I'll take Visual Studio and .NET Framework setup packages and walk through some of the inner workings and show how I use some of the above tricks.
I have no idea if anyone but me is really interested in the theories and technologies behind setup creation, but if you made it this far and have comments/suggestions/questions/etc please send me an email or post a comment. Thanks!
Hey all, it looks like the Visual Studio setup team has heard all of the feedback because they have posted manual installation instructions for the Express SKUs. Here is a compilation of all of the useful links:
Manual Install Instructions
Direct Download Links
If you are on a very slow connection or have a pay-by-the-megabyte connection or something like that, you can use this link to order CDs - http://lab.msdn.microsoft.com/vs2005/get/order/. You will only be charged the cost of manufacturing the CDs and shipping them to you.
The setup team would like to ask you to please try the downloader application before linking to the packages directly because this is a beta and they are looking for all of the feedback and bug reports they can get for this new feature. Please report any issues you find while installing or using the products at the product feedback site - http://lab.msdn.microsoft.com/productfeedback
If you download the packages, you can use the instructions I posted at http://blogs.msdn.com/astebner/archive/2004/07/05/173639.aspx to create an installable layout and optionally burn it to a CD. These steps will give you the same layout of files as the CDs that you can order from the link above.
Let me know if you have any comments or questions, hope this helps....
A couple of folks who attended the session and/or the hands-on lab I presented at Embedded DevCon last week regarding remote debugging had specific questions about whether or not the strategies I presented would work on a minlogon image.
I followed the steps in Mike Hall's debugging tip sheet at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnembedded/html/embedded06072004.asp?frame=true using a minlogon image and found that native remote debugging worked fine for me on this configuration.
So I encourage those of you who are interested to try it out and send me email or post feedback here if you run into any issues or have any questions.
There is a new version of DUAScriptGen now available at http://www.winisp.net/scrat/DUAScriptGen/DUAScriptGen.zip
It contains the following fixes:
As always, please let Mike Hall and/or me know if you see any bugs or have any feature suggestions. Thanks!
Hey all, one of the feedback forms from the hands-on lab I presented about remote debugging indicated that you'd like to hear more information about how to use the Microsoft Loopback Adapter that I used to mimic a LAN connection within the local machine to connect the development OS to the virtual machine. Here are the steps I used to setup the loopback adapter. I am going to see about creating a more formal tip article for this and post it somewhere on MSDN's embedded site also. Please send me any feedback about whether or not this set of steps ends up working for you.....
Installing Microsoft Loopback Adapter
Now that you have installed the Microsoft Loopback Adapter, you need to configure an IP address for it.
Configuring Microsoft Loopback Adapter
Now you can disable your current LAN connection and enable your Microsoft Loopback Adapter connection by right-clicking on each connection in the Network Connections control panel and choosing Enable or Disable.
Earlier, I posted some random thoughts and notes that I took at the first XP Embedded Ask the Experts session at last week's DevCon (see the post at http://blogs.msdn.com/astebner/archive/2004/06/30/170582.aspx). I also want to post some stuff that I wrote down from the 2nd Ask the Experts session (last Thursday at lunch). I'm sorry it has taken me this long to post this stuff.....I'm going to be working with my team in the next couple of weeks to come up with plans to address all the great feedback and ideas we heard last week at DevCon and I'm really excited to get moving on some of this stuff....
I'll keep everyone posted on progress in these areas as we make it.....thanks again to everyone who attended DevCon and provided us with your valuable input into what we're doing well and more importantly where we're not doing so well.....
I've seen numerous issues and comments related to using the customized download manager to control downloads of the Visual Studio Express SKUs and their prerequisites and optional addins such as SQL and MSDN. Here are a couple of options that you can use to directly download the packages and then run from your local machine to install the beta bits:
If you want, you can also assemble the equivalent of a CD layout on your local hard drive. To do this, use these steps:
If anyone tries this and hits any problems please email me or drop me a comment and I'll help wherever I can. Thanks!
<update date="11/16/2005"> Updated the URL to be http://go.microsoft.com instead of http://www.microsoft.com </update>
My former group (Visual Studio and .NET Framework) has signed off on the beta1 bits for the new 8.0/2.0 versions, codenamed Whidbey. One of the last big setup projects I worked on was the download logic for the Express SKUs - these are replacements for the “standard” versions of Visual Basic, C#, J#, C++, along with an additional SKU named Visual Web Developer (think of VID 6.0 with all the cool stuff that goes with ASP.NET and without all of the annoyances of VID).
The coolest thing of all is that you can use the downloader to get yourself a free copy of any of the 5 beta express SKUs and you don't even officially have to be a part of the Visual Studio beta program. Just go to the site at http://lab.msdn.microsoft.com/express/ and choose the version(s) you want, and off you go.
I'd be really curious to hear what you think about the experience of downloading and installing Visual Studio directly from the web, so if you try it, drop me a comment. If you're not a part of the Whidbey beta program and you have any bugs to report and/or suggestions for ways to make the experience better I will fill out a bug report for you so your voice will be heard by the Visual Studio team.....
It took me way too long to do this, but I've now got a link to Jon Fincher's blog on my site. He is a Program Manager that works on XP Embedded along with myself and others, he's been in the group for a very long time and has a ton of experience, tips and tricks to offer. Plus he's got a very good sense of humor so his posts are more fun to read than mine are!
He gave some really cool demos and presentations at Embedded DevCon about the new features that will be coming up when XP Embedded SP2 is released later this year. I encourage all of you to take a look at his blog when you have a chance.....
The second part of Mike Hall's “Going Virtual” article about using Virtual PC to setup an XP Embedded image and perform remote debugging using Visual Studio .NET 2003 has been posted on the Get Embedded site, take a look by clicking here.
For those of you who attended Embedded DevCon this past week in San Diego, some of this will look familiar - I helped Mike figure out some of the Visual Studio debugging details, especially the nuances needed to get things working on XP SP2 with the new firewall features, and I presented some of these techniques in my remote debugging talk on Thursday the 1st.
I'm going to work with Mike to publish a similar article describing how to configure machines for managed remote debugging using the techniques described in my debugging talk. The steps required for that are more involved but can prove to be very useful when readying your apps for an embedded device. So stay tuned for that.....
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:
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.
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.....
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.
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:
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:
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!
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!
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....