Aaron Stebner's WebLog

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

June, 2007

  • Aaron Stebner's WebLog

    See you in three weeks....

    • 2 Comments

    I wanted to drop a brief note and let folks who read my blog know that I'm going to be on vacation for the next 3 weeks.  During that time, I will be completely away from my computer, and I won't be able to read emails sent to me via my blog or moderate the comments on my blog.  That means if you post a comment, it will not appear until I mark it as approved when I get back (unfortunately I got too many spam comments in the past and had to turn on comment moderation).

    I apologize in advance for any inconvenience this might cause.  I'll see you in 3 weeks....

  • Aaron Stebner's WebLog

    Link to information about the Windows Installer 4.5 beta program

    • 0 Comments

    I noticed a post on the Windows Installer team blog this morning that I wanted to link to here.  There will be a beta available soon for Windows Installer 4.5, and the team is asking for folks to sign up to participate in the beta program.

    If you're interested in trying out a beta version of Windows Installer 4.5, I encourage you to check out the following locations for more information:

  • Aaron Stebner's WebLog

    Possible cause of Media Center remote control button issues related to HID service

    • 2 Comments

    Recently, I heard from a customer who had a problem where some buttons on their remote control worked but others did not.  They tried the workarounds in the Remote Control and IR Receiver Errors section of this blog article, but none of them helped.

    Fortunately, they found a post on the Logitech discussion forum that allowed them to fix the problem.  I wanted to post a link to this forum post in case it is helpful to other folks who are having trouble with their remote controls.

    The forum post is located at http://forums.logitech.com/logitech/board/message?board.id=general&message.id=2251, and the following is a summary of the workaround listed there that helped the customer that I heard from regarding this issue:

    1. Make sure you installed the latest drivers for your IR receiver
    2. Click on the Start menu, choose Run, type services.msc and click OK
    3. In the Services snap-in, locate the Human Interface Device (HID) Input Service and verify that the Startup Type is set to Automatic and the service Status is set to Started
    4. If the service is not started, attempt to start it by right-clicking on it and choosing Start

    If the service fails to start with error code 2, use the following steps to add a new value to the registry on your system for hidserv.dll:

    1. Click on the Start menu, choose Run, type cmd and click OK
    2. Type this command: reg add "HKLM\System\CurrentControlSet\Services\HidServ\Parameters" /v ServiceDll /t REG_EXPAND_SZ /d ^%SystemRoot^%\system32\hidserv.dll /f
    3. Try to start the service again using the above steps
  • Aaron Stebner's WebLog

    Link to an article about managing side-by-side file associations for Visual Studio add-ins

    • 3 Comments

    I have created installers in the past (using WiX) that add templates to Visual Studio 2005.  Recently, I started looking at adding support for Visual Studio 2008 to one of these setup packages.  This particular package installs some file associations in addition to project templates.  The file associations are used to add an entry to the menu that appears when right-clicking on files with a specific extension to open the file in Visual Studio 2005, and to automatically launch Visual Studio 2005 when double-clicking on files with a specific extension.

    Visual Studio 2005 and 2008 can be installed and run side-by-side on the same system.  However, any given file extension can only have one "verb" associated with it for the default action when double-clicking on a file with that extension.  The combination of these two facts left me with a small dilemma - how should this file extension be registered if a user installs this Visual Studio add-in package on a system that has both VS 2005 and 2008 installed?

    The ideal solution would be to have a stub program that is invoked when files with this extension are double-clicked, and allow the user to select the version of Visual Studio to run from within the stub program, or have the stub program examine the file contents and automatically choose what version of Visual Studio to use.  This is what Visual Studio itself does for file extensions that it registers.  However, I did not want to invest that much in a solution here.

    Fortunately, Bob Arnson alerted me to an article in the Visual Studio help collection on MSDN called Managing Side-by-Side File Associations.  That article describes how to implement a "highest version wins" strategy for file associations (meaning that whenever the file association is registered on a system, the default action when opening files with the specified extension will be to open it in whatever the most recent version of Visual Studio was installed at the time that the file association was registered).

    The algorithm is presented with example Windows Installer syntax that can be included in an MSI to accomplish this behavior.  At a high level, the algorithm looks like the following:

    1. Add an AppSearch for each supported edition of Visual Studio that will resolve to the full path of devenv.exe
    2. Add one type 51 custom action per supported edition of Visual Studio that will set a property named DEVENV_EXE_LATEST to the path of that version of devenv.exe that is set by the AppSearch results from step 1
    3. Add each of the type 51 custom actions to the InstallExecuteSequence table and condition them such that they will only run if the appropriate version of Visual Studio is installed.  For example, if both VS 2003 and VS 2005 are installed, the conditions will cause only the custom action to set DEVENV_EXE_LATEST to the path of the VS 2005 devenv.exe will run
    4. Add a registry entry to the registry table that sets a value like the following:
      HKEY_CLASSES_ROOT\<your extension>\Shell\Open\Command = "[DEVENV_EXE_LATEST]" "%1"

    This algorithm is a bit complicated to explain in words and purely in Windows Installer constructs, so once I get the details worked out and tested for my scenario, I will write a follow-up blog with example WiX syntax that can be used to implement this type of logic in an MSI.

  • Aaron Stebner's WebLog

    Mailbag: How can I install a file to the GAC and the local file system using WiX syntax?

    • 1 Comments

    Question:

    I am creating an MSI-based setup using WiX.  One of the files that I am installing is authored like this:

    <DirectoryRef Id="MyDirectory">
        <Component Id="MyComponent" Guid="PUT-GUID-HERE" DiskId="1">
            <File Id="MyAssembly" Name="MyAssembly.dll" Assembly=".net" KeyPath="yes" Source="MyAssembly.dll" />
        </Component>
    </DirectoryRef>

    When I create an MSI and install it, I see MyAssembly.dll gets installed to the global assembly cache (GAC), but it does not get installed to MyDirectory.

    How can I author my MSI using WiX so that it will install to both the GAC and a local directory?

    Answer:

    When you use the attribute Assembly=".net" for a file in WiX, it will create entries in the MsiAssembly and MsiAssemblyName table for this component and mark it as a GAC component.  That means that the file will only be installed to the GAC by this component, and it will not install to the directory that the component is a child of.  That directory will only be used by Windows Installer to stage a copy of that file when creating and administrative install point.

    If you need to install the file to both the GAC and the local file system, you will need to author a second component that contains another copy of this file and make sure to not include Assembly=".net" in that second component.

    Heath Stewart has posted some sample WiX syntax in this blog post that can be used as a guide for authoring components to install a file to both the GAC and the local file system.  I want to call out a couple of key points about this scenario:

    • Normally, if you need to install the same files to multiple locations, you could use the DuplicateFile table.  However, as I briefly described in this blog post, Windows Installer does not support using the DuplicateFile table to install a file to both the GAC and the local file system, so that necessitates creating a 2nd component in this scenario.
    • In order to avoid ICE30 errors in your MSI, you need to make sure that the component that installs the file to the GAC is a child of a different directory than the component that installs the file to the local file system.  The directory for the GAC component will only be used by Windows Installer to stage a copy of that file when creating and administrative install point, so it does not really matter what it is named as long as it is different than the directory that the other copy of this file is installed to.
    • Ordinarily, having two components that install the same file would result in your package containing two copies of this file (which therefore increases your installer's size).  However, in recent builds of WiX 3.0, the new "smart cabbing" feature (described in this post on Rob Mensching's blog) will automatically fix up the cab file to only contain one physical copy of the file to eliminate this size issue.
  • Aaron Stebner's WebLog

    My thoughts about using WiX and RegisterMceApp in Media Center application setups

    • 3 Comments

    As part of his series about creating a Windows Vista Media Center application, Steven Harding recently posted an item on his blog describing how to create an installer for a Media Center application.  In this post, Steven walks through the process of determining what registry entries need to be created under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Media Center\Extensibility, and then adding those registry values to a Visual Studio setup/deployment project.

    Charlie Owen posted an item on the Media Center Sandbox blog afterwards that is essentially a response to Steven's blog post.  Charlie outlines why the preferred approach for Media Center application developers is to use the RegisterMceApp utility or the RegisterApplication API within setup, and also why the samples in the SDK demonstrate how to use WiX (as opposed to the Visual Studio setup/deployment projects) to create a Media Center application setup.

    I've heard questions come up fairly often on the Sandbox forum, comments on my blog and elsewhere regarding deployment options for Media Center applications, and after these 2 posts, I wanted to add a couple of comments of my own on the topic of how to register an application in a setup package so it will appear in the Media Center UI.

    Options for registering a Media Center application

    First, as seen in these blog posts, there are several options for registering a Media Center application within an MSI-based setup:

    1. Create the necessary registry values directly as documented in the Writing Registry Keys Directly topic in the Media Center SDK
    2. Run RegisterMceApp as a custom action during your setup
    3. Write a custom action DLL that calls RegisterApplication (this is what was shipped in older versions of the Media Center SDK but discontinued in Windows Vista Media Center)

    How to register a Media Center application in a Visual Studio setup project

    If you are using Visual Studio setup/deployment projects, you will find that they do not support adding custom actions that invoke binaries not installed as part of your product.  Therefore, option 2 is out (unless you know how to write scripts that invoke Windows Installer APIs to modify the MSI file after it is built as a post-build step in Visual Studio).  Option 3 is fairly complicated and requires fairly in-depth knowledge about Windows Installer to get correct, so that tends to lead people to option 1.

    Charlie covered this already, and I also touched on this a while back in this blog post, but I want to reiterate it again here - if you choose to write the registry values directly, you will need to ship separate MSIs for 32-bit OS's and 64-bit OS's or else your installer will not work correctly on 64-bit OS's.  Not a ton of people have 64-bit OS's right now, but that number is only going to grow, and people are not happy when they cannot get an application to install and run correctly out of the box on their 64-bit OS.

    WiX as an alternative to Visual Studio setup projects

    When I first started looking at the steps required to create a Media Center application installer (in a series of blog posts starting with this one a while ago), I wanted to find a solution that would allow me to run RegisterMceApp directly because that file already exists on Media Center systems and it didn't make sense to me to not use it if it is already there.  Because I have several years of background in Windows Installer, I naturally gravitated towards WiX as I started investigating options further because it allowed me to use declarative XML to express what I wanted my MSI to do.

    There is definitely a learning curve for WiX that does not exist in graphical tools like the Visual Studio setup/deployment projects.  However, that learning curve does help you better understand exactly what you are doing to the user's system in your installer, which I think allows you to design and build better installers.

    In addition, the learning curve is somewhat mitigated because most Media Center application setups are fairly small and simple (I outlined the actions taken in most of these setups in this blog post).  That means that once you have a template that runs the correct custom actions, checks the correct prerequisites, etc, you can fairly easily swap in your payload files and build your own MSI.  That is the model I was aiming for with the sample setup files for the Q and Z applications in the Media Center SDK - both of them include fully commented WiX source (WXS) files that explain what each action does to help guide you in the right direction for creating your own setups in WiX.

    I recognize now that the Q and Z examples are overly complicated for folks just getting started, which is why I'm glad to see that Charlie has posted some step-by-step instructions to make it easier to get started with this process.  I'm also working with him on some ideas to make getting started with WiX for Media Center applications even easier in the future.

    Why I use WiX for creating Media Center application setups

    Stepping up a level and comparing Visual Studio setup projects and WiX side-by-side for the task of building Media Center application installers, I personally choose to use WiX and when people ask me why, I always mention the following reasons:

    1. I am able to call RegisterMceApp directly, which keeps me from having to ship separate 32-bit and 64-bit MSIs and is less error prone because I don't have to manually author all of the necessary registry values into my MSI
    2. In most cases, I can copy and paste the WiX source code from the step-by-step guide, change some variable names and GUIDs, change the names of files being installed and be ready to go very quickly
    3. I can use VB Express or C# Express for my entire Media Center development project if I want to, whereas the setup projects are only available in VS standard and higher
    4. I can build everything outside of Visual Studio if I choose to whereas the VS setup projects do not support running via MSBuild
    5. The MSIs that WiX creates are much cleaner, smaller, and serviceable if I have to release patches; VS inserts a lot of additional information into the MSI that I would prefer to not have and that is not technically required to complete the installation process
    6. I have better control over what is put into the MSI, whereas VS only exposes a small subset of Windows Installer functionality in the designer UI

    I know that WiX isn't for everyone though, but I encourage you to take a look and consider it as an option when building an MSI-based installer for your Media Center application.  If you decide to try WiX and run into questions, I have posted a list of useful resources that I often refer to in this blog post.

  • Aaron Stebner's WebLog

    Try Windows Vista and Visual Studio 2005 on a virtual hard drive

    • 2 Comments

    Recently, I read an article about trial versions of Windows Vista, Windows Server 2003 R2 and Visual Studio 2005 that have been released as virtual hard drive (VHD) images.  If you have a program like Virtual PC, you can download and run these VHDs without needing to configure a new test machine or worry that they will affect your existing OS or applications.

    You can download these trial versions at the following locations:

    These VHDs remind me of my early days at Microsoft.  When we were working on some of the editions of Visual Studio .NET 2002, we used to joke that the product was so big that we should just pre-install VS and all of the server applications on hard drives and ship those to users instead of CDs/DVDs.  Virtualization technology has come a long way since then, and now something we used to joke about is sort of a reality.

  • Aaron Stebner's WebLog

    New Windows Vista Media Center mail, RSS and videophone applications from OABSoftware

    • 2 Comments

    I recently noticed a few posts on the Green Button forums announcing some new and updated Windows Vista Media Center applications from OABSoftware.  I wanted to post some information about them in case you didn't see those forum posts.  This information is summarized from the product information pages for each product and the forum posts.

    Media Center Outlook 1.0

    Media Center Outlook is a new application for Windows Vista Media Center.  It allows you to read email, view your calendar and task list, view information about your contacts, read your notes.  It retrieves this information from Microsoft Outlook and displays it within Windows Vista Media Center.

    One important note - Media Center Outlook cannot be used on a Media Center extender because it is not possible to configure Microsoft Outlook for the user account that is used by the extender.

    You can view more details about Media Center Outlook at the following locations:

    Media Center Mail 2.1

    Media Center Mail 2.1 is an updated version that supports Windows Vista Media Center.  It allows you to read your email within Windows Vista Media Center.  It comes with its own system for receiving email from POP3 servers.  In version 2.1, it is now possible to use Media Center Mail on a Media Center extender.

    You can view more details about Media Center Mail at the following locations:

    Media Center RSS Reader 2.1

    Media Center RSS Reader is an updated version that supports Windows Vista Media Center.  It allows you to view items from RSS feeds (such as text-based news feeds, podcasts and video-blogs) within Windows Vista Media Center.  Media Center RSS Reader uses the same RSS feed store as Internet Explorer 7.  In version 2.1, it is now possible to use Media Center RSS Reader on a Media Center Extender.

    You can view more details about Media Center RSS Reader at the following locations:

    Media Center Video Phone 2.1

    Media Center Video Phone is an updated version that supports Windows Vista Media Center.  It allows you to have video conversations within Windows Vista Media Center.  You can start conversations and answer incoming calls from others.  Media Center Video Phone for Windows Vista makes use of the standard SIP (session initiation) protocol.

    Key changes in version 2.1 include the following:

    • Integration with the Media Center Outlook plug-in
    • Support for extensions
    • It comes with an extension for Yealink USB phones.  This extension lets you initiate and answer calls for Media Center Video Phone using a Yealink USB phone.

    One important note - Media Center Video Phone cannot be used on a Media Center extender.

    You can view more details about Media Center Video Phone at the following locations:

  • Aaron Stebner's WebLog

    Update Rollup 2 setup can fail because it does not detect the .NET Framework 1.1 SP1

    • 9 Comments

    It has been a while since I've written about any setup issues related to Update Rollup 2 for Media Center 2005.  The lack of posts has been caused by several things:

    • Most (if not all) systems that ship with XP Media Center pre-installed now also include Update Rollup 2, so there isn't a need for most people to download and install it directly
    • Many people have started using Windows Vista Media Center
    • The issues I've run into that have prevented Update Rollup 2 installation from succeeding have all been similar to ones that I've documented in my Update Rollup 2 troubleshooting guide

    This week, I ran into an Update Rollup 2 installation issue that is related to the .NET Framework 1.1 that I hadn't seen before, so I wanted to describe it here in case anyone else sees it.  Also, since the underlying problem is in the .NET Framework 1.1, it could potentially affect other programs, and not just Update Rollup 2.

    Diagnosing the issue

    In the case I saw this week, a customer ran Update Rollup 2 setup and it installed all of the prerequisite Windows hotfixes, but then failed when trying to install the main Update Rollup 2 package (KB900325).  I looked at the log file named %windir%\kb900325.log from this system and I saw the following:

    0.187: Exec PreReq.SingleOp.OneDotOneSP1Framework:  Types don't match of Key SOFTWARE\Microsoft\NET Framework Setup\NDP\v1.1.4322

    Update Rollup 2 setup requires that you have the .NET Framework 1.1 and 1.1 SP1 installed, so I first verified using Windows Installer tools that 1.1 and 1.1 SP1 were correctly installed.  However, as seen in this log file, the Update Rollup 2 setup itself was not able to detect 1.1 SP1 because of a problem with the data type for a registry value.

    How to workaround this issue

    To resolve this issue, I had the customer fix the incorrect registry value that was causing KB900325 setup to think that 1.1 SP1 was not installed.  The fix required the following steps:

    1. Click on the Start menu, choose Run, type cmd and click OK
    2. Type this command:  reg delete "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v1.1.4322" /v SP /f
    3. Type this command: reg add "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v1.1.4322" /v SP /t REG_DWORD /d 1 /f
    4. Re-run Update Rollup 2 setup

    Root cause of the issue

    The interesting thing about this issue is that the wrapper setup.exe (which chains the prerequisites together with Update Rollup 2) and the KB900325 package both perform a check for both 1.1 and 1.1 SP1.  In this scenario, the wrapper was able to correctly detect that 1.1 SP1 is installed.  However, the logic inside of the KB900325 setup package was not able to detect 1.1 SP1.

    Both the wrapper setup and the KB900325 setup use the following registry value to detect the presence of the .NET Framework 1.1 SP1 (as I've previously described and written sample code for in this post):

    [HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v1.1.4322]
    SP=1

    The one difference is that the KB900325 setup requires this value to be a REG_DWORD, while the wrapper setup will work if the value is a REG_DWORD or a REG_SZ.

    Technically, the .NET Framework setup only writes this value as a REG_DWORD, so that should be the only form that this value should be in on a system.  However, I have seen a few cases where this value was somehow deleted and re-created as a REG_SZ value by some other application.  The difference in registry data type can affect detection depending on how the registry value is being retrieved and parsed.

    If you end up seeing any cases where an application tells you that you do not have the .NET Framework 1.1 SP1 installed but you really do, I suggest checking to see what data type this SP value is stored as in your registry and if it is not currently a REG_DWORD, use the steps listed above to change it it to a REG_DWORD value.

  • Aaron Stebner's WebLog

    Possible cause of 1935 error with HRESULT 0x8002802F

    • 25 Comments

    A while back, I posted an article describing causes of many types of 1935 errors that have been seen in the past.  I wanted to talk about one specific type of 1935 error in a little more detail and provide information about a possible root cause that I did not describe in that previous article.

    A 1935 error in an MSI-based installations code is a catch-all for most of the possible assembly installation errors. In order to diagnose the problem in more detail, it is usually necessary to look at the verbose MSI log file.  In some cases, you will see an error like the following:

    Error 1935. An error occurred during the installation of assembly '<myAssembly>'. Please refer to Help and Support for more information. HRESULT: 0x8002802F. assembly interface: , function: CreateAssemblyNameObject, component: {A7A9D92E-C67F-4E96-BB90-5A4147DAEF6B}

    The key information needed to diagnose the exact root cause of a 1935 error is usually the HRESULT value listed in the verbose MSI log file.

    The HRESULT value listed above is 0x8002802F (-2147319761), and it means "function not defined in specified DLL." There are a few possible root causes of this issue. The most common cause is that the file %windir%\system32\mscoree.dll is missing, corrupt or an incorrect version. In most cases, repairing the highest version of the .NET Framework on the system will correct any problems related to mscoree.dll and will resolve the problem if this is the case.

    In a few less common cases, the file %windir%\system32\mscoree.dll is present, but registry values used by the .NET Framework to find and load specific versions of the .NET Framework are missing. The following values are required by mscoree.dll in order to load each version of the .NET Framework:

    For the .NET Framework 2.0 (on an x86 version of Windows):

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
    InstallRoot = C:\Windows\Microsoft.NET\Framework\

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Policy\Upgrades]
    2.0.50727 = 1.0.0-2.0.50727

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Policy\v2.0]
    50727 = 50727-50727

    For the .NET Framework 2.0 (on an x64 version of Windows):

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
    InstallRoot = C:\Windows\Microsoft.NET\Framework64\

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Policy\Upgrades]
    2.0.50727 = 1.0.0-2.0.50727

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Policy\v2.0]
    50727 = 50727-50727

    [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework]
    InstallRoot = C:\Windows\Microsoft.NET\Framework\

    [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432NodeMicrosoft\.NETFramework\Policy\Upgrades]
    2.0.50727 = 1.0.0-2.0.50727

    [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\Policy\v2.0]
    50727 = 50727-50727

    For the .NET Framework 1.1:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
    InstallRoot = C:\Windows\Microsoft.NET\Framework\

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Policy\Upgrades]
    1.1.4322 = 1.0.0.0 - 1.1.4322

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Policy\v1.1]
    4322 = 3706-4322

    For the .NET Framework 1.0:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
    InstallRoot = C:\Windows\Microsoft.NET\Framework\

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Policy\v1.0]
    3705 = 3321-3705

    If any of the above registry values are missing on your system, you will need to manually add them in order to resolve 1935 errors with HRESULT value 0x8002802F.  Note that the InstallRoot value must be set to the exact location of the %windir% folder on your system, so you may need to adjust that value from the one listed above if your %windir% is not located at c:\Windows.

    <update date="2/4/2008"> One of the values for the .NET Framework 1.0 was incorrect, so I fixed it </update>

    <update date="12/16/2009"> Added 64-bit registry information for the .NET Framework 2.0. </update>

     

  • Aaron Stebner's WebLog

    New Windows Vista Media Center applications - Yougle 2 and EMUCenter

    • 0 Comments

    Steven Harding posted an item on his blog at http://thedigitallifestyle.com/cs/blogs/developer/archive/2007/06/11/emucenter-is-out-now.aspx that announces 2 new Windows Vista Media Center applications that he has been working on:

    Yougle

    This application lets you watch videos from YouTube from within Windows Vista Media Center.

    For more information about Yougle for Windows Vista Media Center and to download the beta and try it out on your Windows Vista Media Center system, check out the link at http://www.push-a-button.com.au/products/mce/vista/yougle2/index.php.

    EMUCenter

    This application lets you launch your favorite current and classic video games from within Windows Vista Media Center

    For more information about EMUCenter, including screenshots, forum discussion and a link to download a beta version, check out the following links:

  • Aaron Stebner's WebLog

    Introduction to Big Screen Movies application for Windows Vista Media Center

    • 0 Comments

    Niall Ginsbourg is at it again.  A while ago, he introduced an application called Big Screen TV Series that he has been working on (in blog posts here and here).  Today, he posted some information about another new application called Big Screen Movies, which he has codenamed "FatLady."

    The first post, located at http://mobilewares.spaces.live.com/Blog/cns!78533A1A2E078194!466.entry, provides the following information:

    • A couple of screenshots of an early version of the UI
    • A chart describing the features of the application, which is designed as a replacement for the DVD Library included in Windows Vista Media Center
    • Some questions and answers about the Big Screen Movies application
    • An explanation about what has been happening with Big Screen TV Series, including some legal issues that have thusfar prevented him from releasing this application

    The second post, located at http://mobilewares.spaces.live.com/Blog/cns!78533A1A2E078194!470.entry is a behind the scenes look at how Big Screen Movies works, including the following topics:

    • What metadata and images Big Screen Movies will work with and look for
    • Offline and online movie support
    • Big Screen Movies manager/editor application (a standalone application that runs outside of Media Center)

    I've used most of Niall's other Big Screen applications, and based on that experience and the information in these posts, I'm really looking forward to trying out Big Screen Movies as soon as Niall makes something publicly available.  I encourage you to check out these blog posts for more information about this application as well.

  • Aaron Stebner's WebLog

    Update on how to deploy the .NET Framework 3.0 on Windows XP Embedded

    • 17 Comments

    Earlier this week, I posted an item with a link to an article on the Windows Embedded team's blog that provides step-by-step instructions to create a Windows XP Embedded runtime image that you can install the .NET Framework 3.0 on.

    Today, I noticed this post on Mike Hall's blog that includes download links for a package that enables installation of the .NET Framework 3.0 on Windows XP Embedded images without requiring all of the manual steps in that previous step-by-step guide.

    If you are an embedded developer or image builder who wants to include the .NET Framework 3.0 in your runtime images, I encourage you to check out Mike's post and the links that it includes for more information.

  • Aaron Stebner's WebLog

    Link to information about MSI script-based custom action error codes 2738 and 2739

    • 25 Comments

    Heath Stewart posted an item on his blog this past week that I wanted to raise awareness about.  In the post, located at http://blogs.msdn.com/heaths/archive/2007/05/31/windows-installer-errors-2738-and-2739-with-script-custom-actions.aspx, Heath described some potential issues and workarounds for script-based custom action failures in MSI-based setups.

    These error codes appear in an MSI log file when a script-based custom action fails to run correctly, and the error messages look like the following:

    • 2738, Could not access VBScript run time for custom action [2].
    • 2739, Could not access JScript run time for custom action [2].

    A common resolution for this type of error is to re-register the file %windir%\system32\vbscript.dll and/or %windir%\system32\jscript.dll.  However, on Windows Vista this can present problems because if you attempt to re-register these DLLs from a normal user cmd prompt, the registration will be written to HKEY_CURRENT_USER instead of HKEY_CURRENT_MACHINE.

    A key point Heath makes in his blog post that I was not aware of before reading it is that Windows Installer will not load and use scripting engines if they are registered in HKEY_CURRENT_USER (for security reasons that he described in more detail in his post).  Therefore, if you have registered the DLLs on Windows Vista from a normal user cmd prompt, that will not help fix this type of error.

    If you have these scripting engines registered under HKEY_CURRENT_USER, you need to make sure that you remove that registration and re-register them under HKEY_LOCAL_MACHINE.  You can use the following steps to unregister them from HKEY_CURRENT_USER:

    1. Click on the Start menu, choose Run, type cmd and click OK
    2. To unregister the VBScript engine, run this command:  reg delete "HKCU\SOFTWARE\Classes\CLSID\{B54F3741-5B07-11CF-A4B0-00AA004A55E8}" /f
    3. To unregister the VBScript engine on a 64-bit OS, run this command:  reg delete "HKCU\SOFTWARE\Classes\Wow6432Node\CLSID\{B54F3741-5B07-11CF-A4B0-00AA004A55E8}" /f
    4. To unregister the JScript engine, run this command: reg delete "HKCU\SOFTWARE\Classes\CLSID\{F414C260-6AC0-11CF-B6D1-00AA00BBBB58}" /f
    5. To unregister the JScript engine on a 64-bit OS, run this command: reg delete "HKCU\SOFTWARE\Classes\Wow6432Node\CLSID\{F414C260-6AC0-11CF-B6D1-00AA00BBBB58}" /f

    One last note - if you are a setup developer reading this post, I encourage you to read this post by Rob Mensching where he explains reasons why using script-based custom actions in an MSI can lead to bad results and should be avoided if at all possible.

    <update date="7/29/2009"> Added steps to unregister the VBScript and JScript engines on 64-bit OS's. </update>

     

  • Aaron Stebner's WebLog

    Problem deploying the RGB Rasterizer MSI in the .NET Framework 3.0 via Active Directory

    • 3 Comments

    Recently, I've heard from a couple of customers who have been trying to use the Microsoft .NET Framework 3.0 Administrator Deployment Guide to deploy the .NET Framework 3.0 to their network using Active Directory.  They have run into problems deploying the RGB Rasterizer prerequisite component (officially known as the Software rasterizer for the Microsoft DirectX 9.0 Software Development Kit (SDK) in this deployment guide).

    Description of the issue

    One of the customers posted a description of this problem in this post on the MSDN forums.  To summarize, using the instructions in the deployment guide yields a fatal error during the deployed installation of the RGB Rasterizer MSI.  However, it doesn't appear that a verbose MSI log file is created during this deployment.

    The RGB Rasterizer is a very simple MSI with the following characteristics:

    • It only installs on Windows XP
    • It installs a single file to the %windir%\system32 directory
    • The component that installs the file is marked as permanent so it cannot be uninstalled using standard MSI actions
    • The MSI itself is marked so it will not appear in Add/Remove Programs - this means that the user will not have an option to uninstall this package and will likely not even know it is installed on their system

    Workaround for the issue

    I have not yet been able to determine the exact root cause of this Active Directory deployment error for this MSI.  However, because of the simple nature of the MSI, it is possible to workaround this issue by creating an administrative install point for the RGB Rasterizer MSI using the instructions in the appendix at the end of the deployment guide, then directly deploy the one file included in the MSI to any Windows XP systems that are on your network.

  • Aaron Stebner's WebLog

    How to deploy the .NET Framework 3.0 on Windows XP Embedded

    • 4 Comments

    I ran across a question on the .NET Framework setup forum today about installing the .NET Framework 3.0 on a Windows XP Embedded runtime image.  Fortunately, Andy alerted me to a post on the Windows Embedded team blog that describes the following:

    • How to configure an XPe runtime so that the .NET Framework 3.0 will be able to install on it (what dependencies are needed, how to deploy the runtime image)
    • How to deploy the .NET Framework 3.0 on XPe
    • How to deploy .NET Framework 3.0 language packs on XPe
    • How to deploy .NET Framework 3.0 applications on XPe

    You can find this blog post at http://blogs.msdn.com/embedded/archive/2007/03/23/deploying-net-framework-3-0-desktop-distribution-package-on-windows-xp-embedded-sp2-runtime.aspx.

    If you are a Windows Embedded developer and plan to develop .NET Framework 3.0 applications for you Windows XP Embedded runtimes, I encourage you to take a look at this blog post.

  • Aaron Stebner's WebLog

    Updated betas of Big Screen Headlines and Big Screen Contacts available for download

    • 0 Comments

    Niall Ginsbourg posted an item on his blog this weekend where he announces the availability of updated beta versions of Big Screen Headlines (a Media Center RSS feed viewer) and Big Screen Contacts (a Media Center Windows contact viewer/manager).  As he noted, these new beta versions do not have any significant changes, but the beta expiration date has been extended to August 1, 2007.  If you have been using Big Screen Headlines and/or Big Screen Contacts, you will need to download the updated versions in order to continue using them.

  • Aaron Stebner's WebLog

    Web Designer Tools can fail to install during VS Orcas beta 1 setup on 64-bit Windows

    • 3 Comments

    When Visual Studio Codename Orcas beta 1 was initially released back in April, I posted this item about a possible failure during the installation of the Microsoft Web Designer Tools prerequisite component.  That failure was caused by a leftover beta version of Microsoft Office 2007 that was still installed on the system.  Since then, I have heard from a couple of other customers who have run into failures during the installation of the Web Designer Tools component, but who did not have any beta versions of Office 2007 on their system.

    Description of the problem

    Thanks to the Office setup team here at Microsoft, we were able to track down one of the possible root causes.  The Office 2007 setup engine (which is what the Web Designer Tools component uses behind the scenes) shipped with a known compatibility issue on the 64-bit version of Windows Server 2003.  If you attempt to install a product that uses the Office 2007 setup engine on a 64-bit Windows Server 2003 system with Terminal Services installed and configured in relaxed security mode, the setup may fail.

    How to diagnose the problem

    In this type of scenario, the log file for Web Designer Tools package, which is located at %temp%SetupExe(########).log, shows an error like the following:

    Loaded Dll : c:\1bfe3344c2af996d3f660b\visualwebdeveloper.ww\OSETUP.DLL.
    Catalyst version is : 12.0.4518.1014
    JobExecutionMode is InstallExecutionMode.
    Error: failed MsiEnumProducts ErrorCode: 2(0x2).
    Catalyst execution finished: 05/01/2007 12:34:56. Return code: 30015. Exception caught: ErrorCodeOnly.

    How to workaround the problem

    The Office team has published a knowledge base article at http://support.microsoft.com/kb/927476/en-us that describes how to workaround this issue.  This knowledge base article describes how to enable full security mode for Terminal Services on Windows Server 2003.  It also lists an alternate registry-based workaround that can be used in case the Terminal Services security mode cannot be changed on your system for some reason.

  • Aaron Stebner's WebLog

    Link to information about smart cabbing feature in WiX v3.0

    • 2 Comments

    Rob Mensching posted an item on his blog last night that I wanted to bring to your attention.  Recently, he implemented a feature in WiX v3.0 to potentially reduce the size of the cab files produced during the WiX build process.  With this feature, if your MSI contains multiple copies of the same file, WiX will optimize the cab so that it only includes one physical copy of the file, but the MSI can still install multiple copies of it (even if they have different file names).

    Normally, an MSI can be authored to use the DuplicateFile table to avoid needing to carry multiple copies of the same file.  However, as Rob alluded to in his blog post and as I previously described in this blog post, it is not possible in Windows Installer to use the DuplicateFile table when the file being duplicated is installed to the global assembly cache (GAC).

    This is the scenario that we have run into when building setups for the .NET Framework and Visual Studio because both of these products install assemblies into the GAC for runtime scenarios and to the local file system for design time scenarios.  An earlier version of the smart cabbing feature allowed us to reduce the size of cabs included in some of the versions of Visual Studio and the .NET Framework using similar logic, but that logic was hard-coded into the Visual Studio build process.  Fortunately, it is now able to be used more widely as a part of WiX v3.0.

    If you are using WiX v3.0, you do not need to do anything special to enable the smart cabbing feature - just download and install the most recent build of WiX v3.0 from the releases page.  If you are not yet using WiX v3.0 and have scenarios where you need to install the same file to multiple locations but you cannot use the DuplicateFile table, then I encourage you to check out the WiX v3.0 smart cabbing feature as a possible solution to reduce your package size.

    <update date="6/2/2007"> Fixed link to the WiX v3.0 releases page </update>

     

Page 1 of 1 (19 items)