Re: [WiX-users] [WIX]: Display UAC message while launching MSI
Windows Installer is designed to work with UAC by delaying the UAC prompt as long as possible. There is no way to alter that without bootstrapping the MSI. Normally that shouldn’t matter because immediate custom actions should never be changing anything on the computer. It’s only an issue in the extremely few cases where non-elevated code cannot read something it needs access in order to set properties in the installation session. -Blair From: dileep s Sent: Tuesday, December 03, 2013 10:46 PM To: General discussion for Windows Installer XML toolset. Hi All, How to display UAC message while launching MSI? Currently, I am getting UAC message after Install action done in MSI. Anyone please help me on this? Thanks in advance... -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to compile build wix by myself
The DevBundle branch doesn’t have any of the tools that crashed for you. There’s no build directory created in the DevBundle branch either. It has an SLN file you can load into Visual Studio (if you have WiX installed already) or build using MSBuild (also requires WiX available) that contains just one WIXPROJ. Are you really sure you are actually in the DevBundle branch? Simple way out: under src\packages, just open each folder and install what you find there. -Blair From: Smagin Alexander Sent: Tuesday, December 03, 2013 8:08 AM To: General discussion for Windows Installer XML toolset. Blair, thank you for slarification. But when I start building DevBundle, GenerateWixInclude.exe and docfromxsd.exe have crashed. There are exceptions which generated during building. Do you know how to fix them? Sorry for russian error messages, I can translate if it's necessary. "d:\Install\Wix\DevBundle\build\debug\x86\GenerateWixInclude.exe" -nologo "custommsierrors.h" "d:\Install\Wix\DevBundle\build\d ebug\inc\caerr.wxi" Необработанное исключение: System.IO.FileLoadException: Невозможно загрузить файл или сборку "GenerateWixInclude, Version=3.0.0 .0, Culture=neutral, PublicKeyToken=36e4ce08b8ecfb17" или один из зависимых от них компонентов. Сбой при проверке правильности строгого имени. (Исключение из HRESULT: 0x8013141A) Имя файла: "GenerateWixInclude, Version=3.0.0.0, Culture=neutral, PublicKeyToken=36e4ce08b8ecfb17" ---> System.Security.Securit yException: Сбой при проверке правильности строгого имени. (Исключение из HRESULT: 0x8013141A) Ошибкой завершилась сборка со следующим параметром Zone: MyComputer "d:\Install\Wix\DevBundle\build\debug\x86\docfromxsd.exe" -out "d:\Install\Wix\DevBundle\build\obj\debug\x86\chm\documents\xsd" "..\libs\dutil\xsd\thmutil.xsd" "..\tools\wix\Xsd\wix.xsd" "..\tools\wix\Xsd\wixloc.xsd" "..\ext\BalExtension\wixext\Xsd\bal.x sd" "..\ext\ComPlusExtension\wixext\xsd\complus.xsd" "..\ext\DependencyExtension\wixext\Xsd\Dependency.xsd" "..\ext\DifxAppExte nsion\wixext\Xsd\difxapp.xsd" "..\ext\FirewallExtension\wixext\Xsd\firewall.xsd" "..\ext\GamingExtension\wixext\Xsd\gaming.xsd" "..\ext\IIsExtension\wixext\xsd\iis.xsd" "..\ext\MsmqExtension\wixext\xsd\msmq.xsd" "..\ext\NetFxExtension\wixext\Xsd\netfx.xs d" "..\ext\PSExtension\wixext\xsd\ps.xsd" "..\ext\SqlExtension\wixext\Xsd\sql.xsd" "..\ext\TagExtension\wixext\Xsd\tag.xsd" ".. \ext\UtilExtension\wixext\Xsd\util.xsd" "..\ext\VSExtension\wixext\xsd\vs.xsd" "..\ext\lux\wixext\Xsd\lux.xsd" Необработанное исключение: System.IO.FileLoadException: Невозможно загрузить файл или сборку "DocFromXsd, Version=3.0.0.0, Cult ure=neutral, PublicKeyToken=36e4ce08b8ecfb17" или один из зависимых от них компонентов. Сбой при проверке правильности строгого имени. (Исключение из HRESULT: 0x8013141A) Имя файла: "DocFromXsd, Version=3.0.0.0, Culture=neutral, PublicKeyToken=36e4ce08b8ecfb17" ---> System.Security.SecurityExcepti on: Сбой при проверке правильности строгого имени. (Исключение из HRESULT: 0x8013141A) Ошибкой завершилась сборка со следующим параметром Zone: MyComputer Thanks, Alex. Вторник, 3 декабря 2013, 15:13 UTC от Blair Murri : >You will need to first install .Net Framework 3.5, recent versions of Visual >Studio (2010 or newer), then build and install the DevBundle branch (you can >remove the DevBundle installer if you wish, all the components it installs are >marked "permanent"). If you install multiple versions of VS, it is recommended >to install them in chronological order (personal experience) with their latest >service packs. > >Build instructions are (more-or-less) described here (the prerequisites >described are most easily obtained by following my previous instructions): >http://wixtoolset.org/documentation/manual/v3/wixdev/building_wix.html > >The biggest missing piece from the above documentation pages is that >tools\OneTimeWixBuildInitialization.proj must be built using MSBuild from an >elevated command prompt at least once on any given build/dev box before you >can build the rest of the toolset (otherwise you will get build errors >starting early on). Also, it is best to build the entire toolset from the root >of the sources (after having built that one project file elevated) before you >descend into sub directories to work/build individual portions. Running the >developer command prompts for Visual Studio usually isn't necessary, although >MSBuild isn't usually in the path. You'll need the v4 MSBuild, which you can >add your path yourself, use the developer command prompt, prepend the MSBuild >calls with the path to the tool, or create your own alias/batch file to call >the tool. > >-Blair > >From: Smagin Alexander >Sent: Tuesday, December 03, 2013 6:31 AM >To: General discussion for Windows Installer XML toolset. > >Hi people, >I want to compile wix from source code, but I didn't find any readme files >"how to comlipe wix". > >Could an
[WiX-users] [WIX]: Hiding Bootstrapper UI
Hi All, How do I prevent the Bootstrapper.exe after triggering MSI? Is there any solution to hide the Bootstrapper main UI until MSI is progressing? Thanks in advance... -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [WIX]: Hiding Bootstrapper UI
Search the archives of this mail list -Blair From: dileep s Sent: Wednesday, December 04, 2013 1:24 AM To: General discussion for Windows Installer XML toolset. Hi All, How do I prevent the Bootstrapper.exe after triggering MSI? Is there any solution to hide the Bootstrapper main UI until MSI is progressing? Thanks in advance... -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Splash Screen
Just curious: MSDN says that LoadBitmap() is deprecated, and to use LoadImage() instead. I wonder if that makes a difference with the BMP version used. Would you mind opening a bug? I would like to test this scenario out. -Blair From: wdh61 Sent: Tuesday, December 03, 2013 12:43 PM To: General discussion for Windows Installer XML toolset. OK, here's the real answer. Gimp and ImageMagik output a bmp in bmp version 4 format. ImageMagik does that as well but can also output version 3 format. The resulting version 3 file will display in the installer. So, bmp splash screen files have to be version 3 format. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Splash-Screen-tp7590775p7591117.html Sent from the wix-users mailing list archive at Nabble.com. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Some questions about CostFinalize. It spends too much time.
Hi all， I have a problem with wix. There are about 3000 files in my msi and it is about 500M. When I run it at first time, it is quickly. But if the program was already installed in the computer, when I run another msi (the same msi, but build again) it will spend too much time on the prepare dialog. It shows "Please wait while the setip wizard prepares to guide you through the installation. Computing space requirements. " and the "next" button is disabled. It is about more than one minute!! I get the setup log. It shows CostFinalize action spend about more than one minute to scan the files in the disk . The msi sdk said: "The CostFinalize action must be executed before starting any user interface sequence which allows the user to view or modify Feature table selections or directories." So, can i skip this step or CostFinalize action do not spend so much time?? Thanks. Cyan mailc...@163.com -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to compile build wix by myself
It was my mistake , I have tried building wix instead of the DevBundle. I download, compile and install the DevBundle, but the errors with building wix are present, that I mentioned below. The following actions (here is the source http://sourceforge.net/mailarchive/message.php?msg_id=31536281 ) fix the problems with compilation Build from elevated prompt once: msbuild .\tools\OneTimeWixBuildInitialization.proj Then you can build from unelevated. My guess is that you missed the 64-bit or 32-bit signing validation disabling. Now I have another question, or I should create a new thread? How to create a simple setup.exe which just verifies some components and execute msi file that is placed near the setup.exe Thanks, Alex. Среда, 4 декабря 2013, 9:11 UTC от Blair Murri : >The DevBundle branch doesn’t have any of the tools that crashed for you. >There’s no build directory created in the DevBundle branch either. It has an >SLN file you can load into Visual Studio (if you have WiX installed already) >or build using MSBuild (also requires WiX available) that contains just one >WIXPROJ. Are you really sure you are actually in the DevBundle branch? > > >Simple way out: under src\packages, just open each folder and install what you >find there. > >-Blair > >From: Smagin Alexander >Sent: Tuesday, December 03, 2013 8:08 AM >To: General discussion for Windows Installer XML toolset. > > >Blair, thank you for slarification. >But when I start building DevBundle, GenerateWixInclude.exe and docfromxsd.exe >have crashed. > >There are exceptions which generated during building. Do you know how to fix >them? > >Sorry for russian error messages, I can translate if it's necessary. > >"d:\Install\Wix\DevBundle\build\debug\x86\GenerateWixInclude.exe" -nologo >"custommsierrors.h" "d:\Install\Wix\DevBundle\build\d >ebug\inc\caerr.wxi" >Необработанное исключение: System.IO.FileLoadException: Невозможно загрузить >файл или сборку "GenerateWixInclude, Version=3.0.0 >.0, Culture=neutral, PublicKeyToken=36e4ce08b8ecfb17" или один из зависимых от >них компонентов. Сбой при проверке правильности >строгого имени. (Исключение из HRESULT: 0x8013141A) >Имя файла: "GenerateWixInclude, Version=3.0.0.0, Culture=neutral, >PublicKeyToken=36e4ce08b8ecfb17" ---> System.Security.Securit >yException: Сбой при проверке правильности строгого имени. (Исключение из >HRESULT: 0x8013141A) >Ошибкой завершилась сборка со следующим параметром Zone: >MyComputer >"d:\Install\Wix\DevBundle\build\debug\x86\docfromxsd.exe" -out >"d:\Install\Wix\DevBundle\build\obj\debug\x86\chm\documents\xsd" >"..\libs\dutil\xsd\thmutil.xsd" "..\tools\wix\Xsd\wix.xsd" >"..\tools\wix\Xsd\wixloc.xsd" "..\ext\BalExtension\wixext\Xsd\bal.x >sd" "..\ext\ComPlusExtension\wixext\xsd\complus.xsd" >"..\ext\DependencyExtension\wixext\Xsd\Dependency.xsd" "..\ext\DifxAppExte >nsion\wixext\Xsd\difxapp.xsd" >"..\ext\FirewallExtension\wixext\Xsd\firewall.xsd" >"..\ext\GamingExtension\wixext\Xsd\gaming.xsd" >"..\ext\IIsExtension\wixext\xsd\iis.xsd" >"..\ext\MsmqExtension\wixext\xsd\msmq.xsd" >"..\ext\NetFxExtension\wixext\Xsd\netfx.xs >d" "..\ext\PSExtension\wixext\xsd\ps.xsd" >"..\ext\SqlExtension\wixext\Xsd\sql.xsd" >"..\ext\TagExtension\wixext\Xsd\tag.xsd" ".. >\ext\UtilExtension\wixext\Xsd\util.xsd" "..\ext\VSExtension\wixext\xsd\vs.xsd" >"..\ext\lux\wixext\Xsd\lux.xsd" >Необработанное исключение: System.IO.FileLoadException: Невозможно загрузить >файл или сборку "DocFromXsd, Version=3.0.0.0, Cult >ure=neutral, PublicKeyToken=36e4ce08b8ecfb17" или один из зависимых от них >компонентов. Сбой при проверке правильности строгого >имени. (Исключение из HRESULT: 0x8013141A) >Имя файла: "DocFromXsd, Version=3.0.0.0, Culture=neutral, >PublicKeyToken=36e4ce08b8ecfb17" ---> System.Security.SecurityExcepti >on: Сбой при проверке правильности строгого имени. (Исключение из HRESULT: >0x8013141A) >Ошибкой завершилась сборка со следующим параметром Zone: >MyComputer >Thanks, >Alex. > >Вторник, 3 декабря 2013, 15:13 UTC от Blair Murri < os...@live.com >: >>You will need to first install .Net Framework 3.5, recent versions of Visual >>Studio (2010 or newer), then build and install the DevBundle branch (you can >>remove the DevBundle installer if you wish, all the components it installs >>are marked "permanent"). If you install multiple versions of VS, it is >>recommended to install them in chronological order (personal experience) with >>their latest service packs. >> >>Build instructions are (more-or-less) described here (the prerequisites >>described are most easily obtained by following my previous instructions): >>http://wixtoolset.org/documentation/manual/v3/wixdev/building_wix.html >> >>The biggest missing piece from the above documentation pages is that >>tools\OneTimeWixBuildInitialization.proj must be built using MSBuild from an >>elevated command prompt at least once on any given build/dev box before you >>can build the rest of the tool
Re: [WiX-users] How to compile build wix by myself
I didn’t miss it. I mentioned it in the paragraph starting “The biggest missing piece”. Discussing the other question should be in a different thread, but the short answer is: that isn’t quite the model used with burn. Query the archives of this list for details (I suggest using the query string “bundle”). Much was discussed this year. There are other bootstrappers that are closer to that model. -Blair From: Smagin Alexander Sent: Wednesday, December 04, 2013 3:22 AM To: General discussion for Windows Installer XML toolset. It was my mistake , I have tried building wix instead of the DevBundle. I download, compile and install the DevBundle, but the errors with building wix are present, that I mentioned below. The following actions (here is the source http://sourceforge.net/mailarchive/message.php?msg_id=31536281 ) fix the problems with compilation Build from elevated prompt once: msbuild .\tools\OneTimeWixBuildInitialization.proj Then you can build from unelevated. My guess is that you missed the 64-bit or 32-bit signing validation disabling. Now I have another question, or I should create a new thread? How to create a simple setup.exe which just verifies some components and execute msi file that is placed near the setup.exe Thanks, Alex. Среда, 4 декабря 2013, 9:11 UTC от Blair Murri : >The DevBundle branch doesn’t have any of the tools that crashed for you. >There’s no build directory created in the DevBundle branch either. It has an >SLN file you can load into Visual Studio (if you have WiX installed already) >or build using MSBuild (also requires WiX available) that contains just one >WIXPROJ. Are you really sure you are actually in the DevBundle branch? > > >Simple way out: under src\packages, just open each folder and install what you >find there. > >-Blair > >From: Smagin Alexander >Sent: Tuesday, December 03, 2013 8:08 AM >To: General discussion for Windows Installer XML toolset. > > >Blair, thank you for slarification. >But when I start building DevBundle, GenerateWixInclude.exe and docfromxsd.exe >have crashed. > >There are exceptions which generated during building. Do you know how to fix >them? > >Sorry for russian error messages, I can translate if it's necessary. > >"d:\Install\Wix\DevBundle\build\debug\x86\GenerateWixInclude.exe" -nologo >"custommsierrors.h" "d:\Install\Wix\DevBundle\build\d >ebug\inc\caerr.wxi" >Необработанное исключение: System.IO.FileLoadException: Невозможно загрузить >файл или сборку "GenerateWixInclude, Version=3.0.0 >.0, Culture=neutral, PublicKeyToken=36e4ce08b8ecfb17" или один из зависимых от >них компонентов. Сбой при проверке правильности >строгого имени. (Исключение из HRESULT: 0x8013141A) >Имя файла: "GenerateWixInclude, Version=3.0.0.0, Culture=neutral, >PublicKeyToken=36e4ce08b8ecfb17" ---> System.Security.Securit >yException: Сбой при проверке правильности строгого имени. (Исключение из >HRESULT: 0x8013141A) >Ошибкой завершилась сборка со следующим параметром Zone: >MyComputer >"d:\Install\Wix\DevBundle\build\debug\x86\docfromxsd.exe" -out >"d:\Install\Wix\DevBundle\build\obj\debug\x86\chm\documents\xsd" >"..\libs\dutil\xsd\thmutil.xsd" "..\tools\wix\Xsd\wix.xsd" >"..\tools\wix\Xsd\wixloc.xsd" "..\ext\BalExtension\wixext\Xsd\bal.x >sd" "..\ext\ComPlusExtension\wixext\xsd\complus.xsd" >"..\ext\DependencyExtension\wixext\Xsd\Dependency.xsd" "..\ext\DifxAppExte >nsion\wixext\Xsd\difxapp.xsd" >"..\ext\FirewallExtension\wixext\Xsd\firewall.xsd" >"..\ext\GamingExtension\wixext\Xsd\gaming.xsd" >"..\ext\IIsExtension\wixext\xsd\iis.xsd" >"..\ext\MsmqExtension\wixext\xsd\msmq.xsd" >"..\ext\NetFxExtension\wixext\Xsd\netfx.xs >d" "..\ext\PSExtension\wixext\xsd\ps.xsd" >"..\ext\SqlExtension\wixext\Xsd\sql.xsd" >"..\ext\TagExtension\wixext\Xsd\tag.xsd" ".. >\ext\UtilExtension\wixext\Xsd\util.xsd" "..\ext\VSExtension\wixext\xsd\vs.xsd" >"..\ext\lux\wixext\Xsd\lux.xsd" >Необработанное исключение: System.IO.FileLoadException: Невозможно загрузить >файл или сборку "DocFromXsd, Version=3.0.0.0, Cult >ure=neutral, PublicKeyToken=36e4ce08b8ecfb17" или один из зависимых от них >компонентов. Сбой при проверке правильности строгого >имени. (Исключение из HRESULT: 0x8013141A) >Имя файла: "DocFromXsd, Version=3.0.0.0, Culture=neutral, >PublicKeyToken=36e4ce08b8ecfb17" ---> System.Security.SecurityExcepti >on: Сбой при проверке правильности строгого имени. (Исключение из HRESULT: >0x8013141A) >Ошибкой завершилась сборка со следующим параметром Zone: >MyComputer >Thanks, >Alex. > >Вторник, 3 декабря 2013, 15:13 UTC от Blair Murri < os...@live.com >: >>You will need to first install .Net Framework 3.5, recent versions of Visual >>Studio (2010 or newer), then build and install the DevBundle branch (you can >>remove the DevBundle installer if you wish, all the components it installs >>are marked "permanent"). If you install multiple versions of VS, it is >>recommended to install them in chronologic
Re: [WiX-users] Some questions about CostFinalize. It spends too much time.
You can’t skip CostFinalize, but if you don’t use the “built-in” Windows Installer UI, you can skip the “UI sequence” (by doing your UI outside of MSI, say in a bootstrapper). Windows Installer is a declarative, transactional system, and it compares your desired state against the system’s current state in order to generate a “plan” of what needs to be reinstalled vs. what should be left alone as well as how to rollback from any application failures. That discovery time is what you are seeing, and is the “tax” from all the stability goodness that Windows Installer gives you. -Blair From: mailc...@163.com Sent: Wednesday, December 04, 2013 3:21 AM To: General discussion for Windows Installer XML toolset. Hi all， I have a problem with wix. There are about 3000 files in my msi and it is about 500M. When I run it at first time, it is quickly. But if the program was already installed in the computer, when I run another msi (the same msi, but build again) it will spend too much time on the prepare dialog. It shows "Please wait while the setip wizard prepares to guide you through the installation. Computing space requirements. " and the "next" button is disabled. It is about more than one minute!! I get the setup log. It shows CostFinalize action spend about more than one minute to scan the files in the disk . The msi sdk said: "The CostFinalize action must be executed before starting any user interface sequence which allows the user to view or modify Feature table selections or directories." So, can i skip this step or CostFinalize action do not spend so much time?? Thanks. Cyan mailc...@163.com -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Splash Screen
Done. It's bug Bug 4221 William D. Hayden Eastern Skies District Camping Chair Technology Chair From: Blair Murri-3 [via Windows Installer XML (WiX) toolset] To: wdh61 Sent: Wednesday, December 4, 2013 4:50 AM Subject: Re: Splash Screen Just curious: MSDN says that LoadBitmap() is deprecated, and to use LoadImage() instead. I wonder if that makes a difference with the BMP version used. Would you mind opening a bug? I would like to test this scenario out. -Blair From: wdh61 Sent: Tuesday, December 03, 2013 12:43 PM To: General discussion for Windows Installer XML toolset. OK, here's the real answer. Gimp and ImageMagik output a bmp in bmp version 4 format. ImageMagik does that as well but can also output version 3 format. The resulting version 3 file will display in the installer. So, bmp splash screen files have to be version 3 format. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Splash-Screen-tp7590775p7591117.html Sent from the wix-users mailing list archive at Nabble.com. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/wix-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/wix-users If you reply to this email, your message will be added to the discussion below: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Splash-Screen-tp7590775p7591127.html To unsubscribe from Splash Screen, click here. NAML -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Splash-Screen-tp7590775p7591132.html Sent from the wix-users mailing list archive at Nabble.com. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Hex codes in bundle errors
Hi, I'm writing a bundles to chain some installs together. Currently this is WiX 3.6, though I'll be considering an upgrade to 3.8 at some point. The bundle uses the RtfTheme theme, customized with the bal:WixStandardBootstrapperApplication/@ThemeFile attribute. My question is this: Is there a way to remove the hex codes from the error message when a bundle fails. We have a bal:Condition element which throws a message if certain prerequisites aren't installed, and this message gets prefixed with the hex code 0x81f40001. Personally, I don't have a problem with this but the QA engineer asked me to change this as she didn't like the look of it, and I said I'd try to find out if there was a way. So if there's a SuppressHexCodesInErrorMessages variable or attribute somewhere that I haven't found, please point me in the right direction. Thanks John -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] RemoveRegistryValues executing after WriteRegistryValues?
There's nothing wrong with a sequence of InstallExecute, REP, InstallFinalize at the end of the execute sequence - it's one of the choices documented in MSDN. Some rambling thoughts/brain dump to think about: 1. Are you sure you haven't overlapped the Progid element with the registry stuff? I'm pretty sure that the Progid setting populates the Extension and Progid tables in the MSI file - you can check that - and that means Windows Installer will just do all that registration without you needing to add registry entries. Something like that may be going on. 2. You're sure that the component guid is the same in the old and the upgrade installs? 3. Is there a bitness change going on? Was the old version x86 and the new one 64? It's not clear from the log what bitness is being created and which removed. The other issue in this area is Registry Reflection. A 64-bit file association prior to Windows 7 was automatically available to 32 and 64-bit programs. It's suggested here: http://msdn.microsoft.com/en-us/library/windows/desktop/dd464643(v=vs.85).aspx that both items, native and WOW64 be explicitly created, so an x64 install would create both x64 and WOW64 file associations. Phil Wilson On Tue, Dec 3, 2013 at 11:19 AM, Brian Gillespie wrote: > Hi, > > I'm using WiX 3.5 in VS 2010. > > Some of my users are experiencing a problem after performing a major > upgrade of our product. One component (WiX for the component shown below) > seems to have it's file extension and mime type properly registered during > WriteRegistryValues, and then the registration is removed because > RemoveRegistryValues executes after WriteRegistryValues. > > Our application includes VS2005 runtimes, and so I think our InstallExecute > sequencing may be less than ideal, but seems to hold together for the most > part: > > *Install Execute:* > > > > > > > >Before="InstallFinalize"> > > > > > > *Component registration is as follows:* > Guid="11B0087A-8339-482D-8F17-BCD30780EC1B" > Directory="INSTALLDIR.System.x64"> >Source="..\$(var.Platform)\Program Files\System\x64\rhiexec.exe"/> >Key="SOFTWARE\Classes\Rhino.InstallerPackage\DefaultIcon" > Value=""[INSTALLDIR.System.x64]rhiexec.exe",0" Type="string" /> >Key="SOFTWARE\Classes\Rhino.InstallerPackage" Name="FriendlyTypeName" > Value="!(loc.RHIFileDescription)" Type="string" /> >IconIndex='0'> > >TargetFile='RhinoInstallerEngine.64bit.$(var.Platform).rhiexec.exe' > Argument='"%1"' /> > > > > > > *Attached is the verbose install log.* > Of note are lines: > *Line 48242*: MSI (s) (5C:20) [09:35:54:748]: Executing op: > RegAddValue(Name=Content Type,Value=application/rhi,) > > *Line 62911*: MSI (s) (5C:78) [09:36:06:713]: Executing op: > RegRemoveValue(Name=Content Type,Value=application/rhi,) > > Any ideas how I can fix this? Please let me know if you need any other > details. > > - Brian > > Brian Gillespie > Rhinoceros Development > Robert McNeel & Associates > > > -- > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed
Context is a migration of a WiX 2.0.5805.0 solution to WiX 3.8.1128.0. Seemed to be working through the compiler and linker errors one by one just fine until I hit ICE38 regarding shortcuts. There are 2 shortcuts created to the same installed EXE. One shortcut is in the start menu and the other is on the desktop. WiX 2.0 compiled MSIs install, uninstall, and major upgrade with proper cleanup of the shortcuts just fine. Now trying to tackle in WiX 3.8. error LGHT0204 : ICE38: Component component40 installs to user profile. It's Key Path registry key must fall under HKCU. The message states that component40 installs to user profile. Why does it think that? The directory it is within is not user specific and the overall MSI is ALLUSERS=1. The following stackoverflow post looked promising but I'm not understanding it yet. http://stackoverflow.com/questions/2058230/wix-create-non-advertised-shortcu t-for-all-users-per-machine And then another stackoverflow post http://stackoverflow.com/questions/17245832/wix-program-files-shortcut-for-p er-machine-install shows a shortcut as a child of the File. But doesn't really address the fact that a needs to have a and which is HKCU. Other posts have noted that if HKCU is used then when another user uninstalls the registry entries are orphaned under the other user and some state that when application is run as another user it triggers a repair. I dunno on this. I also couldn't find what HKMU was in the WiX help file or online other than Hubert Kairuki Memorial University (something tells me that isn't relevant J ). Is it possible to have an ALLUSERS msi and NOT write to user specific registry, file, or any other user specific resource? In WiX 2.0 we did the following . various other wxs constructs . . various other wxs constructs . . other file components including file2 . In WiX 3.8 we are trying the following . various other wxs constructs . . various other wxs constructs . dave williamson -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed
As I recall, there were major language changes from 2.0 to 3.0 and that refactoring would be expected. 3.0 - 3.8 should generally be backwards compatible though. From: "Dave Williamson, Clear Sky Software" Sent: Wednesday, December 04, 2013 4:50 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed Context is a migration of a WiX 2.0.5805.0 solution to WiX 3.8.1128.0. Seemed to be working through the compiler and linker errors one by one just fine until I hit ICE38 regarding shortcuts. There are 2 shortcuts created to the same installed EXE. One shortcut is in the start menu and the other is on the desktop. WiX 2.0 compiled MSIs install, uninstall, and major upgrade with proper cleanup of the shortcuts just fine. Now trying to tackle in WiX 3.8. error LGHT0204 : ICE38: Component component40 installs to user profile. It's Key Path registry key must fall under HKCU. The message states that component40 installs to user profile. Why does it think that? The directory it is within is not user specific and the overall MSI is ALLUSERS=1. The following stackoverflow post looked promising but I'm not understanding it yet. http://stackoverflow.com/questions/2058230/wix-create-non-advertised-shortcu t-for-all-users-per-machine And then another stackoverflow post http://stackoverflow.com/questions/17245832/wix-program-files-shortcut-for-p er-machine-install shows a shortcut as a child of the File. But doesn't really address the fact that a needs to have a and which is HKCU. Other posts have noted that if HKCU is used then when another user uninstalls the registry entries are orphaned under the other user and some state that when application is run as another user it triggers a repair. I dunno on this. I also couldn't find what HKMU was in the WiX help file or online other than Hubert Kairuki Memorial University (something tells me that isn't relevant J ). Is it possible to have an ALLUSERS msi and NOT write to user specific registry, file, or any other user specific resource? In WiX 2.0 we did the following . various other wxs constructs . . various other wxs constructs . . other file components including file2 . In WiX 3.8 we are trying the following . various other wxs constructs . . various other wxs constructs . dave williamson -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed
Yes there have been. That is why we held at 2.0 and didn't make the jump. We recently ran across the issue where a msi built in 2.0 installs under program files(x86) on x64 machines no matter what. So rather than beat that horse we are putting the time into migrating. Dave Williamson Clear Sky Software http://www.clearskysoftware.com Support: 704-554-6300 Sales: 704-568-5544 -Original Message- From: "Christopher Painter" Sent: 12/4/2013 7:07 PM To: "General discussion about the WiX toolset." ; "wix-users@lists.sourceforge.net" Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed As I recall, there were major language changes from 2.0 to 3.0 and that refactoring would be expected. 3.0 - 3.8 should generally be backwards compatible though. From: "Dave Williamson, Clear Sky Software" Sent: Wednesday, December 04, 2013 4:50 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed Context is a migration of a WiX 2.0.5805.0 solution to WiX 3.8.1128.0. Seemed to be working through the compiler and linker errors one by one just fine until I hit ICE38 regarding shortcuts. There are 2 shortcuts created to the same installed EXE. One shortcut is in the start menu and the other is on the desktop. WiX 2.0 compiled MSIs install, uninstall, and major upgrade with proper cleanup of the shortcuts just fine. Now trying to tackle in WiX 3.8. error LGHT0204 : ICE38: Component component40 installs to user profile. It's Key Path registry key must fall under HKCU. The message states that component40 installs to user profile. Why does it think that? The directory it is within is not user specific and the overall MSI is ALLUSERS=1. The following stackoverflow post looked promising but I'm not understanding it yet. http://stackoverflow.com/questions/2058230/wix-create-non-advertised-shortcu t-for-all-users-per-machine And then another stackoverflow post http://stackoverflow.com/questions/17245832/wix-program-files-shortcut-for-p er-machine-install shows a shortcut as a child of the File. But doesn't really address the fact that a needs to have a and which is HKCU. Other posts have noted that if HKCU is used then when another user uninstalls the registry entries are orphaned under the other user and some state that when application is run as another user it triggers a repair. I dunno on this. I also couldn't find what HKMU was in the WiX help file or online other than Hubert Kairuki Memorial University (something tells me that isn't relevant J ). Is it possible to have an ALLUSERS msi and NOT write to user specific registry, file, or any other user specific resource? In WiX 2.0 we did the following . various other wxs constructs . . various other wxs constructs . . other file components including file2 . In WiX 3.8 we are trying the following . various other wxs constructs . . various other wxs constructs . dave williamson -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed
HKMU is either HKLM or HKCU depending on if it's a per user or per machine install. Note, I have disabled ICE57, as I am using HKMU registry resources for the shortcuts. Windows Installer complains about per-user data and a keypath that can be per-user or per-machine. There are numerous complaints about ICE57, the biggest from Rob M himself saying they neglected to take the ALLUSERS property into account when creating it. While I could replace HKMU with HKCU and avoid the ICE57, it would then leave behind these registry fragments if user A did the install but user B did the uninstall. Ref: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ICE57-with-HKMU-td5795201.html -Original Message- From: Dave Williamson [mailto:d...@clearskysoftware.com] Sent: Wednesday, December 04, 2013 6:56 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed Yes there have been. That is why we held at 2.0 and didn't make the jump. We recently ran across the issue where a msi built in 2.0 installs under program files(x86) on x64 machines no matter what. So rather than beat that horse we are putting the time into migrating. Dave Williamson Clear Sky Software http://www.clearskysoftware.com Support: 704-554-6300 Sales: 704-568-5544 -Original Message- From: "Christopher Painter" Sent: 12/4/2013 7:07 PM To: "General discussion about the WiX toolset." ; "wix-users@lists.sourceforge.net" Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed As I recall, there were major language changes from 2.0 to 3.0 and that refactoring would be expected. 3.0 - 3.8 should generally be backwards compatible though. From: "Dave Williamson, Clear Sky Software" Sent: Wednesday, December 04, 2013 4:50 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed Context is a migration of a WiX 2.0.5805.0 solution to WiX 3.8.1128.0. Seemed to be working through the compiler and linker errors one by one just fine until I hit ICE38 regarding shortcuts. There are 2 shortcuts created to the same installed EXE. One shortcut is in the start menu and the other is on the desktop. WiX 2.0 compiled MSIs install, uninstall, and major upgrade with proper cleanup of the shortcuts just fine. Now trying to tackle in WiX 3.8. error LGHT0204 : ICE38: Component component40 installs to user profile. It's Key Path registry key must fall under HKCU. The message states that component40 installs to user profile. Why does it think that? The directory it is within is not user specific and the overall MSI is ALLUSERS=1. The following stackoverflow post looked promising but I'm not understanding it yet. http://stackoverflow.com/questions/2058230/wix-create-non-advertised-shortcu t-for-all-users-per-machine And then another stackoverflow post http://stackoverflow.com/questions/17245832/wix-program-files-shortcut-for-p er-machine-install shows a shortcut as a child of the File. But doesn't really address the fact that a needs to have a and which is HKCU. Other posts have noted that if HKCU is used then when another user uninstalls the registry entries are orphaned under the other user and some state that when application is run as another user it triggers a repair. I dunno on this. I also couldn't find what HKMU was in the WiX help file or online other than Hubert Kairuki Memorial University (something tells me that isn't relevant J ). Is it possible to have an ALLUSERS msi and NOT write to user specific registry, file, or any other user specific resource? In WiX 2.0 we did the following . various other wxs constructs . . various other wxs constructs . . other file components including file2 . In WiX 3.8 we are trying the following . various other wxs constructs . . various other wxs constructs . dave williamson -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.so
Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed
Thanks for info on HKMU. I'll give it a try and suppress ICE57 on the compile. Is HKMU a WiX thing or did I miss a Windows installer acronym meeting? Dave Williamson -Original Message- From: "Hoover, Jacob" Sent: 12/4/2013 8:11 PM To: "General discussion about the WiX toolset." Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts havechanged HKMU is either HKLM or HKCU depending on if it's a per user or per machine install. Note, I have disabled ICE57, as I am using HKMU registry resources for the shortcuts. Windows Installer complains about per-user data and a keypath that can be per-user or per-machine. There are numerous complaints about ICE57, the biggest from Rob M himself saying they neglected to take the ALLUSERS property into account when creating it. While I could replace HKMU with HKCU and avoid the ICE57, it would then leave behind these registry fragments if user A did the install but user B did the uninstall. Ref: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ICE57-with-HKMU-td5795201.html -Original Message- From: Dave Williamson [mailto:d...@clearskysoftware.com] Sent: Wednesday, December 04, 2013 6:56 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed Yes there have been. That is why we held at 2.0 and didn't make the jump. We recently ran across the issue where a msi built in 2.0 installs under program files(x86) on x64 machines no matter what. So rather than beat that horse we are putting the time into migrating. Dave Williamson Clear Sky Software http://www.clearskysoftware.com Support: 704-554-6300 Sales: 704-568-5544 -Original Message- From: "Christopher Painter" Sent: 12/4/2013 7:07 PM To: "General discussion about the WiX toolset." ; "wix-users@lists.sourceforge.net" Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed As I recall, there were major language changes from 2.0 to 3.0 and that refactoring would be expected. 3.0 - 3.8 should generally be backwards compatible though. From: "Dave Williamson, Clear Sky Software" Sent: Wednesday, December 04, 2013 4:50 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed Context is a migration of a WiX 2.0.5805.0 solution to WiX 3.8.1128.0. Seemed to be working through the compiler and linker errors one by one just fine until I hit ICE38 regarding shortcuts. There are 2 shortcuts created to the same installed EXE. One shortcut is in the start menu and the other is on the desktop. WiX 2.0 compiled MSIs install, uninstall, and major upgrade with proper cleanup of the shortcuts just fine. Now trying to tackle in WiX 3.8. error LGHT0204 : ICE38: Component component40 installs to user profile. It's Key Path registry key must fall under HKCU. The message states that component40 installs to user profile. Why does it think that? The directory it is within is not user specific and the overall MSI is ALLUSERS=1. The following stackoverflow post looked promising but I'm not understanding it yet. http://stackoverflow.com/questions/2058230/wix-create-non-advertised-shortcu t-for-all-users-per-machine And then another stackoverflow post http://stackoverflow.com/questions/17245832/wix-program-files-shortcut-for-p er-machine-install shows a shortcut as a child of the File. But doesn't really address the fact that a needs to have a and which is HKCU. Other posts have noted that if HKCU is used then when another user uninstalls the registry entries are orphaned under the other user and some state that when application is run as another user it triggers a repair. I dunno on this. I also couldn't find what HKMU was in the WiX help file or online other than Hubert Kairuki Memorial University (something tells me that isn't relevant J ). Is it possible to have an ALLUSERS msi and NOT write to user specific registry, file, or any other user specific resource? In WiX 2.0 we did the following . various other wxs constructs . . various other wxs constructs . . other file components including file2 . In WiX 3.8 we are trying the following . various other wxs constructs . . various other wxs constructs .
Re: [WiX-users] Some questions about CostFinalize. It spends too much time.
Hi, Thanks Blair. So, the discovery time can not be more quickly??? I think one minute is too long for waiting for installing. It is just "prepare" and the install is not start even. If i do not use the build-in UI, i think, the discovery time is as long as using the build- in UI. Is it??? Or, is there any other way to fix this problem? thanks. Cyan Blair Murri 编写： >You can’t skip CostFinalize, but if you don’t use the “built-in” Windows >Installer UI, you can skip the “UI sequence” (by doing your UI outside of MSI, >say in a bootstrapper). > > >Windows Installer is a declarative, transactional system, and it compares your >desired state against the system’s current state in order to generate a “plan” >of what needs to be reinstalled vs. what should be left alone as well as how >to rollback from any application failures. That discovery time is what you are >seeing, and is the “tax” from all the stability goodness that Windows >Installer gives you. > > > > > > >-Blair > > > > > >From: mailc...@163.com >Sent: Wednesday, December 04, 2013 3:21 AM >To: General discussion for Windows Installer XML toolset. > > > > > > >Hi all， >I have a problem with wix. >There are about 3000 files in my msi and it is about 500M. When I run it at >first time, it is quickly. But if the program was already installed in the >computer, when I run another msi (the same msi, but build again) it will spend >too much time on the prepare dialog. It shows "Please wait while the setip >wizard prepares to guide you through the installation. Computing space >requirements. " and the "next" button is disabled. It is about more than one >minute!! >I get the setup log. It shows CostFinalize action spend about more than one >minute to scan the files in the disk . >The msi sdk said: >"The CostFinalize action must be executed before starting any user interface >sequence which allows the user to view or modify Feature table selections or >directories." > >So, can i skip this step or CostFinalize action do not spend so much time?? > > >Thanks. >Cyan > > > >mailc...@163.com >-- >Sponsored by Intel(R) XDK >Develop, test and display web and hybrid apps with a single code base. >Download it for free now! >http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk >___ >WiX-users mailing list >WiX-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/wix-users >-- >Sponsored by Intel(R) XDK >Develop, test and display web and hybrid apps with a single code base. >Download it for free now! >http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk >___ >WiX-users mailing list >WiX-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/wix-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Some questions about CostFinalize. It spends too much time.
Hmm, 3000 files shouldn't be that bad... Are these data files which aren't versioned? I wonder if it's doing some hash calculations to see if it needs to repair the files (and as such is reading all the files from disk and computing the hash). Also, do you have anti-virus software running on the machine where this is happening? I've seen AV software block or slow Windows Installer access to a file while it's on-demand scanning it and potentially verifying certificates if the file in question is digitally signed. -Original Message- From: Cyan [mailto:mailc...@163.com] Sent: Wednesday, December 04, 2013 8:00 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Some questions about CostFinalize. It spends too much time. Hi, Thanks Blair. So, the discovery time can not be more quickly??? I think one minute is too long for waiting for installing. It is just "prepare" and the install is not start even. If i do not use the build-in UI, i think, the discovery time is as long as using the build- in UI. Is it??? Or, is there any other way to fix this problem? thanks. Cyan Blair Murri 编写： >You can’t skip CostFinalize, but if you don’t use the “built-in” Windows >Installer UI, you can skip the “UI sequence” (by doing your UI outside of MSI, >say in a bootstrapper). > > >Windows Installer is a declarative, transactional system, and it compares your >desired state against the system’s current state in order to generate a “plan” >of what needs to be reinstalled vs. what should be left alone as well as how >to rollback from any application failures. That discovery time is what you are >seeing, and is the “tax” from all the stability goodness that Windows >Installer gives you. > > > > > > >-Blair > > > > > >From: mailc...@163.com >Sent: Wednesday, December 04, 2013 3:21 AM >To: General discussion for Windows Installer XML toolset. > > > > > > >Hi all， >I have a problem with wix. >There are about 3000 files in my msi and it is about 500M. When I run it at >first time, it is quickly. But if the program was already installed in the >computer, when I run another msi (the same msi, but build again) it will spend >too much time on the prepare dialog. It shows "Please wait while the setip >wizard prepares to guide you through the installation. Computing space >requirements. " and the "next" button is disabled. It is about more than one >minute!! >I get the setup log. It shows CostFinalize action spend about more than one >minute to scan the files in the disk . >The msi sdk said: >"The CostFinalize action must be executed before starting any user interface >sequence which allows the user to view or modify Feature table selections or >directories." > >So, can i skip this step or CostFinalize action do not spend so much time?? > > >Thanks. >Cyan > > > >mailc...@163.com >--- >--- >Sponsored by Intel(R) XDK >Develop, test and display web and hybrid apps with a single code base. >Download it for free now! >http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.c >lktrk ___ >WiX-users mailing list >WiX-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/wix-users >--- >--- >Sponsored by Intel(R) XDK >Develop, test and display web and hybrid apps with a single code base. >Download it for free now! >http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.c >lktrk ___ >WiX-users mailing list >WiX-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/wix-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
