[WiX-users] Trouble with DotNet
Hi All, I am having a very annoying problem. I have a managed bootstrapper application which requires .Net 4.5. I have the proper PackageGroupRef in my bundle's chain, and it installs .Net 4.5 successfully when there is no .Net installed. The problem is that if .Net 4 is already installed I run into one of two problems: If in my BootstrapperCore.config I state: supportedFramework version=v4.5 / I get the following every time I run the installer no matter what: Loading prerequisite bootstrapper application because managed host could not be loaded, error: 0x80070490. ... The prerequisites were already installed. The bootstrapper application will not be reloaded to prevent an infinite loop. If I declare any previous versions for supported framework, the installer crashes, and never loads the prereq window. Any ideas? Nick -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to register specific COM+ components (WiX 3.7)
I'm currently porting a Visual Studio setup and deployment project to WiX. Part of the setup is to install a COM+ Application with a specific COM+ component that has a bunch of interfaces and methods. My problem is that when i specify the native (C++) DllPath and specify one single ComPlusComponent, the MSI installs all COM+ components (classes in the dll). Is there maybe some way to select individual COM+ components that have to be installed without installing everything? So my desired end result would be when I look in Component Services under COM+ Applications: -My COM+ App -Components +*MyComp.MyClass3* . The WiX code looks like this now: File Id=MYCOMP_Dll Source=path..to...MyComp.dll KeyPath=yes Vital=yes TypeLib Class and ProgId stuff from heat.exe output /File complus:ComPlusApplication Id=MyComApplication Name=My COM+ App complus:ComPlusAssembly Id=MyComAssembly Type=native DllPath=[#MYCOMP_Dll] complus:ComPlusComponent Id=MyComComponent3 CLSID=bMyClass3's CLSID HERE / /complus:ComPlusAssembly /complus:ComPlusApplication I would expect that Component Services shows only the ComPlusComponent I defined in my .wxs file. But somehow all components within that dll are there... *More information that might help: The original Setup/Deployment project used a custom action written in C# that used the method InstallMultipleComponents() defined as: void InstallMultipleComponents(string bstrApplIDOrName, ref System.Array ppsaVarFileNames, ref System.Array ppsaVarCLSIDs) Member of COMAdmin.ICOMAdminCatalog2 At runtime it would be InstallMultipleComponents(My COM+ App, MyComp.dll, CLSID of MyClass3 here); -- This registers only the specific component that I specified via the CLSID argument so basically i'm looking for the equivalent in WiX. I'm using WiX 3.7 and VS2010. Testing happens on Windows 2008R2.* -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Light.exe error while running build on build machine
Hello! I'm have got wix 3.7 integrated into daily builds in my company (build machine OS is Windows XP). It used to run fine, scripts were invoked properly with ANT and burn bundles were created until some time ago I started to observe some build crashes (most of the time it builds correctly but 1 attempt out of 5 creates error). From logs I discovered that the problem cause was wix 3.7 linker light.exe. Part of log related to light.exe. Project D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj.metaproj (3) is building D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj (16) on node 1 (default targets). [exec] PrepareForBuild: [exec] Creating directory obj\Release\. [exec] Creating directory bin\Release\. [exec] Compile: [exec] ..\..\3rdParty\wix\3.7.1224.0\candle.exe -dDevEnvDir=T:\Program Files\Microsoft Visual Studio 9.0\Common7 -dSolutionDir=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\ -dSolutionExt=.sln -dSolutionFileName=AVS Installer.sln -dSolutionName=AVS Installer -dSolutionPath=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVS Installer.sln -dConfiguration=Release -dOutDir=bin\Release\ -dPlatform=x86 -dProjectDir=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\ -dProjectExt=.wixproj -dProjectFileName=AVSDB.wixproj -dProjectName=AVSDB -dProjectPath=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj -dTargetDir=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\ -dTargetExt=.exe -dTargetFileName=AVSDB.exe -dTargetName=AVSDB -dTargetPath=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\AVSDB.exe -out obj\Release\ -arch x86 -ext D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\3rdParty\wix\3.7.1224.0\WixUtilExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\WixDependencyExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\\WixBalExtension.dll BundleDB.wxs [exec] Windows Installer Xml Compiler version 3.7.1224.0 [exec] Copyright (C) Outercurve Foundation. All rights reserved. [exec] [exec] BundleDB.wxs [exec] Link: [exec] ..\..\3rdParty\wix\3.7.1224.0\Light.exe -out D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\AVSDB.exe -pdbout D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\AVSDB.wixpdb -ext D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\3rdParty\wix\3.7.1224.0\WixUtilExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\WixDependencyExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\\WixBalExtension.dll -contentsfile obj\Release\AVSDB.wixproj.BindContentsFileList.txt -outputsfile obj\Release\AVSDB.wixproj.BindOutputsFileList.txt -builtoutputsfile obj\Release\AVSDB.wixproj.BindBuiltOutputsFileList.txt -wixprojectfile D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj obj\Release\BundleDB.wixobj [exec] Windows Installer Xml Linker version 3.7.1224.0 [exec] Copyright (C) Outercurve Foundation. All rights reserved. [exec] [exec] Exception has been thrown by the target of an invocation. [exec] at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, SignatureStruct sig, MethodAttributes methodAttributes, RuntimeType typeOwner) [exec] at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeType typeOwner) [exec] at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks) [exec] at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) [exec] at Microsoft.Tools.WindowsInstallerXml.Build.Tasks.WixToolTask.ExecuteToolThread(Object parameters) Does anyone have idea what could cause that? Is that some kind of known issue in wix 3.7 ? Is there any way to fix that? -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] REMOVE ME PLEASE
Please remove me from the Mailing List Ian Pender | Desktop Developer Huddle - Collaborate intelligently ian.pen...@huddle.commailto:ian.pen...@huddle.com | +44 (0)203 598 1564 | www.huddle.comhttp://www.huddle.com/ | @huddle London | New York | San Francisco -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] REMOVE ME PLEASE
On 24/04/2013 10:01, Kagiso Seboni wrote: Please remove me from the Mailing List You can unsubscribe via the mailing list interface at: https://lists.sourceforge.net/lists/listinfo/wix-users -- Bruce Cran -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Bundle - NET4.5 - WinXP(and other unsupported OS'es)
Hello, Today we have a bootstrapper, taking care of first installing .NET 4.5, and then the MSI with the application. If the user runs Windows XP, or any OS/Sp-levels not supported by .NET 4.5 the installation fails with a error-code. How do I add a condition in the beginning of the bootstrapper, that checks if the conditions for .NET 4.5 are met? I don't want the .NET 4.5 to first download and then notify the user about the incompatibility. Regards, Sam -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bundle - NET4.5 - WinXP(and other unsupported OS'es)
Use the Bundle/@Condition attribute. It was designed for this scenario. On Wed, Apr 24, 2013 at 3:25 AM, Sam Boman s...@samb.se wrote: Hello, Today we have a bootstrapper, taking care of first installing .NET 4.5, and then the MSI with the application. If the user runs Windows XP, or any OS/Sp-levels not supported by .NET 4.5 the installation fails with a error-code. How do I add a condition in the beginning of the bootstrapper, that checks if the conditions for .NET 4.5 are met? I don't want the .NET 4.5 to first download and then notify the user about the incompatibility. Regards, Sam -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to register specific COM+ components (WiX 3.7)
It's very possible the COM+ CA in WiX toolset doesn't do exactly that. Perhaps you could take a look at the code and see what is wrong? Code is in src\ext\ComPlusExtension. I know nothing about COM+ so I'm not much help beyond that. On Wed, Apr 24, 2013 at 12:04 AM, Bart van Lierop bartvanlie...@gmail.comwrote: I'm currently porting a Visual Studio setup and deployment project to WiX. Part of the setup is to install a COM+ Application with a specific COM+ component that has a bunch of interfaces and methods. My problem is that when i specify the native (C++) DllPath and specify one single ComPlusComponent, the MSI installs all COM+ components (classes in the dll). Is there maybe some way to select individual COM+ components that have to be installed without installing everything? So my desired end result would be when I look in Component Services under COM+ Applications: -My COM+ App -Components +*MyComp.MyClass3* . The WiX code looks like this now: File Id=MYCOMP_Dll Source=path..to...MyComp.dll KeyPath=yes Vital=yes TypeLib Class and ProgId stuff from heat.exe output /File complus:ComPlusApplication Id=MyComApplication Name=My COM+ App complus:ComPlusAssembly Id=MyComAssembly Type=native DllPath=[#MYCOMP_Dll] complus:ComPlusComponent Id=MyComComponent3 CLSID=bMyClass3's CLSID HERE / /complus:ComPlusAssembly /complus:ComPlusApplication I would expect that Component Services shows only the ComPlusComponent I defined in my .wxs file. But somehow all components within that dll are there... *More information that might help: The original Setup/Deployment project used a custom action written in C# that used the method InstallMultipleComponents() defined as: void InstallMultipleComponents(string bstrApplIDOrName, ref System.Array ppsaVarFileNames, ref System.Array ppsaVarCLSIDs) Member of COMAdmin.ICOMAdminCatalog2 At runtime it would be InstallMultipleComponents(My COM+ App, MyComp.dll, CLSID of MyClass3 here); -- This registers only the specific component that I specified via the CLSID argument so basically i'm looking for the equivalent in WiX. I'm using WiX 3.7 and VS2010. Testing happens on Windows 2008R2.* -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Light.exe error while running build on build machine
What version of the .NET Framework are you using? It certainly could be a bug. Not many people use Windows XP as a development box any longer so we might not get much coverage there. On Wed, Apr 24, 2013 at 12:18 AM, Pawel Fujcik pfuj...@proximetry.plwrote: Hello! I'm have got wix 3.7 integrated into daily builds in my company (build machine OS is Windows XP). It used to run fine, scripts were invoked properly with ANT and burn bundles were created until some time ago I started to observe some build crashes (most of the time it builds correctly but 1 attempt out of 5 creates error). From logs I discovered that the problem cause was wix 3.7 linker light.exe. Part of log related to light.exe. Project D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj.metaproj (3) is building D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj (16) on node 1 (default targets). [exec] PrepareForBuild: [exec] Creating directory obj\Release\. [exec] Creating directory bin\Release\. [exec] Compile: [exec] ..\..\3rdParty\wix\3.7.1224.0\candle.exe -dDevEnvDir=T:\Program Files\Microsoft Visual Studio 9.0\Common7 -dSolutionDir=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\ -dSolutionExt=.sln -dSolutionFileName=AVS Installer.sln -dSolutionName=AVS Installer -dSolutionPath=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVS Installer.sln -dConfiguration=Release -dOutDir=bin\Release\ -dPlatform=x86 -dProjectDir=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\ -dProjectExt=.wixproj -dProjectFileName=AVSDB.wixproj -dProjectName=AVSDB -dProjectPath=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj -dTargetDir=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\ -dTargetExt=.exe -dTargetFileName=AVSDB.exe -dTargetName=AVSDB -dTargetPath=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\AVSDB.exe -out obj\Release\ -arch x86 -ext D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\3rdParty\wix\3.7.1224.0\WixUtilExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\WixDependencyExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\\WixBalExtension.dll BundleDB.wxs [exec] Windows Installer Xml Compiler version 3.7.1224.0 [exec] Copyright (C) Outercurve Foundation. All rights reserved. [exec] [exec] BundleDB.wxs [exec] Link: [exec] ..\..\3rdParty\wix\3.7.1224.0\Light.exe -out D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\AVSDB.exe -pdbout D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\AVSDB.wixpdb -ext D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\3rdParty\wix\3.7.1224.0\WixUtilExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\WixDependencyExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\\WixBalExtension.dll -contentsfile obj\Release\AVSDB.wixproj.BindContentsFileList.txt -outputsfile obj\Release\AVSDB.wixproj.BindOutputsFileList.txt -builtoutputsfile obj\Release\AVSDB.wixproj.BindBuiltOutputsFileList.txt -wixprojectfile D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj obj\Release\BundleDB.wixobj [exec] Windows Installer Xml Linker version 3.7.1224.0 [exec] Copyright (C) Outercurve Foundation. All rights reserved. [exec] [exec] Exception has been thrown by the target of an invocation. [exec] at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, SignatureStruct sig, MethodAttributes methodAttributes, RuntimeType typeOwner) [exec] at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeType typeOwner) [exec] at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks) [exec] at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) [exec] at Microsoft.Tools.WindowsInstallerXml.Build.Tasks.WixToolTask.ExecuteToolThread(Object parameters) Does anyone have idea what could cause that? Is that some kind of known issue in wix 3.7 ? Is there any way to fix that? -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt!
[WiX-users] ODP: Light.exe error while running build on build machine
.NET Framework 4.0 Od: Rob Mensching [r...@robmensching.com] Wysłano: 24 kwietnia 2013 14:29 Do: General discussion for Windows Installer XML toolset. Temat: Re: [WiX-users] Light.exe error while running build on build machine What version of the .NET Framework are you using? It certainly could be a bug. Not many people use Windows XP as a development box any longer so we might not get much coverage there. On Wed, Apr 24, 2013 at 12:18 AM, Pawel Fujcik pfuj...@proximetry.plwrote: Hello! I'm have got wix 3.7 integrated into daily builds in my company (build machine OS is Windows XP). It used to run fine, scripts were invoked properly with ANT and burn bundles were created until some time ago I started to observe some build crashes (most of the time it builds correctly but 1 attempt out of 5 creates error). From logs I discovered that the problem cause was wix 3.7 linker light.exe. Part of log related to light.exe. Project D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj.metaproj (3) is building D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj (16) on node 1 (default targets). [exec] PrepareForBuild: [exec] Creating directory obj\Release\. [exec] Creating directory bin\Release\. [exec] Compile: [exec] ..\..\3rdParty\wix\3.7.1224.0\candle.exe -dDevEnvDir=T:\Program Files\Microsoft Visual Studio 9.0\Common7 -dSolutionDir=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\ -dSolutionExt=.sln -dSolutionFileName=AVS Installer.sln -dSolutionName=AVS Installer -dSolutionPath=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVS Installer.sln -dConfiguration=Release -dOutDir=bin\Release\ -dPlatform=x86 -dProjectDir=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\ -dProjectExt=.wixproj -dProjectFileName=AVSDB.wixproj -dProjectName=AVSDB -dProjectPath=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj -dTargetDir=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\ -dTargetExt=.exe -dTargetFileName=AVSDB.exe -dTargetName=AVSDB -dTargetPath=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\AVSDB.exe -out obj\Release\ -arch x86 -ext D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\3rdParty\wix\3.7.1224.0\WixUtilExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\WixDependencyExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\\WixBalExtension.dll BundleDB.wxs [exec] Windows Installer Xml Compiler version 3.7.1224.0 [exec] Copyright (C) Outercurve Foundation. All rights reserved. [exec] [exec] BundleDB.wxs [exec] Link: [exec] ..\..\3rdParty\wix\3.7.1224.0\Light.exe -out D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\AVSDB.exe -pdbout D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\AVSDB.wixpdb -ext D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\3rdParty\wix\3.7.1224.0\WixUtilExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\WixDependencyExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\\WixBalExtension.dll -contentsfile obj\Release\AVSDB.wixproj.BindContentsFileList.txt -outputsfile obj\Release\AVSDB.wixproj.BindOutputsFileList.txt -builtoutputsfile obj\Release\AVSDB.wixproj.BindBuiltOutputsFileList.txt -wixprojectfile D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj obj\Release\BundleDB.wixobj [exec] Windows Installer Xml Linker version 3.7.1224.0 [exec] Copyright (C) Outercurve Foundation. All rights reserved. [exec] [exec] Exception has been thrown by the target of an invocation. [exec] at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, SignatureStruct sig, MethodAttributes methodAttributes, RuntimeType typeOwner) [exec] at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeType typeOwner) [exec] at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks) [exec] at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) [exec] at Microsoft.Tools.WindowsInstallerXml.Build.Tasks.WixToolTask.ExecuteToolThread(Object parameters) Does anyone have idea what could cause that? Is that some kind of known issue in wix 3.7 ? Is there any way to fix that? -- Try New Relic Now We'll Send You this Cool Shirt New Relic is
Re: [WiX-users] ODP: Light.exe error while running build on build machine
Ahh, there were some screwy issues under WiX v3.7 and friends where NETFX 2.0 (or NETFX 3.5 if you prefer) was necessary to have the toolset build fully. We didn't catch it because most OS's have NETFX 2.0 or 3.5 pre-installed and we thought that NETFX 4.0 clean would work. Try adding NETFX 2.0 or NETFX 3.5. On Wed, Apr 24, 2013 at 5:34 AM, Pawel Fujcik pfuj...@proximetry.pl wrote: .NET Framework 4.0 Od: Rob Mensching [r...@robmensching.com] Wysłano: 24 kwietnia 2013 14:29 Do: General discussion for Windows Installer XML toolset. Temat: Re: [WiX-users] Light.exe error while running build on build machine What version of the .NET Framework are you using? It certainly could be a bug. Not many people use Windows XP as a development box any longer so we might not get much coverage there. On Wed, Apr 24, 2013 at 12:18 AM, Pawel Fujcik pfuj...@proximetry.pl wrote: Hello! I'm have got wix 3.7 integrated into daily builds in my company (build machine OS is Windows XP). It used to run fine, scripts were invoked properly with ANT and burn bundles were created until some time ago I started to observe some build crashes (most of the time it builds correctly but 1 attempt out of 5 creates error). From logs I discovered that the problem cause was wix 3.7 linker light.exe. Part of log related to light.exe. Project D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj.metaproj (3) is building D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj (16) on node 1 (default targets). [exec] PrepareForBuild: [exec] Creating directory obj\Release\. [exec] Creating directory bin\Release\. [exec] Compile: [exec] ..\..\3rdParty\wix\3.7.1224.0\candle.exe -dDevEnvDir=T:\Program Files\Microsoft Visual Studio 9.0\Common7 -dSolutionDir=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\ -dSolutionExt=.sln -dSolutionFileName=AVS Installer.sln -dSolutionName=AVS Installer -dSolutionPath=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVS Installer.sln -dConfiguration=Release -dOutDir=bin\Release\ -dPlatform=x86 -dProjectDir=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\ -dProjectExt=.wixproj -dProjectFileName=AVSDB.wixproj -dProjectName=AVSDB -dProjectPath=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj -dTargetDir=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\ -dTargetExt=.exe -dTargetFileName=AVSDB.exe -dTargetName=AVSDB -dTargetPath=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\AVSDB.exe -out obj\Release\ -arch x86 -ext D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\3rdParty\wix\3.7.1224.0\WixUtilExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\WixDependencyExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\\WixBalExtension.dll BundleDB.wxs [exec] Windows Installer Xml Compiler version 3.7.1224.0 [exec] Copyright (C) Outercurve Foundation. All rights reserved. [exec] [exec] BundleDB.wxs [exec] Link: [exec] ..\..\3rdParty\wix\3.7.1224.0\Light.exe -out D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\AVSDB.exe -pdbout D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\AVSDB.wixpdb -ext D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\3rdParty\wix\3.7.1224.0\WixUtilExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\WixDependencyExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\\WixBalExtension.dll -contentsfile obj\Release\AVSDB.wixproj.BindContentsFileList.txt -outputsfile obj\Release\AVSDB.wixproj.BindOutputsFileList.txt -builtoutputsfile obj\Release\AVSDB.wixproj.BindBuiltOutputsFileList.txt -wixprojectfile D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj obj\Release\BundleDB.wixobj [exec] Windows Installer Xml Linker version 3.7.1224.0 [exec] Copyright (C) Outercurve Foundation. All rights reserved. [exec] [exec] Exception has been thrown by the target of an invocation. [exec] at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, SignatureStruct sig, MethodAttributes methodAttributes, RuntimeType typeOwner) [exec] at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeType typeOwner) [exec] at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks) [exec] at
[WiX-users] ODP: ODP: Light.exe error while running build on build machine
Unfortunately, this is not the problem because NETFX 2.0, NETFX 3.5 and NETFX 4.0 are already installed on build machine (our projects target NETFX 4.0). It must be something else. Od: Rob Mensching [r...@robmensching.com] Wysłano: 24 kwietnia 2013 14:39 Do: General discussion for Windows Installer XML toolset. Temat: Re: [WiX-users] ODP: Light.exe error while running build on build machine Ahh, there were some screwy issues under WiX v3.7 and friends where NETFX 2.0 (or NETFX 3.5 if you prefer) was necessary to have the toolset build fully. We didn't catch it because most OS's have NETFX 2.0 or 3.5 pre-installed and we thought that NETFX 4.0 clean would work. Try adding NETFX 2.0 or NETFX 3.5. On Wed, Apr 24, 2013 at 5:34 AM, Pawel Fujcik pfuj...@proximetry.pl wrote: .NET Framework 4.0 Od: Rob Mensching [r...@robmensching.com] Wysłano: 24 kwietnia 2013 14:29 Do: General discussion for Windows Installer XML toolset. Temat: Re: [WiX-users] Light.exe error while running build on build machine What version of the .NET Framework are you using? It certainly could be a bug. Not many people use Windows XP as a development box any longer so we might not get much coverage there. On Wed, Apr 24, 2013 at 12:18 AM, Pawel Fujcik pfuj...@proximetry.pl wrote: Hello! I'm have got wix 3.7 integrated into daily builds in my company (build machine OS is Windows XP). It used to run fine, scripts were invoked properly with ANT and burn bundles were created until some time ago I started to observe some build crashes (most of the time it builds correctly but 1 attempt out of 5 creates error). From logs I discovered that the problem cause was wix 3.7 linker light.exe. Part of log related to light.exe. Project D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj.metaproj (3) is building D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj (16) on node 1 (default targets). [exec] PrepareForBuild: [exec] Creating directory obj\Release\. [exec] Creating directory bin\Release\. [exec] Compile: [exec] ..\..\3rdParty\wix\3.7.1224.0\candle.exe -dDevEnvDir=T:\Program Files\Microsoft Visual Studio 9.0\Common7 -dSolutionDir=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\ -dSolutionExt=.sln -dSolutionFileName=AVS Installer.sln -dSolutionName=AVS Installer -dSolutionPath=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVS Installer.sln -dConfiguration=Release -dOutDir=bin\Release\ -dPlatform=x86 -dProjectDir=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\ -dProjectExt=.wixproj -dProjectFileName=AVSDB.wixproj -dProjectName=AVSDB -dProjectPath=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj -dTargetDir=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\ -dTargetExt=.exe -dTargetFileName=AVSDB.exe -dTargetName=AVSDB -dTargetPath=D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\AVSDB.exe -out obj\Release\ -arch x86 -ext D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\3rdParty\wix\3.7.1224.0\WixUtilExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\WixDependencyExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\\WixBalExtension.dll BundleDB.wxs [exec] Windows Installer Xml Compiler version 3.7.1224.0 [exec] Copyright (C) Outercurve Foundation. All rights reserved. [exec] [exec] BundleDB.wxs [exec] Link: [exec] ..\..\3rdParty\wix\3.7.1224.0\Light.exe -out D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\AVSDB.exe -pdbout D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\bin\Release\AVSDB.wixpdb -ext D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\3rdParty\wix\3.7.1224.0\WixUtilExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\WixDependencyExtension.dll -ext ..\..\3rdParty\wix\3.7.1224.0\\WixBalExtension.dll -contentsfile obj\Release\AVSDB.wixproj.BindContentsFileList.txt -outputsfile obj\Release\AVSDB.wixproj.BindOutputsFileList.txt -builtoutputsfile obj\Release\AVSDB.wixproj.BindBuiltOutputsFileList.txt -wixprojectfile D:\BuildEnv_new\AirSync-5.0\tmp\AirSyncEWM\Clients\AVSinstaller\AVSDB\AVSDB.wixproj obj\Release\BundleDB.wixobj [exec] Windows Installer Xml Linker version 3.7.1224.0 [exec] Copyright (C) Outercurve Foundation. All rights reserved. [exec] [exec] Exception has been thrown by the target of an invocation. [exec] at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, SignatureStruct sig, MethodAttributes methodAttributes, RuntimeType typeOwner) [exec]
Re: [WiX-users] REMOVE ME PLEASE
You can unsubscribe via the mailing list interface at: https://lists.sourceforge.net/lists/listinfo/wix-users -Original Message- From: Kagiso Seboni [mailto:kagisoseb...@yahoo.com] Sent: April 24, 2013 02:01 To: wix-users sourceforge Subject: Re: [WiX-users] REMOVE ME PLEASE Please remove me from the Mailing List Ian Pender | Desktop Developer Huddle - Collaborate intelligently ian.pen...@huddle.commailto:ian.pen...@huddle.com | +44 (0)203 598 1564 | www.huddle.comhttp://www.huddle.com/ | @huddle London | New York | San Francisco -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Launching App non-elevated in an elevated admin WiX installer.
We have a WiX (.msi) installer that has to run as administrator, but at the end a service app is needed to be launch, but has to launch in non-elevated mode. If it is launched in elevated mode then users have to restart the machine to have it launched in non-elevated mode. Now we have a dll that can be called that will launch apps in non-elevated mode, but it does not seem to work on this app and therefore I was wondering if there are any built in WiX actions that can handle this or some other work around that could help? Thanks, Tim. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Launching-App-non-elevated-in-an-elevated-admin-WiX-installer-tp7585400.html Sent from the wix-users mailing list archive at Nabble.com. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bundle - NET4.5 - WinXP(and other unsupported OS'es)
Is there anywhere where I can see an example of this? I tried using the same condition I have for .Net 4.5 and it still skips the prereq and tries to run the BA. Also, what is the correct syntax for the BootstrapperCore.config for .Net 4.5? If I use 'supportedFramework version=v4.5 /' the BA fails to load. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, April 24, 2013 8:25 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bundle - NET4.5 - WinXP(and other unsupported OS'es) Use the Bundle/@Condition attribute. It was designed for this scenario. On Wed, Apr 24, 2013 at 3:25 AM, Sam Boman s...@samb.se wrote: Hello, Today we have a bootstrapper, taking care of first installing .NET 4.5, and then the MSI with the application. If the user runs Windows XP, or any OS/Sp-levels not supported by .NET 4.5 the installation fails with a error-code. How do I add a condition in the beginning of the bootstrapper, that checks if the conditions for .NET 4.5 are met? I don't want the .NET 4.5 to first download and then notify the user about the incompatibility. Regards, Sam -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Heat.exe for Minor Upgrade
Why did you put stable between asterisks? Is there a caveat? What does it mean? Or use Heat with the -ag switch to make it generate *stable* GUIDs. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-Heat-exe-for-Minor-Upgrade-tp6086713p7585402.html Sent from the wix-users mailing list archive at Nabble.com. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Heat.exe for Minor Upgrade
That's standard in Markdown to mark a word with *emphasis*. On Wed, Apr 24, 2013 at 7:19 AM, sleon sergioleonc...@gmail.com wrote: Why did you put stable between asterisks? Is there a caveat? What does it mean? Or use Heat with the -ag switch to make it generate *stable* GUIDs. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-Heat-exe-for-Minor-Upgrade-tp6086713p7585402.html Sent from the wix-users mailing list archive at Nabble.com. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Launching App non-elevated in an elevated admin WiX installer.
The WiX documentation has a topic about launching an executable at the end of install. Unless you explicitly launched your installation elevated, it will launch as the normal user. On Wed, Apr 24, 2013 at 6:42 AM, TimM timmay...@smarttech.com wrote: We have a WiX (.msi) installer that has to run as administrator, but at the end a service app is needed to be launch, but has to launch in non-elevated mode. If it is launched in elevated mode then users have to restart the machine to have it launched in non-elevated mode. Now we have a dll that can be called that will launch apps in non-elevated mode, but it does not seem to work on this app and therefore I was wondering if there are any built in WiX actions that can handle this or some other work around that could help? Thanks, Tim. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Launching-App-non-elevated-in-an-elevated-admin-WiX-installer-tp7585400.html Sent from the wix-users mailing list archive at Nabble.com. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Entire .NET 4.0 Framework dialog disabled
Shortly after I posted this yesterday, I figured out the problem. I am trying to customize the built-in dialog for installing the .NET dependency. From my earlier post: Page Name=Welcome Hypertext Name=EulaHyperlink X=552 Y=366 Width=-11 Height=34 TabStop=yes FontId=3#(loc.InstallLicenseTerms)/Hypertext Button Name=InstallButton X=578 Y=423 Width=180 Height=50 TabStop=yes FontId=0 Visible=yes#(loc.NetInstallAcceptAndInstallButton)/Button Button Name=WelcomeCancelButton X=740 Y=29 Width=75 Height=40 TabStop=yes FontId=0 Visible=yes#(loc.NetInstallDeclineButton)/Button Text X=578 Y=252 Width=180 Height=50 FontId=1 Visible=yes DisablePrefix=yes#(loc.TitleWelcome)/Text Text X=589 Y=503 Width=180 Height=35 FontId=2 Visible=yes DisablePrefix=yes#(loc.CostarQualityMessage)/Text Text X=11 Y=423 Width=400 Height=50 FontId=2 Visible=yes DisablePrefix=yes#(loc.TitleMessage)/Text Text X=135 Y=492 Width=200 Height=50 FontId=2 Visible=yes DisablePrefix=yes#(loc.NetProductName)/Text /Page Notice that I changed the name of this page to Welcome - in the original theme file, it is named Install. By doing this, everything was showing up on the page and it was displaying. However, everything was disabled but the application was not frozen or anything. Changing it back to Install fixed this behavior. So I see this fix from an experiential point of view. It would seem that the Page elements must be referred to elsewhere to see this behavior. Something must be expecting a page named Install but I don't know what that would be. I would love to be enlightened by someone who knows how this is all hooked up. mvd -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Entire-NET-4-0-Framework-dialog-disabled-tp7585384p7585405.html Sent from the wix-users mailing list archive at Nabble.com. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Entire .NET 4.0 Framework dialog disabled
The src\ext\bal\wixstdba\WixStandardBoostrapperApplication.cpp has a table of identifiers at the top of the code that connect it to the theme. On Wed, Apr 24, 2013 at 7:46 AM, mvd1 ma...@costar.ca wrote: Shortly after I posted this yesterday, I figured out the problem. I am trying to customize the built-in dialog for installing the .NET dependency. From my earlier post: Page Name=Welcome Hypertext Name=EulaHyperlink X=552 Y=366 Width=-11 Height=34 TabStop=yes FontId=3#(loc.InstallLicenseTerms)/Hypertext Button Name=InstallButton X=578 Y=423 Width=180 Height=50 TabStop=yes FontId=0 Visible=yes#(loc.NetInstallAcceptAndInstallButton)/Button Button Name=WelcomeCancelButton X=740 Y=29 Width=75 Height=40 TabStop=yes FontId=0 Visible=yes#(loc.NetInstallDeclineButton)/Button Text X=578 Y=252 Width=180 Height=50 FontId=1 Visible=yes DisablePrefix=yes#(loc.TitleWelcome)/Text Text X=589 Y=503 Width=180 Height=35 FontId=2 Visible=yes DisablePrefix=yes#(loc.CostarQualityMessage)/Text Text X=11 Y=423 Width=400 Height=50 FontId=2 Visible=yes DisablePrefix=yes#(loc.TitleMessage)/Text Text X=135 Y=492 Width=200 Height=50 FontId=2 Visible=yes DisablePrefix=yes#(loc.NetProductName)/Text /Page Notice that I changed the name of this page to Welcome - in the original theme file, it is named Install. By doing this, everything was showing up on the page and it was displaying. However, everything was disabled but the application was not frozen or anything. Changing it back to Install fixed this behavior. So I see this fix from an experiential point of view. It would seem that the Page elements must be referred to elsewhere to see this behavior. Something must be expecting a page named Install but I don't know what that would be. I would love to be enlightened by someone who knows how this is all hooked up. mvd -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Entire-NET-4-0-Framework-dialog-disabled-tp7585384p7585405.html Sent from the wix-users mailing list archive at Nabble.com. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WIN64DUALFOLDERS Issue - Installer modifying values obtained from registry
On a 64 bit OS you'd probably want a second search with Win64=yes. Property Id=EXCELPATH32 RegistrySearch Id=ExcelDirSearch32 Root=HKLM Key=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\excel.exe Type=raw / /Property Property Id=EXCELPATH64 RegistrySearch Id=ExcelDirSearch64 Root=HKLM Key=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\excel.exe Type=raw Win64=yes / /Property The 2nd RegistrySearch will probably give you an ICE80 *warning* for using a 64-bit RegistrySearch in a 32-bit package which you can suppress (or just ignore if you don't have treat warning as errors on) but it should work on both x86 x64 systems. -Original Message- From: Shashank Padmanabhan (Aditi Technologies Private LTD) [mailto:v-sh...@microsoft.com] Sent: Wednesday, April 24, 2013 9:59 AM To: WiX-users@lists.sourceforge.net Subject: [WiX-users] WIN64DUALFOLDERS Issue - Installer modifying values obtained from registry Hi all, I am using WIX and trying to read installed location of excel application from Registry. Goal is to launch excel post install based on what the user chooses. I obtain the same using a property below. Property Id=EXCELPATH RegistrySearch Id=ExcelDirSearch Root=HKLM Key=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\excel.exe Type=raw / /Property This obtains the appropriate path. But, it immediately modifies it on a system with 64 bit OS with either of 32 or 64 bit 2013 excel. (It works on 12 other combinations of Win7, Win8, Office 2007, Office 2010, Office 2013 all possible combinations of 32 64 bit) Actual Value in Registry: C:\Program Files\Microsoft Office\... Modified Value by Installer: C:\Program Files (x86)\Microsoft Office\... The obtained value in the property is now no longer valid, since it has the extra ' (x86)' characters in it. I searched around and came across this linkhttp://www.mentby.com/Group/wix-users/registrysearch-converts-value-data.html, where it was suggested to use a custom action to modify the value. We used a custom action to modify the property. But we found that the value is not reflected when the final dialog tries to launch excel on its exit. Additionally, I also tried this. Instead of using EXCELPATH directly to launch excel, I created a dummy property, set it in the custom action and then tried to use to launch excel using that. Property Id=ACTUAL_EXCELPATH /Property Interestingly we found that the property value was being set as per the custom action and was available only until 'InstallFinalize' event. It was cleared out by the time the final dialog was using it to launch excel! (See attached log file) When we hard coded ACTUAL_EXCELPATH property value to the actual value in registry, it remained available after 'InstallFinalize' event. What do I need to do to fix this issue? Note: Also, one weird thing I observed. I quadruple checked this. Win8 64 bit, 2013 32 bit office points to 64 bit programs files location. So is the same with registry value at 'CurrentVersion\App Paths\excel'. Win8 64 bit, 2013 64 bit office points to 64 bit programs files location. So is the same with registry value at CurrentVersion\App Paths\excel. A little perplexed that 32 64 bit versions of office are both at the same program files location (Installed 2 different PC's). Location being - C:\Program Files\Microsoft Office\ The 32 bit version of office should have installed at C:\Program Files (x86)\Microsoft Office\...! Thanks, Shashank -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WIN64DUALFOLDERS Issue - Installer modifying values obtained from registry
thanks for the reply Jacob. Will try it out tomorrow when in office. I also found that the same works on a 2010 version of office (32 64 bit, on 64 bit OS). One would have expected it to fail on that too, but it works there. From: Hoover, Jacob [jacob.hoo...@greenheck.com] Sent: Wednesday, April 24, 2013 8:54 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WIN64DUALFOLDERS Issue - Installer modifying values obtained from registry On a 64 bit OS you'd probably want a second search with Win64=yes. Property Id=EXCELPATH32 RegistrySearch Id=ExcelDirSearch32 Root=HKLM Key=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\excel.exe Type=raw / /Property Property Id=EXCELPATH64 RegistrySearch Id=ExcelDirSearch64 Root=HKLM Key=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\excel.exe Type=raw Win64=yes / /Property The 2nd RegistrySearch will probably give you an ICE80 *warning* for using a 64-bit RegistrySearch in a 32-bit package which you can suppress (or just ignore if you don't have treat warning as errors on) but it should work on both x86 x64 systems. -Original Message- From: Shashank Padmanabhan (Aditi Technologies Private LTD) [mailto:v-sh...@microsoft.com] Sent: Wednesday, April 24, 2013 9:59 AM To: WiX-users@lists.sourceforge.net Subject: [WiX-users] WIN64DUALFOLDERS Issue - Installer modifying values obtained from registry Hi all, I am using WIX and trying to read installed location of excel application from Registry. Goal is to launch excel post install based on what the user chooses. I obtain the same using a property below. Property Id=EXCELPATH RegistrySearch Id=ExcelDirSearch Root=HKLM Key=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\excel.exe Type=raw / /Property This obtains the appropriate path. But, it immediately modifies it on a system with 64 bit OS with either of 32 or 64 bit 2013 excel. (It works on 12 other combinations of Win7, Win8, Office 2007, Office 2010, Office 2013 all possible combinations of 32 64 bit) Actual Value in Registry: C:\Program Files\Microsoft Office\... Modified Value by Installer: C:\Program Files (x86)\Microsoft Office\... The obtained value in the property is now no longer valid, since it has the extra ' (x86)' characters in it. I searched around and came across this linkhttp://www.mentby.com/Group/wix-users/registrysearch-converts-value-data.html, where it was suggested to use a custom action to modify the value. We used a custom action to modify the property. But we found that the value is not reflected when the final dialog tries to launch excel on its exit. Additionally, I also tried this. Instead of using EXCELPATH directly to launch excel, I created a dummy property, set it in the custom action and then tried to use to launch excel using that. Property Id=ACTUAL_EXCELPATH /Property Interestingly we found that the property value was being set as per the custom action and was available only until 'InstallFinalize' event. It was cleared out by the time the final dialog was using it to launch excel! (See attached log file) When we hard coded ACTUAL_EXCELPATH property value to the actual value in registry, it remained available after 'InstallFinalize' event. What do I need to do to fix this issue? Note: Also, one weird thing I observed. I quadruple checked this. Win8 64 bit, 2013 32 bit office points to 64 bit programs files location. So is the same with registry value at 'CurrentVersion\App Paths\excel'. Win8 64 bit, 2013 64 bit office points to 64 bit programs files location. So is the same with registry value at CurrentVersion\App Paths\excel. A little perplexed that 32 64 bit versions of office are both at the same program files location (Installed 2 different PC's). Location being - C:\Program Files\Microsoft Office\ The 32 bit version of office should have installed at C:\Program Files (x86)\Microsoft Office\...! Thanks, Shashank -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt!
Re: [WiX-users] Outercurve OSS Conference, May 8-9, Bellevue WA
Why sir, surely if it is in verbal jousting that thoust taketh part, thou should be sharpening thy lance and not thy sword. - Original Message - From: Rob Mensching r...@robmensching.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tuesday, April 23, 2013 6:34:32 PM Subject: [WiX-users] Outercurve OSS Conference, May 8-9, Bellevue WA Greetings all, It's not often that I start a thread on wix-users but I thought this might be an event some of you would find interesting. On May 8th and 9th, the Outercurve Foundation (the keeper's of the WiX toolset copyright) is holding its first Open Source Conference. They've got some famous people talking like: Jono Bacon, Scott Guthrie, Donnie Berkholz, and Ross Gardler. They even have some less famous people, coughme/cough, doing hand to hand combat over software installation and packaging. I'll be going at it with the project leads for NuGet and CoApp. That should be fun. Anyway, beyond my cage match, I'll also be floating around at the conference (when I'm not sharpening my sword) so if you're going to be around let me know. You can get more details about the conference here: http://www.regonline.com/builder/site/Default.aspx?EventID=1224520 virtually, Rob Mensching http://robmensching.com/ I should probably make this a blog post. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] After restart, Bundle loses non-default InstallFolder value
Hi, If I change the install location (InstallFolder) to a non-default value, and the Bundle then needs a restart (.NET 4.0 installation), the value after reboot is back to the default value. I've tried setting Persist=yes but that makes no difference.. Is this a bug? Is there a workaround? Thanks, -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/After-restart-Bundle-loses-non-default-InstallFolder-value-tp7585411.html Sent from the wix-users mailing list archive at Nabble.com. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] After restart, Bundle loses non-default InstallFolder value
Persisted='yes' worked for the Visual Studio installer, I know they use this extensively. On Wed, Apr 24, 2013 at 9:37 AM, rowbot james.row...@microfocus.com wrote: Hi, If I change the install location (InstallFolder) to a non-default value, and the Bundle then needs a restart (.NET 4.0 installation), the value after reboot is back to the default value. I've tried setting Persist=yes but that makes no difference.. Is this a bug? Is there a workaround? Thanks, -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/After-restart-Bundle-loses-non-default-InstallFolder-value-tp7585411.html Sent from the wix-users mailing list archive at Nabble.com. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] dotnetfx35.exe and hkcr\installer\dependencies
Hello, I'm noticing quite an awkward problem with the dotnet 3.5 installer. Specifically, it appears to wipe out hkcr\installer\dependencies when a user performs a repair. I am using wix dependency extension and this is causing something of a problem on a few Xp machines (which unfortunately our customers still use) because they suddenly become unable to figure out what deps are installed. Has anyone else seen this? I'm guessing there isn't much that can be done... ? -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Trouble with DotNet 4.5
Can anyone help me with this? Nick -Original Message- From: Nick Miller [mailto:nmil...@livetechnology.com] Sent: Wednesday, April 24, 2013 2:08 AM To: General discussion for Windows Installer XML toolset. (wix-users@lists.sourceforge.net) Subject: [WiX-users] Trouble with DotNet Hi All, I am having a very annoying problem. I have a managed bootstrapper application which requires .Net 4.5. I have the proper PackageGroupRef in my bundle's chain, and it installs .Net 4.5 successfully when there is no .Net installed. The problem is that if .Net 4 is already installed I run into one of two problems: If in my BootstrapperCore.config I state: supportedFramework version=v4.5 / I get the following every time I run the installer no matter what: Loading prerequisite bootstrapper application because managed host could not be loaded, error: 0x80070490. ... The prerequisites were already installed. The bootstrapper application will not be reloaded to prevent an infinite loop. If I declare any previous versions for supported framework, the installer crashes, and never loads the prereq window. Any ideas? Nick -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Including third party DLLs for installer to use
I'm new to WiX so my apologies if this is something I should know already. Background: I'm trying to use WiX to implement a new installer for an existing product whose current installer was written using a commercial tool. We have a large library of functions that our current installer calls during installation to do various tasks (for example, to validate the user's license file). This DLL is old and is not written in a .Net language. Rewriting the DLL is not an option - I'm under a tight schedule and it is too large to consider rewriting. So I need to reuse it. Since I can't call the DLL directly from WiX, what I did is to import it manually into my C# custom action DLL. I'm writing wrapper functions in the custom action DLL to call the functions in the old DLL. So far this works, but only because the old DLL is already present on the target computer and is in a known location. What I need is for this DLL to be bundled inside the MSI so that it gets unpacked into the temporary installation folder. I haven't been able to find a way to do this, and from Googling for an answer I've read that it isn't safe or recommended (for example here: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Call-3rd-party-dll-from-C-Custom-Action-td699134.html). I tried using the Binary tag to include it but no luck. Probably because the DLL is not actually used from the WiX installer itself, but only imported at run time into the custom action DLL. I also have to do something similar with an external EXE that our old installer calls. Any suggestions? Is what I'm trying to do possible? Thanks GregS -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Including-third-party-DLLs-for-installer-to-use-tp7585415.html Sent from the wix-users mailing list archive at Nabble.com. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Prevent minor upgrade
Hi, I am a little lost and wondering if anyone knows how to prevent a minor upgrade. Major upgrades are working fine. What I want to achieve is to prevent (or at least deter through UI) minor upgrades. Does anyone know the conditions for detecting them? -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Including third party DLLs for installer to use
Hi Greg, If I understand your problem correctly, what you need to do is add these dll's as references to the custom action project, then set the Copy Local property to true. When you build the custom action, your customaction.CA.dll will contain all of the dependencies needed for it to run, including your old dll's. If you really want to copy the dll's to the machine, you will need to add them to a component with a file .../ tag, reference it in a feature, and schedule your custom action to run after the files are copied. -Original Message- From: GregS [mailto:gsh...@actuate.com] Sent: Wednesday, April 24, 2013 4:37 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Including third party DLLs for installer to use I'm new to WiX so my apologies if this is something I should know already. Background: I'm trying to use WiX to implement a new installer for an existing product whose current installer was written using a commercial tool. We have a large library of functions that our current installer calls during installation to do various tasks (for example, to validate the user's license file). This DLL is old and is not written in a .Net language. Rewriting the DLL is not an option - I'm under a tight schedule and it is too large to consider rewriting. So I need to reuse it. Since I can't call the DLL directly from WiX, what I did is to import it manually into my C# custom action DLL. I'm writing wrapper functions in the custom action DLL to call the functions in the old DLL. So far this works, but only because the old DLL is already present on the target computer and is in a known location. What I need is for this DLL to be bundled inside the MSI so that it gets unpacked into the temporary installation folder. I haven't been able to find a way to do this, and from Googling for an answer I've read that it isn't safe or recommended (for example here: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Call-3rd-party-dll-from-C-Custom-Action-td699134.html). I tried using the Binary tag to include it but no luck. Probably because the DLL is not actually used from the WiX installer itself, but only imported at run time into the custom action DLL. I also have to do something similar with an external EXE that our old installer calls. Any suggestions? Is what I'm trying to do possible? Thanks GregS -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Including-third-party-DLLs-for-installer-to-use-tp7585415.html Sent from the wix-users mailing list archive at Nabble.com. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] UILevel on uninstall using WixStandardBootstrapperApplication.RtfLicense bootstrapper
Okay, just now got a chance to get back to this. To recap, the issue am seeing is as follows: If I install the msi directly, and then uninstall the msi from ARP, the UILevel is 3 during the uninstall of the .msi. I verify this by checking the value of the UILevel property with a custom action. If I install the burn .exe that chains this same .msi, and then uninstall the burn .exe from ARP, when the uninstall of the burn.exe uninstalls the chained msi, the value of the UILevel is 2 in this same custom action. Rob, per your last reply, you mentioned using MsiProcessMessage() to display the dialog. So I have a C# custom action which calls session.Message. If I install the .msi directly, the session.Message message is displayed on uninstall from ARP. If I install via the bootstrapper that contains the .msi, the session.Message is NOT displayed on uninstall from ARP. Again, the above behavior appears to be based on the UILevel of the .msi being 2 when uninstalled via the bootstrapper, versus a UILevel of the .msi being 3 when being uninstall from ARP directly. Is the UILevel being set incorrectly via the bootstrapper a known issue? You had mentioned in one of your previous responses to this chain that Bob changed some things here last because there were some issues. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Tuesday, April 16, 2013 10:26 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] UILevel on uninstall using WixStandardBootstrapperApplication.RtfLicense bootstrapper Ahh, why not use ::MsiProcessMessage() to display the dialog? If you do that, then the message would be routed all the way through Burn to the BA and the BA would then get the message and display it correctly based on its UI level. Trying to throw ::MessageBox() inside a custom action is only useful for Assert() type dialogs and (when absolutely necessary) when your CA is launched by an MSI UI action (because MSI messed up the communication code and messages are lost). On Tue, Apr 16, 2013 at 8:20 AM, Christopher West C christopher.c.w...@ericsson.com wrote: I figured that question was coming... We have multiple products that can be installed by the customer. We have a core product, and then some additional add-on products that can installed as well, each product having its own .msi. Previously we were installing the .msi files directly and were not trying to make use of the burn functionality.In the core product, we have an installexecute custom action( called after AppSearch) that we call during the core product's removal that checks to see if any add-on products are installed. If so, if the UI Level was 3(which is the value set from ARP) we would display a message box to the user to uninstall the relevant add-on products first and then cancel the uninstall. If the UI Level in this same custom action was 2, then we knew that they were doing a silent uninstall from the command prompt using msiexec, and we would cancel the uninstall without displaying the message box, and instead would write the message to the log file. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Tuesday, April 16, 2013 9:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] UILevel on uninstall using WixStandardBootstrapperApplication.RtfLicense bootstrapper PS: Why does it matter? I'm curious. On Tue, Apr 16, 2013 at 7:52 AM, Rob Mensching r...@robmensching.com wrote: Ug. I know Bob changed some things here last because there were some issues. I thought it was as my memory remembered but I was apparently wrong. Hopefully, he can chime in and correct my understanding and why it is the way it is. There was something... On Tue, Apr 16, 2013 at 7:37 AM, Christopher West C christopher.c.w...@ericsson.com wrote: Yes, I do have the DisplayInternalUI=yes set on the MsiPackage element. Following is the entire MsiPackage element. MsiPackage SourceFile=..\bin\Release\en-us\CWTestGACInstaller.msi DisplayInternalUI=yes Vital=yes /MsiPackage -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Tuesday, April 16, 2013 9:31 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] UILevel on uninstall using WixStandardBootstrapperApplication.RtfLicense bootstrapper Ahh, sorry. Misread the question. Did you set DisplayInternalUI='yes' on the MsiPackage? If no, then the MSIs are always run silently. On Tue, Apr 16, 2013 at 7:13 AM, Christopher West C christopher.c.w...@ericsson.com wrote: Based on what I am seeing , the behavior of the burn .exe uninstalling the chained .msi is not matching the behavior if I install/uninstall the .msi directly. If I install the msi directly, and then
Re: [WiX-users] Including third party DLLs for installer to use
Nick, thanks for the reply. I'm importing the old DLL into my custom action DLL using DllImport(), because Visual Studio won't allow me to add it as a reference to the project. I'm not entirely sure why, but I suspect it is because the old DLL is unmanaged code (written in Delphi 2007). I'm pretty sure my problem would disappear if I could add it as a reference as you suggest, but it doesn't seem possible. The second suggestion might work. I suppose I could install the DLL as a component, run the custom actions, and then delete the DLL. However, some of the custom actions that use this DLL really should run before anything gets installed (for example validating that the user's license file is valid). On the surface it seems it should be simple. I just need a way to have the old DLL bundled into the MSI and to be unpacked into the temporary installation folder along with the custom action DLL. If it's there, then the custom action DLL will be able to find it. I thought of another possible solution. Can someone point me to documentation about writing custom actions in unmanaged code? Specifically, about how to pass parameters from WiX to unmanaged code? I'm thinking that maybe I could take the old Delphi code that's in that DLL and redo the interfaces so they're in the format for custom actions. Then I could use the Delphi DLL as a custom action DLL directly and the problem would disappear. I have access to Delphi for doing this and have time to write new interfaces. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Including-third-party-DLLs-for-installer-to-use-tp7585415p7585419.html Sent from the wix-users mailing list archive at Nabble.com. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Show session.Message during silent install...
Stupid question I know...
I am using WIX 3.7 and using burn to bootstrap my MSI's
Most of my MSI's have no need to show UI, so in Burn i am using:
DisplayInternalUI=no
I have quite a few DTF Custom Actions, and I am using:
Most are Message failures in try catch exception:
catch (Exception ex)
{
WriteErrorLogInstall(session, CheckIfServerOffline failed:
, ex, true);
if (session != null)
{
session.Message(
InstallMessage.User + (int)MessageBoxIcon.Error +
(int)MessageBoxButtons.OK,
new Record { FormatString = Setup could not verify
this blah blah.\nException: + ex.Message });
}
return ActionResult.Failure;
}
However I do have 1 or two messages I do want to show for info reasons for
the user:
session.Message(
InstallMessage.User + (int)MessageBoxIcon.Warning +
(int)MessageBoxButtons.OK,
new Record { FormatString = some important message
to view. });
But I would like to show that warning message that is NOT part of an catch
exception, is that possible?
Steve
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Show-session-Message-during-silent-install-tp7585420.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Try New Relic Now We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Including third party DLLs for installer to use
Hi Greg,
I had one other idea, you might be able to include your unmanaged dll as an
embedded resource and have the CA copy it to a temp directory, then reference
it from there. It's a quick and dirty way to get it done, but it should work.
Basically it would look like this:
private void CopyResource(string resourceName, string file)
{
using (Stream resource =
GetType().Assembly.GetManifestResourceStream(resourceName))
{
if (resource == null)
{
throw new ArgumentException(No such resource, resourceName);
}
using (Stream output = File.OpenWrite(file))
{
resource.CopyTo(output);
}
}
}
-Original Message-
From: GregS [mailto:gsh...@actuate.com]
Sent: Wednesday, April 24, 2013 5:50 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Including third party DLLs for installer to use
Nick, thanks for the reply.
I'm importing the old DLL into my custom action DLL using DllImport(), because
Visual Studio won't allow me to add it as a reference to the project. I'm not
entirely sure why, but I suspect it is because the old DLL is unmanaged code
(written in Delphi 2007). I'm pretty sure my problem would disappear if I could
add it as a reference as you suggest, but it doesn't seem possible.
The second suggestion might work. I suppose I could install the DLL as a
component, run the custom actions, and then delete the DLL. However, some of
the custom actions that use this DLL really should run before anything gets
installed (for example validating that the user's license file is valid).
On the surface it seems it should be simple. I just need a way to have the old
DLL bundled into the MSI and to be unpacked into the temporary installation
folder along with the custom action DLL. If it's there, then the custom action
DLL will be able to find it.
I thought of another possible solution. Can someone point me to documentation
about writing custom actions in unmanaged code? Specifically, about how to pass
parameters from WiX to unmanaged code? I'm thinking that maybe I could take the
old Delphi code that's in that DLL and redo the interfaces so they're in the
format for custom actions. Then I could use the Delphi DLL as a custom action
DLL directly and the problem would disappear.
I have access to Delphi for doing this and have time to write new interfaces.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Including-third-party-DLLs-for-installer-to-use-tp7585415p7585419.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Try New Relic Now We'll Send You this Cool Shirt New Relic is the only
SaaS-based application performance monitoring service that delivers powerful
full stack analytics. Optimize and monitor your browser, app, servers with
just a few lines of code. Try New Relic and get this awesome Nerd Life shirt!
http://p.sf.net/sfu/newrelic_d2d_apr
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Try New Relic Now We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Including third party DLLs for installer to use
Interesting idea. I'll try that tomorrow when I get back into the office. Quick and dirty is fine with me, and if that works then it'll do. I also came up with another possibility, which is simply to write another installer that would install the DLL to a known location. This little installer would run first to install the prerequisites (the DLL and any EXEs the installer needs) and then the main installer could run, and clean up these files when it's done. Of course, the right thing to do would be to convert that old DLL into a true custom action DLL. I'm going to look into that tomorrow, too. Hoping it's possible and doable in the time available. Not sure how good the support for MSI is in that old version of Delphi, however. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Including-third-party-DLLs-for-installer-to-use-tp7585415p7585422.html Sent from the wix-users mailing list archive at Nabble.com. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Including third party DLLs for installer to use
On 24-Apr-13 20:54, GregS wrote: Of course, the right thing to do would be to convert that old DLL into a true custom action DLL. I'm going to look into that tomorrow, too. Hoping it's possible and doable in the time available. Not sure how good the support for MSI is in that old version of Delphi, however. You might need something like JEDI to get a translation of the MSI headers. But otherwise, a custom action is just an exported function with this signature: extern C UINT __stdcall CustomActionEntryPoint( __in MSIHANDLE hInstall ) -- sig://boB http://joyofsetup.com/ -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How do I correctly modify an EventLog?
On 23-Apr-13 13:24, David Kauffmann wrote: I would really love to see an extension to the WixUtilExtension library which provides an EventLog element with the Attributes ModifyOverflowPolicy, MaximumKilobytes, MinimumRetentionDays... essentially all the Properties you can set for an EventLog object from the System.Diagnostics namespace. Please file a feature request with specific requests. Some, like ModifyOverflowPolicy, are just another way of expressing Retention. -- sig://boB http://joyofsetup.com/ -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
