Building Debug version of WixBalExtensionsExt.dll for use with Wix 3.7.1224.0

Aug 21, 2013 at 4:01 PM
Relative to the discussion in wix-users forum about how to create a multilingual bundle that auto detects the RTF license, I downloaded Wix 3.7.1224 and compiled a Debug build. Now I am trying to compile a Debug version of source from this site (obtained using the Download button on the Source page).

Whether I use the build.bat file, or call MSBUILD, in a VS2010 console, on the specific projects detailed in the build.bat file, or open the BalExtensionExt.sln using VS2010, the project fails to build for a number of reasons. Most of the issues related to not finding various .h files were resolved by adding paths to my 3.7.1224 source tree to the Include directories property in each project.

However there are errors which indicate that various member items, such as 'fPerMachine' is not a member of _BAL_INFO_BUNDLE. I can see from looking at the Wix 3.7.1224 src and the Wix 3.8.722 src that it is a member which was added to the 3.8 source tree and is not defined in the 3.7 source. So what is the correct environment to compile the WixBalExtensionExt.dll in Debug mode for use with Wix 3.7.1224?

Thanks;
Phill
Coordinator
Aug 21, 2013 at 4:24 PM
To build the WixBalExtensionsExt.dll you need to have WiX 3.7 installed - it references the header and lib files shipped with WiX 3.7. It is not compatible with 3.8 as they changed the intefface and as I merged the code in to WiX 3.8 I didn't really see the need to make it compatible (although I probably will once 3.8 is released). Hope this helps.
Aug 21, 2013 at 8:41 PM
Thanks I finally got a Debug build of the WixBalExtensionExt.DLL on a system where I also have a Debug build of Wix 3.7.1224.0. I created VS2010 projects to build both the setup.wxs and Bundle5.wxs in the Examples. I had these projects building against the RTM of 3.7.1224.0, but when I re-point VS2010 to use the Build\Debug\x86 folder of the Debug Wix 3.7.1224 tree (which is also where the WixBalExtensionExt Debug output files are at, candle bombs out (on either the MSI or Bundle project, same reason).

------ Rebuild All started: Project: ExtendedBARtf, Configuration: Debug x86 ------
    Deleting file "C:\Development\WiX\test\ExtendedBARtf\bin\Debug\ExtendedBARtf.exe".
    Deleting file "C:\Development\WiX\test\ExtendedBARtf\bin\Debug\ExtendedBARtf.wixpdb".
    Deleting file "obj\Debug\Bundle12.wixobj".
    Deleting file "obj\Debug\ExtendedBARtf.wixproj.BindContentsFileList.txt".
    Deleting file "obj\Debug\ExtendedBARtf.wixproj.BindOutputsFileList.txt".
    Deleting file "obj\Debug\ExtendedBARtf.wixproj.BindBuiltOutputsFileList.txt".
    C:\Development\WiX\wix37_source_codeplex\build\debug\x86\candle.exe -dDebug -d"DevEnvDir=c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\\" -dSolutionDir=C:\Development\WiX\test\ExtendedBARtf\ -dSolutionExt=.sln -dSolutionFileName=ExtendedBARtf.sln -dSolutionName=ExtendedBARtf -dSolutionPath=C:\Development\WiX\test\ExtendedBARtf\ExtendedBARtf.sln -dConfiguration=Debug -dOutDir=bin\Debug\ -dPlatform=x86 -dProjectDir=C:\Development\WiX\test\ExtendedBARtf\ -dProjectExt=.wixproj -dProjectFileName=ExtendedBARtf.wixproj -dProjectName=ExtendedBARtf -dProjectPath=C:\Development\WiX\test\ExtendedBARtf\ExtendedBARtf.wixproj -dTargetDir=C:\Development\WiX\test\ExtendedBARtf\bin\Debug\ -dTargetExt=.exe -dTargetFileName=ExtendedBARtf.exe -dTargetName=ExtendedBARtf -dTargetPath=C:\Development\WiX\test\ExtendedBARtf\bin\Debug\ExtendedBARtf.exe -out obj\Debug\ -arch x86 -ext C:\Development\WiX\WixBalExtensions_src\build\WixBalExtensionExt.dll -ext ..\..\..\Installs\Tools\WiX_3.7.1224.0\bin\WixNetFxExtension.dll Bundle12.wxs
    Windows Installer Xml Compiler version 3.7.2020.0
    Copyright (C) Outercurve Foundation. All rights reserved.
candle.exe(0,0): error CNDL0001: Could not load file or assembly 'wix, Version=3.0.0.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad' or one of its dependencies. The system cannot find the file specified.
    Exception Type: System.IO.FileNotFoundException
    Stack Trace:
       at System.ModuleHandle.ResolveType(RuntimeModule module, Int32 typeToken, IntPtr* typeInstArgs, Int32 typeInstCount, IntPtr* methodInstArgs, Int32 methodInstCount, ObjectHandleOnStack type)
       at System.ModuleHandle.ResolveTypeHandleInternal(RuntimeModule module, Int32 typeToken, RuntimeTypeHandle[] typeInstantiationContext, RuntimeTypeHandle[] methodInstantiationContext)
       at System.Reflection.RuntimeModule.ResolveType(Int32 metadataToken, Type[] genericTypeArguments, Type[] genericMethodArguments)
       at System.Reflection.CustomAttribute.FilterCustomAttributeRecord(CustomAttributeRecord caRecord, MetadataImport scope, Assembly& lastAptcaOkAssembly, RuntimeModule decoratedModule, MetadataToken decoratedToken, RuntimeType attributeFilterType, Boolean mustBeInheritable, Object[] attributes, IList derivedAttributes, RuntimeType& attributeType, IRuntimeMethodInfo& ctor, Boolean& ctorHasParameters, Boolean& isVarArg)
       at System.Reflection.CustomAttribute.GetCustomAttributes(RuntimeModule decoratedModule, Int32 decoratedMetadataToken, Int32 pcaCount, RuntimeType attributeFilterType, Boolean mustBeInheritable, IList derivedAttributes, Boolean isDecoratedTargetSecurityTransparent)
       at System.Reflection.CustomAttribute.GetCustomAttributes(RuntimeAssembly assembly, RuntimeType caType)
       at System.Reflection.RuntimeAssembly.GetCustomAttributes(Type attributeType, Boolean inherit)
       at System.Attribute.GetCustomAttributes(Assembly element, Type attributeType, Boolean inherit)
       at System.Attribute.GetCustomAttribute(Assembly element, Type attributeType, Boolean inherit)
       at System.Attribute.GetCustomAttribute(Assembly element, Type attributeType)
       at Microsoft.Tools.WindowsInstallerXml.WixExtension.Load(String extension) in c:\Development\WiX\wix37_source_codeplex\src\wix\WixExtension.cs:line 237
       at Microsoft.Tools.WindowsInstallerXml.Tools.Candle.Run(String[] args) in c:\Development\WiX\wix37_source_codeplex\src\candle\candle.cs:line 163
Done building project "ExtendedBARtf.wixproj" -- FAILED.

I am trying to setup a system to debug code and avoid posting a bug that turns out to be related to optimization.
Coordinator
Aug 21, 2013 at 9:07 PM
Not sure what is going on here but I would avoid using VS to build against debug releases because it is really hard to get the msbuild stuff to work properly, I would just revert to using candle/light directly and making sure all the paths point to the debug code.

Just to step back a bit what problem are you trying to investigate?
Aug 21, 2013 at 9:30 PM
Thanks, I will give the batch approach a try.

What problem?

My main problem is to learn to create a debug build and debug a bundle so that I do not file a bug that ends up wasting someone else's time when I file a bug. As an exercise I am also trying to understand the auto detect of multiple languages since various wix-users posts report issues. (My primary project is working thanks to your efforts in WiX 3.8, and they could use 3.8 also.) I am just using the 3.7 issue as a way to figure out how to reliably debug a bundle. After that then back to my primary project to figure out why the splash screen does not show and to develop and debug a BAFunction.dll which validates whether a particular OS has a particular EditionID and several other configuration checks. I created RegSearch and ProductSearches but I need to process the information in a BAFunc.
Coordinator
Aug 22, 2013 at 9:11 PM
I have to admit to not using a debugger much, mostly I just build the code with extra logging in it.
Aug 22, 2013 at 11:54 PM
Edited Aug 22, 2013 at 11:54 PM
I set a side the issue of building the bundle.exe and msi projects against a Debug version of Wix for now, and today I focused on reworking the VS proj files so that I could consistently build to a particular WiX version along the lines documented for Integrating with an MSBUILD server. I found lots of issues of reference paths that were not pointed to the correct location which may have been a reason fro my attempts to target the Wix 3.7 debug build. I also added a BAFunction back into my Wix 3.8 built project and found a simple way to launch the VS debugger and step through the BAFunction. (I did not hook up the pbds or source to be able to step into the rest of the Wix code from my BAFunc code. At the moment I am trying to figure out the Splash Screen 'DelayStart' issue. I implemented as indicated in one of your samples, added the Private function Delay to the BAFunction.dll but I don't see where in your example the Private function ever gets called. If I put it in OnDetectComplete I do not ever see the splash screen but I do see a blank main dialog until the delay. (Sorry for changing subjects from the title. I can start a new thread if you prefer.)
Coordinator
Aug 23, 2013 at 6:01 AM
Can you get Bundle11.wxs to work? That has a splash screen and calls the delay function. Is you splash screen a bmp file? I believe that is the only format that works.
Sep 5, 2013 at 9:26 PM
FYI - I got a Debug build of Wix 3.8 working with my project, and tracked the Splash Screen problem down to the fact that I had implemented the private function Delay() in my BAFunctions.dll, but had not added a call to Delay() in the OnDetect() event handler. I now have this working. (I was originally working with 3.7, but after trying to setup my development system to switch between 3.7 and 3.8, I eventually decided to just go with 3.8 and configure my project to use the latest 'release' of 3.8 when VS2010 Configuration == Release, and the Debug build of 3.8 when Configuration is set to Debug.)