As with all software installations, there are times when WindowsEmbeddedCompact7.exe cannot complete the install successfully. Great effort has been made prevent the installation from failing. Sometimes the installation requires other software to be installed first. In the case of Platform Builder, Visual Studio 2008 and Visual Studio 2008 SP1 are the prerequisites. Windows Embedded Compact 7 will search for the prerequisites when it starts. This is part of the action taken while the Splash screen is displayed. ( as a side note, the Splash screen can be moved to show the program has not locked up.)

So what happens if the prerequisites are not found?

You, the user, will see Red X’s next to options that require prerequisites to be meet.

RTM display.

With the updated software, a message is displayed explaining what prerequisites are required.

So why is Shared Source greyed out with a red X next to it when all the prerequisites are installed?

Evaluation copies of the software do not come with Shared Source. But you can access more information about Shared Source right from the link the description field.

If you are still having trouble with WindowsEmbeddedCompact7.exe, you can either reach out help, or investigate the issue yourself. For both options you will need to access the log files that the software creates. These log files are in the user profile temp folder, of the user who ran the software. The easiest way to get to that folder is to click on Start and Select Run.

In the text window type %temp%, click Ok.

That will open your temp folder and you should see the log files listed.

All four of log files shown were created by the software. When some prerequisites are not found, an entry like the highlighted one here will explain why you are having a problem.

The snippet above is an entry showing that Visual Studios 2008 could not be found on the computer.

When Visual Studios 2008 is found at the proper version, an entry like this can be found in the log.

If you are having issues, I hope this helps explain how to trouble shoot it. In our efforts, we have attempted to prevent as many issues as we can, and present as much information as possible when the issue can not be prevented. Let me know how we are doing.

Blog Entry

https://krakllc.wordpress.com/2011/07/25/updating-windows-embedded-compact-7/

Here are a couple ways you could help me out.

Our installer, the engine, writes all the logs to the user’s profile temporary directory. Typically this would be the environment variable %temp%. In the instance of WindowsEmbeddedCompact7.exe and WindowsEmbeddedSilverlightTools.exe, we create log files which remove the .exe and add .nnnn.log. So the full string would look something like WindowsEmbeddedCompact7.0001.log.

If you are familiar with Windows API calls and error codes, you should be able to scan the logs and find errors and issues that will help you address the problem you are seeing. If you aren’t familiar with the above, please feel free contact me through this blog by sending me a direct email and I will try to help you directly.

One item I've already found involves the physical product discs. In Compact 7 we introduced a new feature called the Windows Embedded Developer Update. The developer update functionality is installed as a Visual Studio add-in during the Compact 7 installation. We have noticed an irregular occurrence that, after the Compact 7 installation has completed and within the same user session (i.e., the user hasn't logged off or rebooted since completing the install) when starting Visual Studio, users may see a Windows dialog saying, “There is no disk in drive. Please insert a disk into drive D.” This occurs when the Windows Embedded Developer Update checks for an update on-line. So far, we've only been able to reproduce this when the user has removed the disc from the drive and hasn't yet rebooted or logged off after completing the install.

The root issue is straightforward. Windows is simply looking for a disk to be in your CD/DVD drive. This prompt can be dismissed by placing any disc in the drive. It does not need to be the Compact 7 installer disc. We're fixing this right now so that the operating system won't look for a disc in the drive when starting the Windows Embedded Developer Update. We are running the fix through an extended test cycle. If you experience this, please do write me (via this blog) so I can learn more about how it occurred on your system and provide assistance as needed.

Here are three simple workarounds: Either click the continue button 41 times (once for each MSI in Compact 7) or put any disc at all into your disc drive or log off and then log back into the user account. Any of these will dismiss the message and allow for the Windows Embedded Developer Update to continue checking online for new updates.

I will update this post as soon as we release this fix to the field. Your comments and feedback are most welcome.

During this time I worked closely with the Windows Installer XML (WiX) Toolset Community to ensure that the installation I was to build would make it more than a couple of months out the door! I spoke with many of the members of the community and used some of the early forms of the Burn project to make it to this point. The architecture allowed us to create, what I affectionately call, the business layer to drive the Burn engine.

If you have installed or will install the new Windows Embedded Compact 7 Public CTP I am interested in knowing how your installation experience went!

Help me help you!

Architecture

The first point to know about Heat would be around the architecture. The entire engine is written to be extensible. The core, which contains one harvester, has its extension set during the command line switch parsing.

Heat loads all the extensions from the heat.exe.config file and then parses the command line for additional extensions. Each extension is passed the command line switches that were given to Heat so they can determine if they should become the active harvestor extension.

Getting Started

The examples I will be using are going to be via C#. Create your new extension project using the language of your choice. This should be a Class Library project. I have decided to use the .NET 2.0 Framework to keep in line with the Windows Installer XML Toolset (WiX) and to keep from requiring a higher version of .NET on the machine (this is your choice however).

Setting Up The Project

Now that you have created your project you will need to add a few dependencies. The main one is to the wix.dll which can be found in the same directory as Heat.exe. If you are looking to write your own directory harvester you will want to add a reference to the WixUtilExtension.dll if you don’t want to rewrite all the work done to harvest an individual file. The FileHarvester has some great functionality around harvesting self-registering files.

Now that your project has its core dependencies added it is time to create a shell class that will become your harvester extension. For my example I will be calling my extension "MyCustomExtension".

namespace MyHeatExtension
{
    using System;
    using System.Collections.Generic;

    using Microsoft.Tools.WindowsInstallerXml.Tools;

    public class MyCustomExtension : HeatExtension
    {
    }
}

Next you will need to add a reference to your extension in the AssemblyInfo.cs file. This helps the extension loader to find out which class in your Assembly should be treated as your harvester.

using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;

using MyHeatExtension;
using Microsoft.Tools.WindowsInstallerXml.Tools;

[assembly: AssemblyTitle("MyCustomExtension Heat Extension")]
[assembly: AssemblyDescription("This is an extension to heat.exe which is part of the WIX Toolset.")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("MyCompany")]
[assembly: AssemblyProduct("MyHeatExtension")]
[assembly: AssemblyCopyright("Copyright © MyCompany 2009")]
[assembly: AssemblyCulture("en-us")]
[assembly: AssemblyVersion("0.5.0.0")]
[assembly: AssemblyFileVersion("0.5.0.0")]

[assembly: ComVisible(false)]

[assembly: AssemblyDefaultHeatExtension(typeof(MyCustomExtension))]

Overrides

At this point I like to do a build on the project to make sure everything is working as expected. Once your compile has worked and your assembly built it is time to start coding. Going back to class diagram and looking at the HeatExtension class there are a couple exposed properties and methods. Two of these are pinnacle to our successful create of the extension; CommandLineTypes and ParseOptions.

CommandLineTypes

/// <SUMMARY>
/// Gets the supported command line types for this extension.
/// </SUMMARY>
/// <VALUE>The supported command line types for this extension.</VALUE>
public override HeatCommandLineOption[] CommandLineTypes
{
    get
    {
        return new HeatCommandLineOption[]
        {
            new HeatCommandLineOption("mydirext", "harvest a directory my way")
        };
    }
}

ParseOptions

/// <SUMMARY>
/// Parse the command line options for this extension.
/// </SUMMARY>
/// <PARAM name="type">The active harvester type.</PARAM>
/// <PARAM name="args">The option arguments.</PARAM>
public override void ParseOptions(string type, string[] args)
{
    bool activated = false;

    if (String.Equals(type, "mydirext", StringComparison.OrdinalIgnoreCase))
    {
        this.Core.Harvester.Extension = new MyHarvesterExtension();
        activated = true;
    }

    if (activated)
    {
        //TODO: Parse the command line if needed and add mutators if needed.
    }
}

Summary

You are now at the point to start diving in and looking into what it takes to actually make your HarvesterExtension and MutatorExtension if you need it. As my schedule allows I plan on adding other parts to this to help in the creation of a HarvesterExtension and MutatorExtension. I realize that much of this is undocumented so I hope that you find these blogs of use.

As always, comments and feedback welcome.

MyHeatExtension.zip

const UINT COST_BINARY_READ_TRANSACTION = 10000;
//Extract the Binary Id to a memory stream as an immediate custom action.
//
__declspec(dllexport)
UINT __stdcall GetMyBinaryData(MSIHANDLE hInstall)
{
    HRESULT hr = S_OK;
    UINT er = ERROR_SUCCESS;
    LPWSTR pwzStreamToString = NULL;
    BYTE* pbData = NULL;
    DWORD cbData = 0;

    hr = WcaInitialize(hInstall, "GetMyBinaryData");
    ExitOnFailure(hr, "failed to initialize GetMyBinaryData");

    //Extact the Id in the Binary table to a stream.
    hr = 
ExtractBinary
(L"MyBinaryTableId", &pbData, &cbData);
    ExitOnFailure(hr, "failed to extract binary data");

    //Write the stream to a string to be passed as CustomActionData
    hr = 
WcaWriteStreamToCaData
(pbData, cbData, &pwzStreamToString);
    ExitOnFailure(hr, "failed to write the stream to a string");

    hr = WcaDoDeferredAction(L"IAlwaysCodeForRollbackToHandleFailures", L"Rollback", 0);
    ExitOnFailure(hr, "Failed to schedule IAlwaysCodeForRollbackToHandleFailures");

    //Send it over to a deferred custom action if you need to do "special" things with it
    hr = 
WcaDoDeferredAction(L"IAmUsingThisAsAMemoryStream", pwzStreamToString, COST_BINARY_READ_TRANSACTION)
;
    ExitOnFailure(hr, "Failed to schedule IAmUsingThisAsAMemoryStream");

LExit:
    ReleaseStr(pwzStreamToString);
    ReleaseMem(pbData);

    if (FAILED(hr))
    {
        er = ERROR_INSTALL_FAILURE;
    }
    return WcaFinalize(er); 
}

Next, as the custom action reads, we will be opening this in a deferred action as a memory stream.

//Read the stream from the CustomActionData property.
__declspec(dllexport)
UINT __stdcall 
IAmUsingThisAsAMemoryStream
(MSIHANDLE hInstall)
{
    HRESULT hr = S_OK;
    UINT er = ERROR_SUCCESS;
    LPWSTR pwzCustomActionData = NULL;
    LPBYTE pbData = NULL;
    DWORD_PTR cbData = 0;

    hr = WcaInitialize(hInstall, "IAmUsingThisAsAMemoryStream");
    ExitOnFailure(hr, "failed to initialize IAmUsingThisAsAMemoryStream");

    hr = 
WcaGetProperty
(L"CustomActionData", &pwzCustomActionData);
    ExitOnFailure(hr, "failed to get CustomActionData");

    //Get the stream for the custom action data.
    hr = 
WcaReadStreamFromCaData
(&pwzCustomActionData, &pbData, &cbData);
    ExitOnFailure(hr, "failed to read file contents from custom action data");


LExit:
    ReleaseStr(pwzCustomActionData);
    ReleaseMem(pbData);

    if (FAILED(hr))
    {
        er = ERROR_INSTALL_FAILURE;
    }

    return WcaFinalize(er);
}

There is a quick and very dirty example on how to read from a Binary table. There are easy ways of abusing this which you, the developer, should avoid at all cost. Writing the streams to disk and leaving them there is one of the most common I have seen.

As with every new tool, once someone gets a hold of it they want it to do more. In the case I don’t disagree with them.

• Was Heat designed to help automate the creation of WiX source? Yes.
• Was the intention to have Heat gather thousands of files quickly for Setup authors? Yes.
• Is Heat ready to be placed into an automated build system and generate patch compliant MSI packages? No.

This is where I am seeing the initial pain points. Setup authors that have installations with 1,000+ files don’t want to be hand coding or manipulating the output in order to fit their needs. I, being one of those authors (200,000+ files currently), completely agree. This is why, as the current feature owner, it pains me to say that Heat is not ready for this type of primetime work straight out of the box.

There are solutions, however, that can help us large setup authors out. Before I go into details on that, take a read over a response I made to someone that asked a few of these questions.

What can be done to enable this type of requirement?

• Layout Your Build Output into Groups of Less Than 1600 Files
• I am aware that many people will not find this to be a viable options, but it would work.
• Heat could be run against these smaller grouped directories and easily handle your needs.
• This would also enable auditing of the files your company is releasing out the door.
• Why does this matter? In one company I worked for a developer on his way out of the company got upset and wanted to deface a public website with an addition of a new GIF (a Cannabis leaf). The file was named “pot.gif” but that isn’t enough to throw off any major alarms. However, because we had put in change control on what files were allowed to ship we found this through auditing.
• Write a Custom Heat Extension
• Heat, like the other tools in Windows Installer XML Toolset (WiX), can be extended.
• Writing your own Heat extension can be challenging for some but easy for others. If you are up to the task then this could be your quickest solution.
• If you take this approach, be sure to follow Component rules and all the other fun stuff that is required to remain stable.
• Wait Until Someone Else Does the Above Mentioned Possibility
• This could be the simplest but not the most quickly available.
• If your company isn’t into letting you write your own code, this would be your option.
• Wait Until WiX vNext
• The least optimal solution would be to wait until the next release of Heat.
• Rob and I have tossed around some ideas on how to improve Heat overall in order to make it a production ready build environment tool.
• When will this happen? It will be a while <grin/>

Some good news with all of this. For my day job, I am looking into doing much of this in order to get our products out the door and patchable. I would say the contribution to WixContrib will be several months off until something is ready, but it IS coming.

Some references:

• https://www.joyofsetup.com/2008/12/30/paying-for-upgrades/
• https://blogs.msdn.com/heaths/archive/2005/09/12/464047.aspx
• https://blogs.msdn.com/pmarcu/archive/2009/05/19/wix-removing-files-with-patches.aspx

Although this practice is still recommend against, this last update is a set in the direction of consistent regeneration. In Windows Installer this is a very difficult task to manage as there are many rules that a package must confirm to in order to be patch compliant. Not only must Component GUIDs remain stable, the File ID, Registry ID, Directory ID Media Number and other items must stay consistent. If this does not happen there can be serious implications to the “in-place” servicing of your product.

Several years ago I was working on a way to do what heat.exe is starting to do now, auto-generate dynamic content in a compliant way. My project, WIXML, failed to generate MSIs that were upgrade compliant. It was necessary to do a full uninstall with each new package because it broke all the rules that I mentioned above (additional information from Bob Arnson “Paying for Upgrades”). With the latest update, Heat is getting closer to the ability of being compliant with consistent re-generation.

There has been four significant command line switches added that will help users comply to the rules above.

-cg <GroupName>
-dr <DirectoryRefId>
-srd
-var

The –cg <GroupName> command instructs Heat to harvest a given directory and include all found components in a <ComponentGroup/> with the given name. This will ensure that, when authoring a full product, a developer can be guaranteed a static value to reference using a <CompnentGroupRef/>.

heat.exe dir C:\MyDir -srd -cg 
TestMe



<Wix xmlns="https://schemas.microsoft.com/wix/2006/wi">
  <Fragment>
    <ComponentGroup Id="
TestMe
">
      <Component Id="CO_BEA0A254206A075FE419AECC8F8323C3" Directory="DI_5E971BF1ECC0BC11795785D90F250FC0" ... >
        <File Id="FI_4273BB2732377498E74980308130C808" ... />
      </Component>

heat.exe dir C:\MyDir -srd -dr 
MyDir



<Wix xmlns="https://schemas.microsoft.com/wix/2006/wi">
  <DirectoryRef Id="
MyDir
">
    <Component Id="CO_BEA0A254206A075FE419AECC8F8323C3" Directory="DI_5E971BF1ECC0BC11795785D90F250FC0" ... >
      <File Id="FI_4273BB2732377498E74980308130C808" ... />
    </Component>

heat.exe dir C:\MyDir -sfrag


<Wix xmlns="https://schemas.microsoft.com/wix/2006/wi">
  <Fragment>
    <DirectoryRef Id="TARGETDIR">
      
<Directory Id="dir86787CC870C17D6ABA6D1CDCBD925324" Name="MyDir">
        <Directory Id="dirAA5EBADF0D0CC654BAD8E2CEFBF96609" Name="one">
          <Component Id="cmp51B22E187A7403EF3A8EB589174E89DC" ...>
            <File Id="filEA449989D4339EB8C7329B93F83D35FE" ... />
          </Component>
        </Directory>

heat.exe dir C:\MyDir 
-srd
 -sfrag


<Wix xmlns="https://schemas.microsoft.com/wix/2006/wi">
  <Fragment>
    <DirectoryRef Id="TARGETDIR">
      <Directory Id="dir090ACB8E8D9B8C1F26DE6E8300AA9049" Name="one">
        <Component Id="cmpE21824A6879A478E4A884BA6B00C33C9" ...>
          <File Id="filF1BA1271365EB2A130AA3F0BE83E9D6D" ... />
        </Component>
    </Directory>

heat.exe dir C:\MyDir -srd -sfrag -var 
var.MyVar



<Wix xmlns="https://schemas.microsoft.com/wix/2006/wi">
<Fragment>
  <DirectoryRef Id="TARGETDIR">
    <Directory Id="dir090ACB8E8D9B8C1F26DE6E8300AA9049" Name="one">
      <Component Id="cmpE21824A6879A478E4A884BA6B00C33C9" ...>
        <File Id="filF1BA1271365EB2A130AA3F0BE83E9D6D" Source="$(
var.MyVar
)\one\test.txt" ... />
      </Component>
    </Directory>

As mentioned in my previous blog, there was a user request to enable the Windows Installer XML Toolset (WiX) to run on FIPS enabled machines. This in itself was not a large change. In order to enable it all that needed to be done was to switch the hashing algorithms that we use from a non-compliant one (MD5) to a compliant one (SHA1). The issue came when not wanting to break backwards compatibility with users that have auto generated identifiers now and are using the generated short name feature as well. Second was to ensure that merge modules built with Windows Installer XML Toolset (WiX) and that are embedded in an MSI built with Windows Installer XML Toolset (WiX) do not break (overflow Id length) with FIPS enabled.

Below is what you can expect to see in terms of the output changing.

Registry Id Change
regCF3E4DD8E9FDD1355D6E8ECA2D7DA852
to
regFD39D952EC8973D41843396A15B57055

Short Name Change
djjnosd-.wxs
to
q9_iaha-.wxs

In addition the two static methods in src\wix\CompilerCore.cs have changed to members of that class. Please take note of this if you are using those!