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.
As described in this post on S. Somasegar's blog and in other places, Visual Studio codename Orcas beta 1 was recently released. Some customers (such as in this forum post) have reported that Orcas beta 1 setup is failing on their system while it tries to install the Microsoft Web Designer Tools component.
There is a known issue where the Microsoft Web Designer Tools component will fail if you attempt to install it on a system that has a beta version of Microsoft Office 2007 installed. This component is produced by the Office team, and the setup wrapper for the component has logic in it to block if it detects beta versions of Office 2007 on the system. Unfortunately, since Visual Studio setup launches the Web Designer Tools setup in silent mode, the error message only appears in the log file instead of in the UI.
To diagnose this issue, you can look at the Web Designer Tools log file, which is located at %temp%\SetupExe(########).log (where ####### is a unique value with date/time information and a randomly generated ending). If you attempt to install on a system that has a beta version of Office 2007 installed, there will be an error that looks like the following:
Not showing message because suppress modal has been set. Title: 'Setup Errors', Message: 'Setup is unable to proceed due to the following error(s): The 2007 Microsoft Office system does not support upgrading from a prerelease version of the 2007 Microsoft Office system. You must first uninstall any prerelease versions of the 2007 Microsoft Office system products and associated technologies. Correct the issue(s) listed above and re-run setup.
Not showing message because suppress modal has been set. Title: 'Setup Errors', Message: 'Setup is unable to proceed due to the following error(s):
The 2007 Microsoft Office system does not support upgrading from a prerelease version of the 2007 Microsoft Office system.
You must first uninstall any prerelease versions of the 2007 Microsoft Office system products and associated technologies.
Correct the issue(s) listed above and re-run setup.
In order to resolve this issue, you can uninstall any remaining beta versions of Office 2007 from your system using the Add/Remove Programs control panel and then re-run Visual Studio Orcas beta 1 setup. If you do not see any beta versions of Office 2007 in your Add/Remove Programs control panel, you can use steps like the ones listed in this blog post to locate and uninstall the beta components. All Office 2007 components have the string 0FF1CE at the end of the product code GUID, so you can search for that string to locate these components in the output from the MSI inventory tool. When you do this, just make sure that you do not inadvertantly uninstall the final release of Office 2007. If in doubt, you can tell from the product name whether or not the product in question is a beta or the final release.
If you've ever been interested in trying out beta versions of Windows Media Center and providing feedback that helps determine what features will be included in future editions of the product, now is your chance! As Jessica announced yesterday on this Green Button forum post, there is an online application form available to sign up for a chance to be a Media Center beta tester.
You can apply by filling out the web form located at the following link:
Please note the following caveats listed on that application form:
Update - I just found out that if you were a member of the Windows Vista Media Center beta program, you do not need to re-apply.
<update date="4/19/2007"> Added an update indicating that existing Windows Vista Media Center beta program members do not need to re-apply on this web form </update>
Heath Stewart has posted an item on his blog that I wanted to link to here so that hopefully more setup developers will find it. The post, located at http://blogs.msdn.com/heaths/archive/2007/04/20/custom-action-guidelines.aspx, provides a set of high-level guidelines for creating custom actions if you find that they are necessary for your MSI-based setup.
Included in these guidelines are items such as the following:
If you are a setup developer working with custom actions in an MSI-based setup, I encourage you to take a look at Heath's post for more detailed information about guidelines for creating custom actions.
There is a new cumulative update package available for download today that applies to Windows Vista Media Center systems. This cumulative update is called the April 2007 Cumulative Update for Media Center for Windows Vista, and is also known as KB932818, and is available in both x86 and x64 versions.
This update includes the following enhancements to Media Center functionality (which are also described in more detail in this knowledge base article):
This update also includes the following bug fixes:
Here are some useful links for this cumulative update:
If you are running Windows Vista Home Premium or Ultimate editions and using Media Center, I highly encourage you to install the April 2007 cumulative update (KB932818) on your system.
For a while, I've been trying to figure out how to manage the posts on my blog. When I originally established my blog back in 2005, the blog creation wizard asked me to create one or more categories to classify content that I wrote. I didn't have a clear idea about what kind of topics I wanted to write about back then, so I created some really broad categories (Setup issues, Visual Studio and .NET Framework and Windows Embedded). I've added a few more broad categories over the past couple of years as the topics I've posted on my blog have evolved (Mailbag, Miscellaneous, Windows Media Center - General, Windows Media Center - Development and Windows Vista).
Since I started writing in this blog, I have found that I write about a wide range of topics, and only a subset of readers are really interested in each type of topic, so they'll tend to subscribe to the categories they're interested in. I also tend to use my blog to store links to information I think is interesting and that I want to be able to find in the future, but I sometimes have a hard time finding specific links later on when I need them.
Based on these usage patterns, I think it will provide overall benefit to create a larger set of more targeted categories for my blog content. This introduces a couple of possible problems - I don't want to go through all of my old posts that are filed in the broad categories and re-classify them. I also don't want to break any category subscriptions that anyone might have by deleting the old categories or no longer using them.
So, I settled on a plan where I will create more specific categories, but retain the broad categories as well. For old blog posts, if I edit them in the future I will add tags for the new categories. I will also go through the posts that I refer people to most frequently to troubleshoot problems and add tags to them as well. For new blog posts, I will classify them into both the new categories and the old categories I would have used if the new ones didn't exist. Then as content builds up in the new categories, if anyone has subscriptions to the broad categories and decides they want to only get targeted information in more specific areas, they can adjust their subscriptions.
Hopefully this will provide a good step forward with the overall goal of making it easier to quickly find relevant information from this blog.
Here is an initial set of new, more specific categories that I have created:
If you have any feedback or recommendations about how to better organize the information in my blog, please leave a comment on this blog post or contact me and let me know what you think.
Rob Mensching wrote a couple of interesting posts this week regarding upcoming plans for WiX development that I wanted to link to here to help make sure setup developers see them.
Locking down WiX v2.0
In the first post, located at http://robmensching.com/blog/archive/2007/04/09/WiX-v2-entering-escrow.aspx, Rob outlines the plan for locking down the WiX v2.0 project. The key message in this post is that WiX v2.0 is entering "escrow" mode. This is the first step in locking down this version of WiX. It means that for about a month or so, no fixes will be made in the WiX v2.0 source tree, and no new builds will be produced. If you're a setup developer using WiX v2.0, I encourage you to pick up the latest WiX v2.0 build from http://wix.sourceforge.net/downloadv2.html and put it through its paces. Make sure to report any bugs you find at http://sourceforge.net/tracker/?group_id=105970&atid=642714.
Roadmap for WiX v3.0
In the second post, located at http://robmensching.com/blog/archive/2007/04/10/WiX-v3-Roadmap-Draft.aspx, Rob outlines a draft of a roadmap for WiX v3.0 and potential future versions of WiX. This roadmap covers the following aspects of WiX v3.0:
If you are a setup developer and are using WiX or are considering WiX for your MSI-based setups, I encourage you to take a look at both of the above posts on Rob's blog for more details about where WiX v2.0, v3.0 and beyond are heading over the coming months.
I often get asked questions about how to read, interpret and find error information in verbose Windows Installer log files. These logs tend to be very long, and it can be difficult to filter out noise in order to find the truly useful information needed for debugging purposes. In the past, I posted an item describing how to locate the cause of error code 1603 in a Windows Installer log file - http://blogs.msdn.com/astebner/archive/2005/08/01/446328.aspx, but this technique is only one of many useful strategies for analyzing verbose log files.
Today, I was catching up on some of the blog posts from blogs I subscribe to, and I noticed an item on the Windows Installer team blog that I wanted to also link to here. The Windows Installer blog links to another blog post providing details about how to interpret Windows Installer logs. You can find this blog post at http://blogs.technet.com/richard_macdonald/archive/2007/04/02/How-to-Interpret-Windows-Installer-Logs.aspx.
This post includes the following useful information:
I encourage you to take a look at this blog post, especially the annotated log file and the wilogutl.exe tool, if you are a setup developer and/or need to debug MSI-based setups.
A while back, I wrote a post with my opinion about managed code custom actions - http://blogs.msdn.com/astebner/archive/2005/03/10/392280.aspx. Essentially, I recommend avoiding using them in an MSI-based setup because of the extra complexity they introduce to the installation process.
This week, I noticed that Rob Mensching wrote an interesting analysis of issues surrounding supporting managed code custom actions in MSI-based setups in a recent blog post at http://robmensching.com/blog/archive/2007/04/19/Managed-Code-CustomActions-no-support-on-the-way-and-heres.aspx. His blog post presents much more concrete details about the potential dangers that managed code custom actions introduce to a setup. It also describes some higher level strategic reasons that Windows Installer does not officially support/endorse managed code custom actions.
If you are a setup developer, Rob's blog post is a very informative read and hopefully it will encourage you to do the following:
I was talking recently with Surupa Biswas (a program manager on the NGen team at Microsoft and the author of the MSDN Magazine article describing NGen at http://msdn.microsoft.com/msdnmag/issues/06/05/CLRInsideOut/). We were discussing a bug that was uncovered in one of the daily builds of the next version of Visual Studio (codenamed Orcas). That bug illustrated a potential issue that any setup could encounter if it includes native image generation (NGen) actions. We decided it would be best to describe this scenario and offer some guidance to setup developers to help them avoid this type of problem in their setups.
The underlying issue is that the NGen service is currently not fully re-entrant, and this can lead to deadlock issues. An example of a deadlock scenario that is possible today is the following:
When NGen attempts to generate a native image for A.dll, and A.dll has a static dependency on some optional component B.dll, NGen will try to load this dependency. That in turn can trigger the installation and native image generation for the optional component. This means that NGen can be triggered for B.dll while the system is still attempting to NGen A.dll, and NGen will end up in a deadlocked state.
How to avoid this problem
In order to avoid this possible deadlock, setup developers should avoid using synchronous NGen during the installation process for optional components. Instead, if NGen is desired for optional components, it can be scheduled to occur asynchronously after the installation process is complete.
If you are using WiX to build an MSI-based installer that includes NGen (by using the instructions I previously posted at http://blogs.msdn.com/astebner/archive/2007/03/03/how-to-ngen-files-in-an-msi-based-setup-package-using-wix.aspx), this means that you need to use an NGen priority value of 3 (for asynchronous) instead of 0 (for synchronous).
Recently, I was helping a friend test an installer for a Windows Vista Media Center application and ran across an interesting issue that I wanted to post here so that other Media Center application developers will think about it when designing their own setups as well.
The installer I was testing included entries in the Registry table of the MSI to create registry values to register the application so it would appear in the Media Center UI. This algorithm is described at http://msdn2.microsoft.com/en-us/library/bb189827.aspx in the Windows Vista Media Center SDK documentation.
When I installed this MSI on my x64 Windows Vista Ultimate Edition system and then launched Media Center, I could not find any entry points to use to start the application. I investigated further by looking around in my system registry using regedit.exe, and I found that all of the Media Center registration information was created in the following location:
Because the MSI I installed was a 32-bit MSI, Windows Installer automatically creates registry values in the 32-bit registry instead of the 64-bit registry. However, since Media Center runs as a native 64-bit application on Windows Vista x64, it only knows to look in the 64-bit registry for extensibility application registration information. As a result, I did not see any entry points to this application in the Media Center UI even after installing the MSI.
In order to avoid this issue, I recommend using a custom action that calls RegisterMceApp.exe instead of writing the registration registry values directly. You can see examples that demonstrate how to create a custom action like this using WiX by looking at the Q and Z sample applications in the Windows Media Center SDK for Windows Vista. The files q.wxs and z.wxs contain fully commented WiX setup source code that describes what each action is designed to do.
I also wrote more detailed blog posts describing the Q sample application setup at this location for WiX v2.0 and this location for WiX v3.0 that are useful to look at in order to get a deeper understanding about how Windows Media Center application setups should be constructed.
If you prefer to not use WiX to build your setup, the only other reliable alternative I know that will allow you to avoid this 64-bit installation issue is to create separate installers for 32-bit and 64-bit operating systems. In this option, you can create the 32-bit installer the same way as before. However, you must make the following changes in the 64-bit installer in order for it to create the Media Center registration registry values in the correct location:
Links to additional information
You can check out the following links for more information about 64-bit-specific issues related to Windows Installer:
You can also check out the following links for more information about how WOW64 works in Windows:
I use Orca from the Windows Installer SDK to view the contents of Windows Installer setup packages (MSI files) and Windows Installer patch packages (MSP files) all the time. When I view MSPs, I typically right-click on the applicable MSI, choose Edit with Orca, and then drag-and-drop the MSP file(s) into the Orca window to view the changes that the patch will make to the original MSI.
However, I recently ran into an issue while using Orca on Windows Vista - dragging and dropping MSPs onto my MSI in Orca does not load the MSP. Instead, I am only able to open the MSP by going to Orca's Transform menu, choosing View Patch... and browsing to the MSP file in the Open File dialog.
As I previously mentioned, one of the features that I used to use all of the time in previous versions of Windows no longer works in Windows Vista - dragging and dropping a file or folder into a cmd prompt in order to copy the path to that file/folder into the cmd prompt. It appears that there is some kind of security-related limitation regarding dragging and dropping objects in Windows Vista that affects my cmd prompt scenario and also dragging MSPs onto an MSI in Orca.
In case you run into problems viewing MSPs in Orca on Windows Vista, just make sure that you use the Transform | View Patch... menu option instead of relying on dragging and dropping like I used to.
Also, Heath Stewart has a blog post at http://blogs.msdn.com/heaths/archive/2006/11/07/viewing-patches-in-orca.aspx where he shows some screenshots of what MSPs look like when you apply them to an MSI within Orca.
I haven't been keeping up with the Media Center Sandbox forums as well as I would like to lately, and I apologize for that. Based on the forum posts I've caught up on over the past weekend and the comments I've received on my blog, I've noticed that some folks are struggling with creating MSI-based installers for their Media Center applications in order to deliver them to customers. I wanted to summarize some of the information I've found useful in the past when I was learning how to create installers for Media Center applications myself. I'd also like to hear feedback about how things can be improved in the future.
Samples in the Media Center SDK
If you installed the Windows Vista Media Center SDK to the default path, you will see sample WiX source files for the Q and Z sample applications in the following locations:
The files Q.wxs and Z.wxs each have detailed comments that explain what each of the sections of the file is designed to do, along with some gotchas that you need to keep in mind when creating your own WiX-based installers.
In addition, the Q and Z application each include a readme.htm file that includes information about how to build an MSI-based installer for each of these sample applications.
The WiX files in the original release of the Media Center SDK are based on WiX v2.0, and the upcoming SDK refresh will update those files to be based on WiX v3.0.
Unfortunately, all of the above information is only included in the Media Center SDK samples and not in the written documentation. That means it is not searchable via the online Media Center SDK documentation page.
I've written some blog posts that I intended to supplement the information available in the Media Center SDK (since I'm somewhat of a "setup geek" and tend to dig deeper into deployment issues than most Media Center developers would need to). Here are some of the posts I'd consider most interesting for those of you working on building setups for Media Center applications:
Online WiX tutorial
There is a really comprehensive tutorial that I used extensively when I was first learning how to use WiX. You can find it at http://www.tramontana.co.hu/wix/. This tutorial walks you through the end-to-end process of creating a fully featured MSI-based setup. Most of the stuff in this tutorial is overkill for all but the most complex Media Center applications, but it can be helpful in case you want to add items to your setup that are not included in the existing Q and Z sample setup files.
WiX user groups
If all else fails, there is a very active online community of WiX developers and users who field questions, report bugs and help each other resolve WiX issues. The developers at Microsoft who volunteer as WiX developers hang out in these forums and respond to a lot of the questions. Here are some useful links:
I've seen some questions about why the Media Center SDK recommends WiX as a solution for creating MSIs as opposed to other options such as the Visual Studio setup/deployment project system. These recommendations come mostly from me based on my experience and preferences. Most teams at Microsoft that create MSI-based installers now use WiX, and I used it to create the installer for the Media Center SDK itself.
I admit that it has a bit steeper learning curve, and it currently lacks some of the visual designer tools that the Visual Studio setup/deployment projects offer, but the MSIs it produces are cleaner, more fully featured, more reliably patched if necessary, etc. The learning curve is a big thing I hope to help lessen in the future by doing things like the following:
Hopefully the above is helpful. Please let me know by posting comments here, posting comments on the Media Center Sandbox forum, and/or emailing me if you have any questions or suggestions for the future.
A while back, I posted an item about a book co-authored by Ian Dixon titled Using Microsoft Vista Media Center that was available for pre-ordering. I just noticed a post on Ian's blog indicating that the book has been released. The book covers a range of topics, including the following list from Ian's post:
I've also heard that there is a chapter about Windows Media Center extensibility and application development, but I haven't seen a final copy of the book to confirm that.
I'd also like to congratulate Ian for becoming a published author. I remember how excited I was to see my first white paper published on MSDN, and I can only imagine how much more thrilling it must be to be the co-author of a book....
Niall Ginsbourg (a Media Center community development expert and the developer behind the Big Screen Blog) is working on an updated version of his Big Screen Photos Flickr photo viewer for Windows Vista Media Center.
You can check out the blog post at http://mobilewares.spaces.live.com/Blog/cns!78533A1A2E078194!395.entry. It contains example screenshots and a video of the work-in-progress new version of Big Screen Photos. As the post indicates, the new version will support all of the features of the original version, and has some visual design changes to make it look and feel more like the Windows Vista Media Center UI.
The screenshots and videos look good, and I encourage you to check them out if you get a chance. After looking at them myself, I'm looking forward to trying out a beta version of the application.
The original version of Big Screen Photos is a Windows Presentation Foundation (WPF) XBAP application that is integrated into Windows Media Center and can also function as a standalone application. The new version is being implemented in Media Center Markup Language (MCML) and the Windows Media Center Presentation Layer (WMCPL). As Niall gets farther along, I really hope he'll volunteer to write a comparison study between implementing the Big Screen Photos application in WPF versus implementing it in MCML/WMCPL to help other Media Center developers make a more informed decision about what technology to choose for their applications (hint hint Niall....)
Visual Studio codename Orcas beta 1 was recently released, and now a standalone version of the .NET Framework 3.5 beta 1 (which is also installed as a prerequisite during VS Orcas setup) is available as a standalone download on the Microsoft download center. Here are links to download information for the .NET Framework 3.5 beta 1:
.NET Framework 3.5 setup-specific details
The .NET Framework 3.5 follows a similar model to the .NET Framework 3.0 - it builds on the .NET Framework 2.0 and adds supplemental features. It is not an entirely new version of the common language runtime (CLR). Behind the scenes, the .NET Framework 3.5 installs the following (if they are not already present on the system):
The package available for download is a web download bootstrapper. It will inventory your system and download and install the packages that it detects are not yet installed.
.NET Framework 3.5 features
Some of the key new features introduced in the .NET Framework 3.5 are the following (also summarized on the download page linked above):
Getting help from the community
If you encounter issues while installing or using the .NET Framework 3.5 beta 1 or Visual Studio codename Orcas beta 1, there are several community forums available at http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID=153&SiteID=1. For setup-related issues, you can use the following forums:
Reporting bugs found in the beta version
Also, most importantly, if you run into problems while installing or using the .NET Framework 3.5 beta 1 and/or Visual Studio codename Orcas, please help us make the final release as good as it can be by reporting bugs back to Microsoft. You can use the site at http://connect.microsoft.com/VisualStudio/ to report bugs or suggestions for these beta products.
I have seen countless cases where bugs reported by end users that could not be reproduced in our test labs at Microsoft have been fixed (such as this tricky issue in the .NET Framework 2.0), so I assure you that every bug report is reviewed by team members here at Microsoft and they are taken very seriously.
I previously wrote a blog post about updated versions of the Visual C++ 8.0 runtime files that shipped as a part of Visual Studio 2005 SP1. At the time I wrote that post, the only place that standalone redistributable packages for the VC 8.0 SP1 runtime files could be obtained was by installing Visual Studio 2005 standard or higher, installing VS 2005 SP1, and then going to the folder %ProgramFiles%\Microsoft Visual Studio 8\SDK\v2.0\Bootstrapper\Packages.
Recently, standalone versions of the VC 8.0 SP1 runtime files redistributable packages were posted so they can be downloaded directly even if you do not have a system with VS 2005 and SP1 installed. They can be downloaded from the following locations:
Links for additional information about the VC++ runtime files
The following links contain some additional information that may be useful if you are creating a setup package that will deploy or depend on the VC 8.0 runtime files.
I just came across a link to a forum on The Green Button that I wanted to pass on. The forum is called "Ask Jessica" and the tag line for this forum states taht you can ask questions directly to Jessica Zahn, a program manager on the TV team in Windows Media Center.
You can find this forum at http://thegreenbutton.com/forums/83/ShowForum.aspx.
Jessica has been doing a great job so far of trying to find answers to as many of the questions asked there as possible, even if they are not in areas of Windows Media Center that she works on directly. Also, I'm really happy to see that some other folks on the Windows Media Center team are starting to read and answer questions on this forum as well.
There is also a Windows Media Center public newsgroup that I've found to be useful for identifying workarounds and asking questions about Windows Media Center functionality. You can view the contents of the Microsoft.Public.Windows.MediaCenter newsgroup and post questions to that newsgroup by using this link - http://www.microsoft.com/windowsxp/expertzone/newsgroups/reader.mspx?dg=microsoft.public.windows.mediacenter
If you have problems with or questions about Windows Media Center, I encourage you to look at the posts on this forum and the Microsoft newsgroups, and ask a new question in one of these places if you can't find the specific information you're looking for.
Ian Dixon has posted episode #103 of the Media Center Show. You can view a summary transcript and download the episode from this blog post - http://iandixon.spaces.live.com/Blog/cns!36983156CAA83EA9!1953.entry.
In this episode, Ian talks with Francis Hogle. Francis was the development manager for the Media Center core platform team for the Windows Vista release, and also worked on previous releases of Windows XP Media Center Edition. He talks with Ian about various aspects of Media Center application development.
If you're interested in Media Center development, and/or how Media Center has evolved over the years, especially as a development platform, I encourage you to check out this episode of the Media Center Show.
Steven Harding has been posting information on a new Windows Media Center developer blog that is being hosted on the Digital Lifestyle website. I wanted to post a link to this blog and encourage Media Center developers to take a look at this blog for some great information about creating Windows Vista Media Center applications using Media Center Markup Language (MCML).
You can find Steven's Digital Lifestyle blog at http://thedigitallifestyle.com/cs/blogs/developer/default.aspx.
In addition, for those of you who don't know Steven, he has also done the following Media Center development projects:
I have been trying to follow the steps listed in some of your blog posts in order to create a network install point for Visual Web Developer Express Edition. I started by downloading and extracting the Visual Web Developer ISO file to a network share based on the instructions in this blog article. Then, I attempted to run the following command line that is listed in this blog post to perform a silent installation:
\\myserver\myshare\ixpvwd.exe /q:a /c:"msiexec /i vnssetup.msi VSEXTUI=1 ADDLOCAL=ALL REBOOT=ReallySuppress /qn"
\\myserver\myshare\ixpvwd.exe /q:a /c:"msiexec /i vnssetup.msi VSEXTUI=1 ADDLOCAL=ALL REBOOT=ReallySuppress /qn"
However, when I tried this, I got Windows Installer error code 1308 stating the following:
Source file not found: .\rebootstub.exe
Source file not found: .\rebootstub.exe
How can I fix this error so that I can successfully install Visual Web Developer 2005 Express Edition in silent mode?
Each of the Visual Studio 2005 Express Edition packages (ixpvb.exe, ixpvc.exe, ixpvcs.exe, ixpvjs.exe and ixpvwd.exe) contain an MSI that installs some files from within the CAB file that is included in the EXE itself and some files that are a part of the web download bootstrapper. In order to reduce download size, they re-use the files from the web download bootstrapper instead of requiring an additional download.
However, when assembling a network install point, the files from the web download bootstrapper may not be present in the correct location that the Express Edition setup packages expect them to be in. In those cases, you can see file not found errors (represented by Windows Installer error code 1308) when attempting to install.
In order to resolve this issue, you need to make sure to download and extract the contents of the web download bootstrapper as part of the process of creating a network install point. The way to accomplish this is listed in steps 1 through 3 of option 2 of the blog article at http://blogs.msdn.com/astebner/articles/551674.aspx.
Also note that you need to make sure that your silent installation includes steps to install all prerequisite components (such as Windows Installer 3.1 and the .NET Framework 2.0) or validate that they are already installed on the computers prior to attempting to install the main Express Edition MSI package. You will encounter other Express Edition installation errors if you do not ensure that prerequisites are present first.
More details for setup developers
If you are interested about how to author an MSI that will install some files from within an embedded or external CAB file and other files from flat, uncompressed source locations, I suggest looking at the following Windows Installer MSDN topics: