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 colleague Alaks Sevugan created a pretty comprehensive list of file and registry exclusions that can be used with the InCtrl5 tool to eliminate noise when trying to convert an application installer to an XP Embedded component. Click on the link below to download it and try it out....
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.....