Aaron Stebner's WebLog

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

  • Aaron Stebner's WebLog

    XP Embedded is powering unmanned aircraft

    • 0 Comments

    I found this really cool article this morning about a project at Cornell University where they're building an unmanned aircraft with onboard embedded control systems that are running XP Embedded - check it out at http://research.microsoft.com/displayArticle.aspx?id=685

     

  • Aaron Stebner's WebLog

    Cultural issues to consider when writing worldwide applications

    • 2 Comments

    My colleague, former manager and friend Michele Coady is currently an international test lead on the Visual Studio and .NET Framework localization team.  She sent me a really interesting link today that I wanted to pass on for anyone who may be writing world-ready applications.  Colors have different meanings and cultural implications depending on the audience, and it is very important to keep the connotations in mind when writing applications for worldwide audiences.  Anyone writing worldwide applications should take a look at this article, and even if you're not, this is an interesting read - http://www.colorconnection.xerox.com/wwwco578/html/en/tips/international.html

     

  • Aaron Stebner's WebLog

    Weird rollback behavior I saw in Windows Installer yesterday

    • 1 Comments

    I saw a very odd rollback behavior in the .NET Framework setup yesterday that I thought I should post in case anyone else runs into something similar.  This was the 2nd time I saw it, but the first time in a scenario from a non-Microsoft internal machine.  When it first happened I had written it off as a one-off caused by daily builds of the OS, the .NET Framework or something like that.  But apparently it is possible to get the machine into this state through released products (possibly beta bits, but still valid in my opinion)

    Essentially what happened was the .NET Framework setup proceeded all of the way through installation and then initiated a full rollback.  I couldn't find any evidence in the verbose MSI log file that any kind of error had triggered the rollback, and the last section of the log told me that the return code was 0 and that the .NET Framework installation completed successfully.  I had to use filemon and regmon (from http://www.sysinternals.com) to diagnose that there was a file in the folder c:\config.msi named *.rbs that was being executed, and then finally I traced it back to the following registry value on the machine:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts

    I wasn't able to determine how that value got set, and searching for information about this registry hive in msi.chm and on the internet didn't yield any conclusive information.  The closest I came to a possible explanation is in the section named Active (Incomplete) Installations at http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/Default.asp?url=/resources/documentation/windowsServ/2003/all/techref/en-us/msizap_remarks.asp

    What I think may have happened is some other Windows Installer setup (more than likely the .NET Framework itself) got orphaned before it completed, and then this script was left behind in the registry and inadvertantly got launched by future installations.  Normally when a Windows Installer setup gets orphaned and you try to run another MSI, it will say that an installation is currently in progress and is suspended and asks if you want to rollback before you continue with the new setup, but for whatever reason we didn't see that in these 2 instances.  I'm still hoping to get a more thorough explanation from the Windows Installer team about what is really going on here, and I'll post my findings back here.....

  • Aaron Stebner's WebLog

    New embedded blog available from Neil Marlowe

    • 0 Comments

    Hey, I'm slowly but surely getting other folks on my team to create blogs.  Neil Marlowe is a program manager who I work closely with - some of you may have met him and attended one of his talks at Embedded DevCon.  His primary focus is the Embedded Enabling Features (EEFs) like me, plus he's got some expertise on embedded security and servicing scenarios.  Take a look at his blog at http://blogs.msdn.com/neilmarlowe/ if you have a chance, he's planning to post some good how-to documentation in the near future about using the ICF utility to protect embedded devices....

     

  • Aaron Stebner's WebLog

    Reverse engineering a setup - lesson 1 - .NET Framework 1.1

    • 10 Comments

    Hey all, as I promised a while back, I wanted to walk through some examples of how I approach reverse engineering a setup package to learn how it works, make any necessary changes, figure out command line switches, etc.  I apologize for not posting anything in a while, I was spending some time with my family who was in town from Texas and then I managed to get sick right after they left.  But I'm back now  :-)

    I'm going to start with a relatively straight-forward reverse engineering example - the .NET Framework 1.1 package.  I chose this first because that setup is very simple - no setup data files, no configurable setup UI options, etc.  Yet it is complicated enough to be interesting and it is a setup that a lot of people want to include in their setup packages and/or have had issues trying to install.  I'm going to try to approach this from the perspective of someone who is familiar with different types of setup technologies in a broad sense, but who has not yet seen this particular setup before (I may get a little off track on this part because I'm so familiar with this setup from my previous work, but I'll try.....)


    Step 1 - figure out what packaging technology is being used

    When I download the .NET Framework 1.1 I see that it is a single EXE named dotnetfx.exe.  When I double-click on it, setup asks me if I want to install and when I say Yes it proceeds to extract files to the %temp% folder on my machine.  Then a EULA appears.  When I go to %temp% after the EULA appears, I see a folder named ixp000.tmp.  This tells me that the package in question is an IExpress self-extracting EXE.  Since I know it is IExpress, I can now use some well-known IExpress command lines to extract the package to a folder of my choosing.  I will run dotnetfx.exe /t:c:\aaron /c to create a folder named c:\aaron on my machine and unpack the .NET Framework files to this folder.  The /t flag specifies the folder to extract to, and the /c flag specifies that I want to extract the files only and not run the setup after extraction.

    Side note for setup developers - I found some IExpress docs on the web here, and you can also find iexpress.exe in %windir%\system32 on an XP Professional machine.  It is a useful tool for packaging up multiple files into a single package but it is also a fairly old technology and has some limitations that may not make it practical to use, depending on your scenario.

    Step 2 - figure out what setup/installation technology is being used

    Now that I have extracted the files, I will go to the c:\aaron folder that I created above.

    • The first thing I see in the folder is a file named netfx.msi - this tells me that the setup is a Windows Installer-based setup.
    • I see a file named netfx1.cab, and opening it in a file extraction utility such as WinZip, or in Windows Explorer on Windows XP or higher shows me that there are 204 files with long funny looking names inside.  My knowledge of Windows Installer tells me that these are the files that will be installed by netfx.msi because I know that if you install files from a CAB file using Windows Installer, you are required to name files in the cab using the File token from the File table of the MSI - hence the funny names.
    • There are 2 self-extracting EXE files named instmsi.exe and instmsiw.exe, and I recognize those as the setup packages for Windows Installer itself.  This means to me that this setup will install the required version of Windows Installer for the user if it is not already present on the machine.
    • Finally, I see a file named install.exe.  Initially I am not sure what this is for, but I guess that it is a bootstrapper EXE that will launch netfx.msi and will also launch instmsi.exe or instmsiw.exe if it is needed.  Out of curiousity, I run install.exe /? and observe the usage information that appears and it does indeed appear to be a .NET Framework setup bootstrapper.

    Step 3 - figure out the basics of how the setup works

    Most of the information I need to figure out how the setup works will be gained by installing Orca and then looking at the MSI, but first I want to look at a basic overview of what the setup is doing.  I will start by double-clicking install.exe - when I do so, the .NET Framework setup starts and the EULA appears.  Now I will take a look in the %temp% directory and see if the setup happens to be creating a log file since most setups will create some kind of log for debugging and troubleshooting.  I can sort the %temp% directory by Date Modified, and I see a log named dotnetfx.log there.  Opening this up and reading it gives me some ideas of what the install.exe process is doing - it is checking several system requirements such as OS type, OS service pack, Internet Explorer version, MDAC version.  It is also loading msi.dll to determine the version of Windows Installer on my system - this must be how it decides whether or not to run instmsi.exe/instmsiw.exe.  There is also a call to a function called StopDarwinService.  I'm not sure why this is here, but I know that Darwin is a code word for Windows Installer, and I know that on Windows NT-based OS's Windows Installer is actually a service instead of just an application, so I am guessing that install.exe is trying to stop the Windows Installer service before starting installation of the .NET Framework.

    After I look at all of this, I go ahead and step through the UI and install the .NET Framework 1.1, and then re-open the log file dotnetfx.log.  I see that it lists the command line that is passed to the MSIInstallProduct function - and I know that this is an API call for an application to install a product using Windows Installer.  Then I see a return code for that API call - fortunately it is 0 in this case to tell me that the .NET Framework 1.1 installed correctly.  Then I see another call to StopDarwinService, so this install.exe application is stopping the Windows Installer service again after installation is complete - kind of strange.

    Step 4 - figure out details about how the setup works

    Now that I have a basic understanding of how the .NET Framework 1.1 setup works, I'm going to use my Windows Installer expertise to dig a little deeper.  The first thing I will do is install Orca, then right-click on netfx.msi and choose Edit with Orca to view the contents of the MSI.  There is a ton of data to wade through in an MSI and it is overwhelming at first, so I will only look at a few key things here:

    • Go to the property table and look at the product code, upgrade code, and any other interesting properties that are set.  Most of the properties in this table will be standard data documented in msi.chm, but sometimes there may be interesting custom properties set here.
    • Go to the Tools menu and see if the Dialog Preview item is enabled.  If it is, that means that this setup package uses UI that is contained in the MSI itself.  For the .NET Framework 1.1, it is enabled and we can look at all of the possible UI screens.  If you look closely at the Dialog Preview and cross reference it with data in the UI tables of the MSI (the Control, ControlEvent, and Dialog tables among others), you can find a bug in this setup.  The ActionDialog is shown during installation, and it has a Control_Default set to cancel which means that if you press Enter with this dialog on-screen it will trigger the cancel action.  However, an MSI-based setup should not allow you to cancel if it reaches the commit phase of setup (which is normally distinguished by the cancel button being greyed out or disappearing from the setup UI progress screen).  However, for the .NET Framework 1.1, you can press Enter even when the cancel button is gone and it will trigger the cancel action.
    • Go to the InstallUISequence table and observe the conditions and order of actions when running the setup with full setup UI
    • Go to the AdminUISequence table and observe the conditions and order of actions when running the setup in administrator mode.  This is often the source of some bugs if someone forgets to author an action or condition on the AdminUISequence table but it exists in the InstallUISequence - this will cause behavior differences for setup depending on whether or not it is run in admin mode.
    • Go to the InstallExecuteSequence table and observe the conditions and order of actions when setup is actually installing/uninstalling
    • Go to the LaunchCondition table and see if there are any actions that will block setup from installing.  In the case of the .NET Framework 1.1, it will block installation if the OS being installed to is 64-bit.
    • Go to the Component table and observe the attributes and conditions for components to be installed.  In the case of the .NET Framework 1.1 - some files will not install on certain OS types (for example, ASP.NET is not supported on OS's before Windows 2000).  Also, all files have at least an attribute of 8 meaning that Windows Installer will respect and increment/decrement the legacy shared DLL refcounting scheme for these files.  In addition, files that have OS conditions have the attribute of 64 (= transitive), which means that Windows Installer will re-evaluate component conditions when a repair is attempted.  This is nearly always needed for files with OS conditions because we want to have the files added or removed as appropriate when performing a repair after an OS upgrade or downgrade.  For example - if you install the .NET Framework 1.1 on Windows 98/ME then upgrade to Windows XP and then perform a repair, we want the ASP.NET files to be installed for the user.

    There are many more things that we could look at in an MSI, but the above are good starting points.  Often for other setups you will see items in tables that will lead you on trails through other tables.  Most commonly, if there are launch conditions that depend on the existence of other applications, you will be led to the AppSearch table to figure out exactly what file or registry data the setup is looking for when deciding whether or not to block.

    Step 5 - install with verbose logging and look at the MSI log file

    Reading an MSI log file is more of an art than a science but can often be useful when reverse engineering a setup.  For the .NET Framework 1.1, we know that because it is an MSI we can set the verbose logging flags before running setup - HKLM\Software\Policies\Microsoft\Windows\Installer, Debug (REG_DWORD = 7) and Logging (REG_SZ = voicewarmup!).  These will give us a verbose log named msi*.log in %temp% where * is a randomly generated set of characters.

    I also noticed when running install.exe /? it says that if you pass a /l flag it will generate netfx.log in %temp%.  Since I also noticed that the log created by running install.exe was named dotnetfx.log and not netfx.log, I might be curious what the difference is and run install.exe /l from c:\aaron to see what it does.  When I install this way I see that the resulting file %temp%\netfx.log is essentially the equivalent of a Windows Installer verbose log file without needing those registry keys to be set.  So now I can take a look at netfx.log (or msi*.log if I choose) and view the step-by-step process of this setup.


    With that, the process of reverse engineering the .NET Framework 1.1 setup is done for the common cases.  There is of course more detail that may be needed depending on your scenarios, but much of that will require more in-depth analysis of the MSI tables and/or the verbose MSI log files.  I will leave that for a later lesson.

    Side note for the curious - the reason that the .NET Framework 1.1 setup stops the Windows Installer service is because Windows Installer uses pieces of the .NET Framework to install assemblies to the GAC (the MSIAssembly and MSIAssemblyName tables in the MSI) in Windows Installer 2.0 and higher.  This creates a classic chicken-n-egg problem - Windows Installer is going to install the .NET Framework but Windows Installer needs the .NET Framework in order to do so.  Because of that, Windows Installer has some special logic to bootstrap the part of the .NET Framework it needs to install assemblies, but since Windows Installer is run as a service, it could already be running from a previous setup and we want to stop the service to unload any older versions of the .NET Framework from memory so that the most recent version will be used.

    I hope this post is at least a little bit useful to give some insight into how I approach the process of taking apart a setup and figuring out how it works.  I will post more later with a more complicated example of a setup that uses information from data files, etc.  Let me know via comments or emails if you have any questions about any of the above.....

  • Aaron Stebner's WebLog

    Exclusion list to use with InCtrl5 for creating embedded components for applications

    • 7 Comments

    Hey all,

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

    http://www.winisp.net/astebner/bin/inctrl5_exclusion.txt

     

  • Aaron Stebner's WebLog

    Updating the registry in pre-FBA images without rebuilding

    • 2 Comments

    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:

    1. Run regedit.exe on your development machine
    2. Click on HKEY_LOCAL_MACHINE in the registry tree, go to the File menu and choose Load Hive...
    3. Browse to \Windows\System32\Config\ in the location where you built your XP Embedded image
    4. Load one of the hives named *.SAV - this is because the FBA process copies the hives with *.SAV extensions over the same hives without the *.SAV extensions before performing any other actions, so if you want registry changes to take effect during FBA you have to change the *.SAV hive
    5. When prompted for a hive name, enter a name that does not clash with an existing registry hive on your development machine
    6. Make any desired changes to the registry in the Regedit UI
    7. Click on the hive name that you provided in step 6 above, go to the File menu and choose Unload Hive...

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

     

  • Aaron Stebner's WebLog

    Cool list of MSI setup tricks

    • 4 Comments

    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  :-)

    http://www.installsite.org/pages/en/msi/tips.htm

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

     

  • Aaron Stebner's WebLog

    Orca install package

    • 56 Comments

    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>

     

  • Aaron Stebner's WebLog

    Thoughts on setup repackaging and reverse engineering

    • 4 Comments

    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:

    • Convert a non-MSI setup to an MSI so that it can be deployed via Active Directory, using tools such as FileMon and RegMon
    • Remove specific custom actions, files, registry keys, etc from an MSI
    • Use transforms to make changes to the installation behavior of an MSI

    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

    • Using the setup package to install on an embedded image after deploying the OS (which has drawbacks like increased footprint and additional troubleshooting required for identifying missing dependencies needed by the setup package, etc)
    • Reverse engineering the setup package and creating a component that can be imported into the embedded database using the same set of tools as the university admins above

    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

    • The biggest key to working with MSIs is to understand how Windows Installer works - what a component is, how Windows Installer does reference counting, what the data in key tables in the MSI are used for
    • Simple MSI setups are relatively easy to reverse engineer, assuming they only install files listed in the File table and write registry keys/values listed in the Registry table
    • As soon as you start introducing custom actions, type libraries, self registration, etc then the job becomes more difficult.  If it wasn't for these types of “black box“ actions, our team could produce an msi2sld tool similar to the inf2sld tool that ships with the Windows Embedded toos.  This tool could still be useful as a starting point for creating embedded components - I'll have to look into this some more
    • You can create an administrative share by running msiexec /a <msi name> to create a file layout that includes all of the files that the MSI will install - this can be useful when the files to be installed are consumed into the MSI via CAB/MSM files, and also when creating an embedded component where you need to create a file repository
    • Orca is an invaluable tool - you can change/remove launch conditions, custom actions, registry values, component conditions, and on and on.  I generally only use Orca to look at the contents of an MSI though, I would recommend not changing a shipping setup - you never know what unintended side effects you may cause, and the worst possible thing would be if you make a change that ends up preventing future MSP's from applying to your machine.
    • Rather than using Orca to change existing setups, I suggest creating transforms.  All you have to do is make a copy of the MSI you want to modify, keep one in the original form, modify the other with Orca, then use a transform creation tool to analyze the differences between the 2 MSIs and create an MST

    Random Tricks for Packaging and Reverse Engineering

    • Running a setup package with the /? switch (or -? or -h or -help) will usually show a set of command line parameters supported by the setup.  This is often useful to unpack a self-extracting EXE package to get to the files that will be installed or to get to the INF file for a driver to use inf2sld
    • Look for an INI file or DAT file in a self-extracting setup package or sitting next to a setup.exe - these often contain settings that are used during setup.  Sometimes they will contain data or variables that are self-explanatory or contain comments (versions of Office are especially good at this), and these values can often be changed to update the behavior of a setup
    • Get to know other setup technologies - Wise and InstallShield both make MSI package creation tools, and have specific UI, packaging strategies and behaviors that are slightly different and unique; OCM and INF-based setups are used for installing drivers and some other components that ship as part of the OS on some platforms; IExpress is used for creating self-extracting EXE packages; SFXCab is a next-generation update to IExpress that is used for newer hotfixes created for Windows that are shipped on Windows Update

    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!

  • Aaron Stebner's WebLog

    Visual Studio Whidbey Express SKU manual install instructions

    • 11 Comments

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

     

  • Aaron Stebner's WebLog

    XP Embedded and Native Remote Debugging - minlogon update!

    • 0 Comments

    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.

     

  • Aaron Stebner's WebLog

    DUAScriptGen v1.0.0004 has been released

    • 3 Comments

    There is a new version of DUAScriptGen now available at http://www.winisp.net/scrat/DUAScriptGen/DUAScriptGen.zip

    It contains the following fixes:

    • Fixed bug where file entries were incorrectly written to the DUS file if the user specifies a full path including drive letter
    • Fixed bug where binary data was being written to the DUS file as hex but duagent.exe expects it as decimals
    • Added ability to parse folder tokens in registry values (%10% represents \Windows\ for example), previously this only worked for file paths
    • Added some menu items to the File menu that were previously only accessible via buttons on the main form
    • Added version stamp information in the DUS files that are created by DUAScriptGen to identify what version of the tool created the file

    As always, please let Mike Hall and/or me know if you see any bugs or have any feature suggestions.  Thanks!

  • Aaron Stebner's WebLog

    Installing Microsoft Loopback Adapter

    • 17 Comments

    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

    • Go to the Add Hardware control panel
    • Click Next on the first wizard screen
    • When asked if the hardware is connected, select Yes and click Next
    • In the list of installed hardware, scroll to the bottom and select Add a new hardware device and click Next
    • Choose the option titled Install the hardware that I manually select from a list (Advanced) and click Next
    • In the list of common hardware types, select Network adapters and click Next
    • In the list of manufacturers, select Microsoft.  Then in the list of network adapters, select Microsoft Loopback Adapter and click Next
    • Click Next one more time to install the Microsoft Loopback Adapter and then press Finish

    Now that you have installed the Microsoft Loopback Adapter, you need to configure an IP address for it.

    Configuring Microsoft Loopback Adapter

    • Go to the Network Connections control panel
    • Locate the LAN or High-Speed Internet connection that has a Device name of Microsoft Loopback Adapter, right-click on it and choose Properties
    • Select the Internet Protocol (TCP/IP) item and click Properties
    • Select the option to Use the following IP address and enter 192.168.2.1 for the IP address.  This will cause a subnet mask of 255.255.255.0 to appear
    • Click OK to accept the changes and Close to exit the Properties dialog

    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.

     

  • Aaron Stebner's WebLog

    Notes from DevCon Ask the Experts v2.0

    • 3 Comments

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

    • Is it possible to restrict/disable plug-n-play detection and the “found a new device“ dialog after the device is up and running?  PnP is something I haven't done extensive testing with since I joined this group so I want to do some research into this.  I am guessing that this has been answered on the newsgroups but I need to go find out....
    • What is the version of MSXML that Target Designer requires?  I did a quick search of our tools MSI and didn't find any references to MSXML, so it appears that Target Designer should work correctly with the version that ships with golden XP.  I don't know if that is actually true though - so this is another item for me to do some quick research on
    • In pre-SP2 runtime images, there is about a 30 second lag before Internet Connection Firewall (ICF) is up and running, which gives a window of time for virus infection.  This is addressed in XPSP2 with the new Windows Firewall functionality, but what are the options for closing this in SP1 runtimes?
    • We need to discuss strategies for creating components from applications in more detail - this item gets into the topic that I've been thinking a lot about both in the embedded space and in general - application repackaging.  I'm still working on a discussion of this topic and I'm sorry it is taking me so long to publish, but it keeps getting longer and longer and I want to find ways to break it up but also cover all the stuff on my mind in this area
    • The need for source control and integrated build process engineering for XPE was emphasized again today, and I'm really excited to dig into this area in more detail.  This hits one of my other areas of research lately - creating cleaner, repeatable build processes for our products.  The original designs for Target Designer seem to have only been targeting users who want to build runtimes in the GUI, and that doesn't lead to readily repeatable processes for companies that want to build lots of different images or maintain source control over their SLD/SLX files and create something like daily builds for their runtimes, figure out what changes from revision to revision of an SLD/SLX, etc.  Stay tuned for more ideas in my blog and hopefully some how-to white papers on the MSDN embedded site soon.....

     

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

  • Aaron Stebner's WebLog

    How to directly download Visual Studio Express packages

    • 12 Comments

    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:

    1. Use the links provided for the individual packages at http://lab.msdn.microsoft.com/productfeedback/viewFeedback.aspx?feedbackid=f472b36e-2c26-483a-bc73-0dd643d6aae2 to save each package to your local machine
    2. Run the download manager package from the web download site, and let it extract to your %temp% directory.  While it is still running, go to %temp% and find a folder named SIT*.TMP (where * is a randomly generated alphanumeric sequence), and open the file baseline.dat in notepad or another text editor.  Then for each package that you need to download, find the bracketed section for the “gencomp“ and then find the URL item.  If you open a browser window and type http://go.microsoft.com/ and then add in the value of the URL item, it will take you to the package download directly

    If you want, you can also assemble the equivalent of a CD layout on your local hard drive.  To do this, use these steps:

    1. Create a folder on your local machine to store the CD layout (for example - expressbeta)
    2. Create a subfolder named WCU
    3. Under WCU create folders named dotnetframework, MSDNExpress, SSE, and jsharpredistcore (if you are installing a SKU that requires the J# redist package)
    4. Download the initial express package from the site and run it
    5. While the package is still running, go to %temp% and copy the contents of SIT*.TMP to the root of the expressbeta folder you created in step 1 above
    6. Locate and download the .NET Framework and place it in the dotnetframework folder
    7. Locate and download the J# redist and place it in the jsharpredistcore folder
    8. Locate the main express SKU and place it in the expressbeta folder.  Note that this package will be named the same as the initial 2 meg download that you get to by clicking the link on the download site (vcssetup.exe for C# express for example) - this is kind of a tricky/misleading naming scheme that will hopefully be updated for the next release
    9. Locate and download MSDN Express if you want to install it and place it in the MSDNExpress folder
    10. Locate and download SQL Express if you want to install it and place it in the SSE folder
    11. After doing all of this, cancel out of the setpu that you launched in step 4 above and then run setup.exe from the expressbeta folder you created

    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>

     

  • Aaron Stebner's WebLog

    Download Visual Studio Whidbey Express Versions Now!!

    • 7 Comments

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

     

  • Aaron Stebner's WebLog

    Jon Fincher's Blog

    • 2 Comments

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

  • Aaron Stebner's WebLog

    XP Embedded and Native Remote Debugging

    • 0 Comments

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

     

  • 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

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

     

Page 47 of 48 (1,185 items) «4445464748