BA Function

Aug 7, 2013 at 9:17 PM
I am writing a Wix 3.7 bundle which needs to detect the users language and select one of a subset of supported LCIDs, based in the LCID in UserLanguageID, and then pass in only the supported LCID.mst to the MsiPackage. Also I want the bundle language to be set by this action rather than having to launch the setup with -lang LCID.

So in looking at the bafunction template I think I can see how to implement the above in OnDetect. To start I created a test build of the bafunctions.dll with the only addition to the template being the 'Delay' function in the sample code. I added the Variable DelayStart to my wix as in the example. But I am missing how to let the project know to use the bafunction.dll. When I try to added a reference it fails as an invalid type of reference. I am using VS2010.

I also noticed the discussion about the additions to Wix 8.3. Given that this project will not ship for several months, would you advise switching to 8.3 to address the above issue, or proceed with 3.7.

One more question is that some managers want me to use a mba rather than the WixStdba. Does the ba functions concept transfer. I assume not.
Aug 7, 2013 at 10:27 PM
I think I found what I was missing as far as building and linking to the BAFunctions.dll. Sorry for that noise. If you have a chance to comment on the remaining questions it will be appreciated.
Aug 11, 2013 at 9:29 AM
WiX 3.8 correctly identifies the LCID so might be a better option (this extended ba also overrides the LCID so fixes the WiX 3.7 bug).

BAFunctions are WixStdba only they wouldn't really apply to mba as you are writing all the code yourself anyway so can implement the customizations in that.
Aug 14, 2013 at 11:55 PM
Edited Aug 14, 2013 at 11:56 PM
I upgraded my project to WiX 3.8 (and sorted out some confusion with my Win 8 test box), and now the LCID is detected properly (at least so far). I was stepping through the code and observed what I think is incorrect behavior which I posted in this thread:

One reason I was stepping through the code was to see if I could understand why the DelayStart property did not seem to have any effect on the display of the splash screen.

Also after my 3.8 conversion I don't understand why the Version line of text in the dialog is no longer displayed.

Thanks for your help.
Aug 15, 2013 at 7:15 AM
Re the version: To display the version you need to set <bal:WixStandardBootstrapperApplication ShowVersion="yes" />

The m_fPrereq is related to the managed bootstrapper and is set when the class is created so I can't see why it would be undefined. How are you debugging the code?
Aug 15, 2013 at 4:19 PM
I built my project using the installed Wix 3.8.722 on a Windows 7 x64 PC. (I did not figure out how to re-compile the WiX Toolset 3.8 yet so it is a 'Release' build I assume.). I moved my bundle.exe and the Wix 3.8 source and pdbs to a Windows 8 x64 PC. I installed WinDbg and set the source and pdb paths. I had WinDbg launch my bundle and I set a break point in WixStandardBootstrapperApplicaiton.cpp and stepped through the code over and over using the Locals view and the Memory view. I just happened to notice that early in the code when there is a if (m_fPrereq) the prereq code is not executed and then later the prereq code was executed which seemed strange, So I went back and did it over and over again until I could tell that the change is happening in the LoadBootstrapperBAFunctions() call. But I did not figure out exactly what is happening. I hope to figure out how to do a debug build of the toolset, but first I will make the change that you suggested to my project to resolve the ShowVersion issue and try that code in exactly this same configuration to see if this issue still exists.
Aug 15, 2013 at 4:40 PM
Just curious, where did the pdbs come from if you did not re-compile it?
Aug 15, 2013 at 5:04 PM
Edited Aug 15, 2013 at 5:06 PM
I downloaded them from this URL
Aug 15, 2013 at 5:10 PM
Of course, I completely forgot that.

This does seem odd and I can't explain it - I'll see if I can find some time to debug it the same way you did.
Aug 15, 2013 at 5:15 PM
I am trying to figure out how to do a build using the documentation, but so var MSBUILD always gives an error

Microsoft (R) Build Engine Version 4.0.30319.1
[Microsoft .NET Framework, Version 4.0.30319.1008]
Copyright (C) Microsoft Corporation 2007. All rights reserved.

Build started 8/15/2013 11:07:52 AM.
Project "C:\Development\WiX\wix38_source\wix.proj" on node 1 (default targets).
C:\Development\WiX\wix38_source\wix.proj(62,3): error MSB4019: The imported project "C:\Development\WiX\wix38_source\tools\Traversal.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Done Building Project "C:\Development\WiX\wix38_source\wix.proj" (default targets) -- FAILED.


"C:\Development\WiX\wix38_source\wix.proj" (default target) (1) ->
C:\Development\WiX\wix38_source\wix.proj(62,3): error MSB4019: The imported project "C:\Development\WiX\wix38_source\tools\Traversal.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.15

I am rather new to MSBuild and used to using the VS2010 IDE.

Back to the debug issue, would it help if I uploaded screen shot of WinDbg before the call and after the change to m_fPrereq. I t looks to me like the address of the who class is changed to an uninitialized area of memory. The old memory still exists but the whole class instance is in a new area of memory that is not initialized. So it is not just the m_fPrereq that changes but a lot of stuff. Even so the if block tries to use the m_fPrereq value and does the wrong thing based on the changed value. Initially I posted this more as a curious observation not really all that familiar with what should happen. Should I post a bug? I thought maybe another step is to make a simple basic bundle form an example and check it to verify that the observation is not related to my bundle.
Aug 15, 2013 at 6:09 PM
I think a simple repro and bug report would be good that way it can be track.

This is how I build the code:
set MSBUILD="%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\msbuild.exe"
%MSBUILD% wix.proj /p:VisualStudioVersion=11.0 /l:FileLogger,Microsoft.Build.Engine;logfile=build.log
I can't remember why the VisualStudioVersion=11.0 is required but it was discussed on wix-devs.

You also need to build OneTimeWixBuildInitialization.proj once.
Aug 15, 2013 at 6:18 PM
Edited Aug 15, 2013 at 6:19 PM
Thanks. I will work on the repo and bug report and then try the MSBUILD stuff again. I read that the VisualStudioVersion=11.0 is needed when VS2012 is intalled due to a behavior change (or new feature) in VS2012. I only have VS2010 installed. I appreciate the example, and will report back.
Aug 15, 2013 at 7:18 PM
A simple repo was create which has the same behavior. Bug 3357 was created.
Aug 15, 2013 at 7:58 PM
FYI - My build problem is the same as Big #3216 which was fixed in 2/2013. There is no tools folder in the 3.8.722 source zip, so I cannot run the OneTimeWixBuildInitialization.proj I am relatively new to this community and did not know if adding a comment to 3216 was the correct action or opening a new bug.
Aug 15, 2013 at 9:39 PM
Source zip is for reference only, to do a build you need to get the source using Git.
Aug 15, 2013 at 9:49 PM
Guess I am going to have to remember how to use WinDbg - it's been a while!
Aug 15, 2013 at 10:47 PM
Yes, I have the same issue each time I set it up.

I will have to learn how to use Git
Aug 20, 2013 at 11:39 PM
Edited Aug 20, 2013 at 11:39 PM
Neil, I appreciate the information that you have provided. In another thread in the wix-users list, I was trying to help Tim get his project working and I created a project using his code, but edited to simplify last week. I then uploaded both a 3.7 with WixBalExtendedExt.dll build and a 3.8 build which worked to auto detect languages for me. Others still had issues and when I went back to the 3.7 configuration my test project also fails to auto detect. My main project auto detects lcids using 3.8. But I am trying to tackle the 'how to build the source' issue so that I can debug issues like this.

I installed git on my Win 8 test box and was trying to learn the basics and figure out how to get the source code. In the wix docs for either 3.7 or 3.8 there is info on building but it assumes that one already has the source. So while searching for this answer I discovered that I did not need git to get the source. (I shouldprobably still learn it if I ever get to the level of submitting a change.) but I found that all I needed to do was go to, select the 3.7 fork, and click on download. Then extract the resulting zip to a folder on my system. At my development system I did essentially the above MSBUILD commands (without doing the set %MSBUILD% because I was already running in a VS 2010 Command Prompt (as Admin). This resulted in a successful build, with no errors and seven warnings. However as a rule I do not 'test' setups on my development box, and I did not figure out how to get VS2010 to launch a bundle.exe and debug it.

So I tried to do the same build process on my Win 8 x64 test box, but it results in 55 errors. Mostly the wix targets cannot be found. I tried many rebuilds doing the OneTimeWixBuildInitialization.proj followed by the build many times at different paths, ect, with the same 55 errors.

So I guess I have a two sided question.
A) Any thoughts on the cause of the wix.targets not found issue given that I am using the same source files and tools just installed on Win 8 rather than Win 7 (both x64)?
B) If you do not normally use WinDbg, how do you normally debug a bundle.exe, when rebuilding the source code of the wix tools?

Aug 21, 2013 at 1:21 AM
Actually in thinking about this on the drive home, I think I know what I need to do. Thanks for your time.