light.exe : error LGHT0001 : Unable to read beyond the end of the stream.

Continuously getting this error, while compiling the Bundle project:
light.exe : error LGHT0001 : Unable to read beyond the end of the stream.

It was very annoying... and then after searching in Wix-users, came to read this post. And then I realized that either some graphics doesn't exist or corrupted. And then I've found that I copied Logo.png to Logo.ico and was referencing in my Bungle wix. 

Logo.png and Logo.ico are totally different formats and so light.exe was not able to read ico binary stream, because technically it was png binary stream..

I used GoldFish Icon Editor to convert Logo.png to Logo.ico and all went well.. :).

HeatDirectory task failure on TFS with MSBUILD error MSB4166: Child node “3” exited prematurely

Due to the project’s requirement, I had to setup Wix to generate the installer xml markup at Build Time. For this, I started using HeatDirectory task in my *.wixproj. This worked very fine while building locally (not on Team Foundation Server (TFS) ). However, it failed while building on TFS with following error log:

C:\Program Files (x86)\WiX Toolset v3.8\bin\Heat.exe dir D:\Builds\32\48\bin\Debug\InstallSrc\WebApp\ -cg CompGrp_WebApp -dr WebApp -ke -scom -sreg -srd -var var.WebAppSrc -v -ag -sfrag -suid -out WebApp_.wxs Could not load file or assembly 'file:///C:\Program Files (x86)\WiX Toolset v3.8\bin\Heat.exe' or one of its dependencies. An attempt was made to load a program with an incorrect format.            at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)             at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)             at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)             at System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark& stackMark)             at System.Reflection.Assembly.LoadFrom(String assemblyFile)             at Microsoft.Tools.WindowsInstallerXml.Build.Tasks.WixToolTask.ExecuteToolThread(Object parameters) 0>MSBUILD : error MSB4166: Child node "3" exited prematurely. Shutting down. Diagnostic information may be found in files in the temporary files directory named MSBuild_*.failure.txt.

I searched for MSBUILD : error MSB4166: Child node "3" exited prematurely which mostly pointing towards MSBuild’s parallel project building capability. However, turning this feature off on TFS never solved the problem, instead reporting differently.
On same build machine (where TFS is used to build), I tried the Heat.exe command line (See blue in above log), and it worked fine. Even building the same solution on same build machine using MSBuild command line never gave any problem. It was only failing when building through TFS.
Making story short, I posted the problem on different forums, and got response on Wix-User’s Group.  Using these tips, I was able to correct the problem.

Issue is actually related to MSBuild Platform setting on TFS Build Definition.  i.e:
TFS --> Edit Build Definition --> Process --> Advanced --> MSBuild Platform = Auto.
With Auto, MSBuild was actually trying to use Heat.exe as x64 bit process, while it is actually x86 bit process, and so it was failing with this message:
 
Could not load file or assembly 'file:///C:\Program Files (x86)\WiX Toolset v3.8\bin\Heat.exe' or one of its dependencies. An attempt was made to load a program with an incorrect format.
 
Now, changed this to x86 i.e. 
 
TFS --> Edit Build Definition --> Process --> Advanced --> MSBuild Platform = X86
 
Here is a screen shot for this correction:
 
and MSBuild is now able to execute Heat.exe as x86 bit process and building the project as expected.

Displaying <![CDATA[]]> literally in XML while escaping end token.

While adding XML Code Snippets for WIX (Windows Installer XML), I had to write XML containing <![CDATA[Installed OR NETFRAMEWORK40FULL]]>.
Problem arises, where Visual Studio Code Snippets uses <![CDATA[your snippet code here]]> to store the code and it can’t have another <![CDATA[]]> inside it. So it was not accepting this:

<Code Language="xml">
<![CDATA[

<PropertyRef Id="$NETFRAMEWORK40FULL$"/>
  <Condition Message="This application requires Microsoft .NET Framework 4.0 Runtime in order to run. Please install the .NET Framework and then run this installer again." >
        <![CDATA[Installed OR $NETFRAMEWORK40FULL$]]>
</Condition>

]]>
</Code>

That is, the inner <![CDATA[Installed OR $NETFRAMEWORK40FULL$]]> became a bottleneck. So making story short, after Googling, I found very good discussion on this discussion on Stack Overflow Thread and then I was able to build proper XML by escaping ]]>. Here is my solved snippet code:

    <Code Language="xml">    
      <![CDATA[<PropertyRef Id="$NETFRAMEWORK40FULL$"/>
      <Condition Message="This application requires Microsoft .NET Framework 4.0 Runtime in order to run. Please install the .NET Framework and then run this installer again." >
          <![CDATA[Installed OR $NETFRAMEWORK40FULL$]]]]><![CDATA[>
       </Condition>]]>      
    </Code>

See the breaking code into chunks and put in multiple uses of <![CDATA[]]>… Do read Escaping CDATA end token for more info.

Wix Bootstrapper: Exit/End during installation.

 

During CacheAcquireProgress Event:

this.model.BootstrapperApplication.CacheAcquireProgress += (sender, args) =>
{
    //if ever detected InstallState.Cancelled (which can be set from other event like Exit Button Click)
    if (this.State == InstallState.Cancelled)
        args.Result = Result.Cancel; //this would quit installation process.
.

.

.

};

During ExecuteProgress Event:

this.model.BootstrapperApplication.ExecuteProgress += (sender, args) =>
{
    //if ever detected InstallState.Cancelled (which can be set from other event like Exit Button Click)
    if (this.State == InstallState.Cancelled)
        args.Result = Result.Cancel; //this would quit installation process.

.

.

.

};

So if InstallState.Cancelled is ever setup, it would set args.Result=Result.Cancel and so it would quit installation.

Bootstrapper Error 0x8013101b: Failed to create the managed bootstrapper application.

I developed Wix Burn based Managed bootstrapper, which required .Net Framework v4.0.xxx. It worked perfectly fine when I tried on Windows XP + Service Pack 2. That is, it initially launched .Net FW 4 Setup, which I packed in my Burn Package, and then launched my Boostrapper Installer.

But on Windows 7 without Service Pack 1, it was crashing with following log:

[0530:0B50][2014-01-21T11:39:50]i000: Loading managed bootstrapper application.

[0530:0B50][2014-01-21T11:39:51]e000: Error 0x8013101b: Failed to create the managed bootstrapper application.

[0530:0B50][2014-01-21T11:39:51]e000: Error 0x8013101b: Failed to create UX.

[0530:0B50][2014-01-21T11:39:51]e000: Error 0x8013101b: Failed to load UX.

[0530:0B50][2014-01-21T11:39:51]e000: Error 0x8013101b: Failed while running 

.

After some searching and digging, I finally able to solve it by editing BootstrapperCore.config file. Initially, it was:

< startup useLegacyV2RuntimeActivationPolicy="true" >
        < supportedRuntime version="v4.0" / >
        < supportedFramework version="v4\Client" / >
         < supportedRuntime version="v2.0.50727" / >

< /startup>
         

I removed < supportedRuntime version="v2.0.50727" / >. This causes bootstrapper to launch .Net FW 4.0 installation (Packed with as payload). 

Remember, on Windows 7 without SP1, there is .Net framework 3.5. So supportedRuntime version="v2.0.50727" causing the bootstrapper trying to use Net FW 2.0 or 3.5 and so failing, as my Bootstrapper is based on .Net FW 4.

Now, t updated the machine with .Net FW 4 and then launched my bootstrapper, and now working like charm.. :) 

WPF: Loading RTF document in RichTextBox from Embeded Resouce.

While developing a UI interface for Wix based bootstrapper,  I found that in WPF, Richtextbox Control is not same as it was in Windows Forms. So loading an RTF document in it was a little mess. However, while finding and digging for about two days, I finally came to a simple solution. Let’s say, my WPF project name is Surf.

1. In your WPF projects, add a Resources.resx file (if its not already there).
2. Add your RTFDoc.rtf in your Resources.resx file.
3. Along with your Resources.resx file, there would be code behind file:Resources.Designer.cs. Open it and copy its namespace and Class name. In my case it is  Surf.Resources.Resource1

I used this to load rtf data in my WPF RichTextBox control. Here are the lines from the code behind of my XAML:

using Surf.Resources;

void Surface_Loaded(object sender, RoutedEventArgs e)         

{             

//Loading License Agreement document data.
MemoryStream memLicStream = new MemoryStream(ASCIIEncoding.Default.GetBytes(Resource1.RTFDoc));             

this.MyRTFDocument.Selection.Load(memLicStream, DataFormats.Rtf);

}

System.IO.MemoryStream class is used here to load the rtf data from RTFDoc stored in Resource1.resx. And then it is loaded as a Selection in my RichTextBox Control (MyRTFDocument), while specifying Data Format as Rtf.