[WiX-users] Overriable variable are case sensitve.
Commandline parameters are case sensitive when setting up overriable variables and passing them to an MSI using the stdba. Is there a way around this? i.e. How to we recognize command line parameters coming in where case doesn't match? Thanks. Darwin -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] DisplayInternalUI in MsiPackage Issues
First, the progress bar in the MSI UI doesn't show any progress while it is installing. It this universally the case? Has anyone else seen this? I'm also having this issue, are there any solutions? Thanks I've found a kludge that has seemed to work so far. It is bound to cause some weird behavior though. Basically rather than making the main window not visible, I move the main window off the screen and then move it back when I want it back. Something like this: ::SetWindowPos(m_hWnd, HWND_TOPMOST, screenBottom+1, screenRight+1, 0, 0, SWP_SHOWWINDOW); Darwin -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn Install adds item to Programs and Features too soon.
Working with build 2928, it seems that the burn engine adds an entry that is visible in Programs and Features too soon. It adds it there before anything is installed. It can get you into some weird states. Scenario 1: Listed in Programs and Features but not installed There comes a point in the install process where the app is listed in Programs and Features before any packages are installed. There is a point where you can kill the process where nothing was installed but the app is still listed in Programs and Features Scenario 2: Not listed in Programs and Featurs but installed Since the app can show up in Programs and Features prematurely, you can also ask it to uninstall before anything has been installed. You can then continue with the original install process and it installs fine. The result is the program is installed but not listed in Program and Features Any insights? Should I submit a bug? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] DisplayInternalUI in MsiPackage Issues
There are 2 issues that I'm wondering about with the DisplayInternalUI set to Yes in my MsiPackage bundle. First, the progress bar in the MSI UI doesn't show any progress while it is installing. It this universally the case? Has anyone else seen this? Second, there is no item in the task bar for the MSI. This can be a problem if it is the only UI that you are showing. i.e. not showing any other Bootstrapper UI while the MSI is running. Is there a way to configure things so that is will display? Any suggestions? Let me know if these should be entered as bugs. Thanks -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Bundle Pending reboots
Burn seems really strict on enforcing reboots. You can't uninstall after an install until a reboot happens when it is required. It also goes the other way when you uninstall, you can't re-install without a reboot. It looks like what controls this is found in \src\burn\engine\registration.cpp. Specifically RegistrationDetectResumeType check a registry entry for a reboot pending flag and kicks you out of the install. This has made it difficult to write re-install scripts that clean the install off and reinstall it. Is there an easy way to bypass the reboot pending stuff and allow the installer to run anyways? I could fiddle with the registry, but that probably isn't the approach I want to take. This check is probably run and set before the ba has control anyways. Thanks Darwin -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Setting bundle variables from properties or registry entries
I wanted a simple launch condition in the bootstrapper to check and make sure that .net 3.5 is installed. I realize that I can make a PakageGroup, but I don't want to install it if it isn't there. I cannot find a way to reference the NETFRAMEWORK35 property. It looks like the bal Condition only recognizes bundle variables in expressions (not properties) and placing values in bundle variables is a simple copy. It doesn't evaluate expressions. Is this accurate? Is there another means of doing this? Thanks Darwin -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] BalExtension and the Common Public License
I am looking into possibility of creating my own bootstrapper that tweaks the standard bootstrapper. I assume that if I write my bootstrapper from scratch, I shouldn't run into complications, but if I start with the standard bootstrapper code and make some changes that fits my situation, I've created a derivative work and therefore would be required to make the source code publicly available. (At least according to Wikipedia) I imagine there will be people looking to have a place to start with, and the standard bootstrapper source code is where they will probably go. Has this been discussed? Are there any plans to address this? Perhaps a bootstrapper template that is released under less restrictive terms where derivative source code isn't required to be made public availability. Or perhaps a more configurable bootstrapper where dialogs can be suppressed and custom dialogs can be added. Thanks Darwin -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] BalExtension and the Common Public License
I may have taken the wrong approach and this may become a non-issue once the documentation comes out and clears things up, but I was looking to make a quiet bootstrapper whose only dialog was the usage help page; kind of an incremental step from a straight MSI to a bootstrapper, where the MSI dialogs are still used but I can at least take advantage of the pre-req functionality and launch conditions available in the unmanaged bootstrapper. I fiddled around with the Foundation variant of the standard bootstrapper, but it still seemed to need EULA dialogs, Success/Failure dialogs etc. Maybe I gave up too early on this. So my next step was to go look at the WixStdBA source code. It seemed like it would be pretty easy to rip out all the dialogs (pages) except the help page and manipulate it all to step through everything without the user interaction. So having done this, and gotten it to work I'm at the stage of wondering what would be the ramification if we were to distribute it with our product and if it will be a common problem with others. Thanks for your interest. Darwin From: John Robbins [mailto:j...@wintellect.com] Sent: Thursday, July 12, 2012 3:44 PM To: General discussion for Windows Installer XML toolset. Cc: Darwin Baines Subject: RE: BalExtension and the Common Public License Sensitivity: Personal Out of pure curiosity, why would you need to do your own custom bootstrapper? The WiX Burn bootstrapper is incredibly flexible and allows you to completely control everything I can imagine anyone would need. What does Burn not do that you need? Thanks for satisfying my curiosity. John Co-founder - Wintellecthttp://www.wintellect.com/ @JohnWintellecthttps://twitter.com/#!/JohnWintellect | Bloghttp://www.wintellect.com/CS/Blogs/jrobbins/default.aspx +1-206-321-7341 -Original Message- From: Darwin Baines [mailto:da...@microsoft.com]mailto:[mailto:da...@microsoft.com] Sent: Thursday, July 12, 2012 1:58 PM To: wix-users@lists.sourceforge.netmailto:wix-users@lists.sourceforge.net Subject: [WiX-users] BalExtension and the Common Public License Sensitivity: Personal I am looking into possibility of creating my own bootstrapper that tweaks the standard bootstrapper. I assume that if I write my bootstrapper from scratch, I shouldn't run into complications, but if I start with the standard bootstrapper code and make some changes that fits my situation, I've created a derivative work and therefore would be required to make the source code publicly available. (At least according to Wikipedia) I imagine there will be people looking to have a place to start with, and the standard bootstrapper source code is where they will probably go. Has this been discussed? Are there any plans to address this? Perhaps a bootstrapper template that is released under less restrictive terms where derivative source code isn't required to be made public availability. Or perhaps a more configurable bootstrapper where dialogs can be suppressed and custom dialogs can be added. Thanks Darwin -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.netmailto:WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Should balinfo.h be included in sdk/inc?
https://sourceforge.net/tracker/?func=detailaid=3542020group_id=105970atid=642714 Date: Tue, 10 Jul 2012 00:28:17 -0400 From: Bob Arnson Subject: Re: [WiX-users] Should balinfo.h be included in sdk/inc? On 09-Jul-12 17:26, Darwin Baines wrote: You can't build WixStdBA without balinfo.h. Should it be included in the binary distribution under sdk/inc? Yes. Please file a bug so it doesn't get lost in e-mail. -- sig://boB http://joyofsetup.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Should balinfo.h be included in sdk/inc?
You can't build WixStdBA without balinfo.h. Should it be included in the binary distribution under sdk/inc? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Pass parameters from bootstrapper to msi bundle package
I just figured out how this works looking through the WixStdBA source code. This was implemented in time for the RC release on May 21. (https://sourceforge.net/tracker/index.php?func=detailaid=3489809group_id=105970atid=642714) To pass command line arguments, it goes something like this: Wix Bundle Variable Name=CommandLineArg bal:Overridable=yes/ Chain MsiPackage MsiProperty Name=CommandLineArg Value=[CommandLineArg]/ /MsiPackage /Chain /Bundle /Wix You have to make a bundle variable that is overridable at the command line and then pass that variable to your msi. Re: [WiX-users] Pass parameters from bootstrapper to msi bundle packagehttps://sourceforge.net/mailarchive/message.php?msg_id=29237310 From: Hoover, Jacob Jacob.Hoover@gr... - 2012-05-09 03:13 Assuming you are using the StdBA, I am mostly certain that the passing of bootstrapper params to the underlying packages has not been implemented. Sadly, the native BA is a bit rough around the edges. For now the team has been focusing on the core functionality of burn and not the BA's. My advice would be if you need a BA now then it would be faster to do in a MBA than a BA (if your application already requires .Net). If you can't swallow .Net as a prereq, then I'd suggest forking on codeplex and adding the functionality you are looking for. -Original Message- From: Tomislav Markovski [mailto:tmarkovski@...] Sent: Tuesday, May 08, 2012 10:56 AM To: wix-users@... Subject: [WiX-users] Pass parameters from bootstrapper to msi bundle package I'm using VS2010 and WiX 3.6 to create MSI packages and bundle them into Bootstrapper setup. Here's my Boostrapper code. ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Bundle Name= Version= Manufacturer= UpgradeCode= BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.RtfLicense / Chain MsiPackage SourceFile=Package1.msi MsiProperty Name=PARAM1 Value=[PARAM1] / MsiProperty Name=PARAM2 Value=[PARAM2] / /MsiPackage MsiPackage SourceFile=Package2.msi MsiProperty Name=PARAM1 Value=[PARAM1] / MsiProperty Name=PARAM2 Value=[PARAM2] / /MsiPackage /Chain /Bundle /Wix The MSI packages must have the parameters specified in order to run. Normally, I would call Packag21.msi PARAM1=1 PARAM2=2. After I build the project, I try to pass the parameters to my Bootstrapper.exe in the same manner Bootstrapper.exe PARAM1=1 PARAM2=2, but it doesn't seem to pass them to the MSI. Installations hang with the missing parameters condition. Is there a way to pass the parameters from the exe to the msi? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@... https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall Rollback crashes with Wix 3.5
I am having a problem with an uninstall that rolls back and crashes on 64 bit Wix 3.5 setups. We get the following error message in the Event logs: 00 ntdll!RtlReportCriticalFailure(long StatusCode = 0n2, void * FailureInfo = 0x07fe`0023)+0x62 [d:\win7sp1_gdr\minkernel\ntos\rtl\rtlutil.c @ 178] 01 ntdll!RtlpReportHeapFailure(long ErrorLevel = 0n0)+0x26 [d:\win7sp1_gdr\minkernel\ntos\rtl\heaplog.c @ 159] 02 ntdll!RtlpHeapHandleError(long ErrorLevel = 0n2883584)+0x12 [d:\win7sp1_gdr\minkernel\ntos\rtl\heaplog.c @ 381] 03 ntdll!RtlpLogHeapFailure(_HEAP_FAILURE_TYPE FailureType = 0n3441876 (No matching enumerant), void * HeapAddress = 0x`002c, void * Address = 0x`003484d4, void * Param1 = 0x`, void * Param2 = 0x`, void * Param3 = 0x`)+0xa4 [d:\win7sp1_gdr\minkernel\ntos\rtl\heaplog.c @ 679] 04 ntdll!RtlFreeHeap+0x1aab7 05 KERNELBASE!LocalFree(void * hMem = 0x`003484d4)+0x2e [d:\win7sp1_gdr\minkernel\kernelbase\lmem.c @ 439] 06 MSIF262!ExecSecureObjectsRollback(unsigned long hInstall = 0xcf)+0x31c [c:\delivery\dev\wix35\src\ca\wixca\dll\secureobj.cpp @ 913] 07 msi!CallCustomDllEntrypoint(function * pfEntry = 0x`, bool fDebugBreak = true, unsigned long hInstall = 0, wchar_t * szAction = 0x` )+0x26 [d:\w7rtm\admin\darwin\src\engine\action.cpp @ 5293] 08 msi!CMsiCustomAction::CustomActionThread(class CustomActionData * pData = 0x`)+0x2cf [d:\w7rtm\admin\darwin\src\engine\icust.cpp @ 894] 09 kernel32!BaseThreadInitThunk(unsigned long RunProcessInit = 0, function * StartAddress = 0x`, void * Argument = 0x`)+0xd [d:\win7sp1_gdr\base\win32\client\thread.c @ 65] 0a ntdll!RtlUserThreadStart(function * StartAddress = 0x`, void * Argument = 0x`)+0x1d [d:\win7sp1_gdr\minkernel\ntos\rtl\rtlexec.c @ 3185] So it looks like ExecSecureObjectsRollback is the culprit and we are guessing that it is trying to free memory that is already free. We do have one entry in the SecureObject Table that is created by adding a util:PermissionEx element. I do see that this bug may have been addressed in 3.6 http://wix.codeplex.com/SourceControl/network/forks/tedshroyer/tedwix/changeset/changes/839be4dc5f1e CAraman: Fix heap corruption in ExecSecureObjectsRollback. Is there a work around in 3.5 that would prevent this heap corruption? Did this Changeset make it into the 3.6 trunk? Any insight would be appreciated. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
