[WiX-users] WiX Releases Archive (All WiX releases since WiX 2.0.5213.0) has a new home
Hi All, For those still interested in the old release versions of WiX. The WiX Releases Archive (All WiX releases since WiX 2.0.5213.0) is now moved to: http://www.jukito.nl/snippets/WiX/ Best regards, Albert van Peppen -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Weekly releases are no longer updated?
Hi all, I noticed for a long time that the weekly updates at http://wixtoolset.org/releases are not updated since January 20, 2014. Is there a specific reason for this? Do we actually have to build the set ourselves in order to test them? Or is there nothing specific that can be tested / everything is open so a useable version cannot be build? Or is it just my proxy that keeps the old page in cache ;) Best regards, Albert van Peppen -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Weekly releases
Hmm, the latest release is still dated August 26, 2013 (WiX 3.8.826.0) Best regards, Albert van Peppen ** WiX Releases Archive - All WiX releases since WiX 2.0.5213.0 (January 2008) at http://madbutcher.dyndns.org/snippets/wix/ -Oorspronkelijk bericht- Van: Rob Mensching [mailto:r...@robmensching.com] Verzonden: 25 September 2013 08:33 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Weekly releases They should be back now. On Tue, Sep 24, 2013 at 10:01 PM, Ivanoff, Alex alex.ivan...@shavlik.comwrote: When will weekly releases be back? -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.c lktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [SPAM] Re: Weekly releases
Mainly waiting for VS2013 support.. But I guess that comes later ;) Also to update my archive ;) Best regards, Albert van Peppen ** WiX Releases Archive - All WiX releases since WiX 2.0.5213.0 (January 2008) at http://madbutcher.dyndns.org/snippets/wix/ -Oorspronkelijk bericht- Van: Rob Mensching [mailto:r...@robmensching.com] Verzonden: 25 September 2013 17:03 Aan: General discussion for Windows Installer XML toolset. Onderwerp: [WiX-users] [SPAM] Re: Weekly releases Yeah. There were no changes until late last week. There will be a new build soon. Were you waiting for those couple changes? On Wed, Sep 25, 2013 at 1:15 AM, Albert van Peppen alb...@insad.nl wrote: Hmm, the latest release is still dated August 26, 2013 (WiX 3.8.826.0) Best regards, Albert van Peppen ** WiX Releases Archive - All WiX releases since WiX 2.0.5213.0 (January 2008) at http://madbutcher.dyndns.org/snippets/wix/ -Oorspronkelijk bericht- Van: Rob Mensching [mailto:r...@robmensching.com] Verzonden: 25 September 2013 08:33 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Weekly releases They should be back now. On Tue, Sep 24, 2013 at 10:01 PM, Ivanoff, Alex alex.ivan...@shavlik.com wrote: When will weekly releases be back? -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg .c lktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.c lktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.c lktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Weekly releases
My First concern is regarding the libraries (.lib files) so I can build my CAs
in C++ using VS2013.
I can use the VS2012 libraries but seeing the improvements in C++/VS2013 I
would like to test the VS2013 compiled libraries.
Also VS2012 Update 4 (still RC3) has some optimizer issues fixed which I think
can fix some problems in some of my CAs, not sure though :).
Since my builds are automated and I don't really use Votive, this is of less
concern to me :)
Best regards,
Albert van Peppen
** WiX Releases Archive - All WiX releases since WiX 2.0.5213.0 (January 2008)
at http://madbutcher.dyndns.org/snippets/wix/
-Oorspronkelijk bericht-
Van: Rob Mensching [mailto:r...@robmensching.com]
Verzonden: 26 September 2013 01:14
Aan: General discussion for Windows Installer XML toolset.
Onderwerp: Re: [WiX-users] [SPAM] Re: Weekly releases
BTW, Alex, this is like the 4th time you've asked for VS2013 support in Votive.
I *highly* recommend you jump in and help write the code to add the support or
do *something* to take some burden off the people who volunteer time on the WiX
toolset before asking again.
I say this because it's around the 2nd time of asking volunteers to do work for
you without offering to help out in anyway that your requests actually start to
*discourage* volunteers from working on the feature for you. If the feature
gets done it's often in spite of repeated requests, not because of them.
smile/
PS: I know I went off on a rant about this same topic a week or so ago so I
apologize to those of you that read the list regularly. To those of you that
regularly answer questions here or write code/fix bugs and generally help make
the WiX toolset better, thank you.
On Wed, Sep 25, 2013 at 3:39 PM, Rob Mensching r...@robmensching.com wrote:
It's pretty well laid out here: http://www.joyofsetup.com/
2013/09/13/getting-from-here-to-there-for-wix-v3-8/
On Wed, Sep 25, 2013 at 1:13 PM, Ivanoff, Alex
alex.ivan...@shavlik.comwrote:
Do you have an ETA for VS 2013 support?
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Wednesday, September 25, 2013 10:46
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] [SPAM] Re: Weekly releases
2013 support is on the list, but hasn't been completed.
-Original Message-
From: Albert van Peppen [mailto:alb...@insad.nl]
Sent: Wednesday, September 25, 2013 10:43 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] [SPAM] Re: Weekly releases
Mainly waiting for VS2013 support.. But I guess that comes later ;)
Also to update my archive ;)
Best regards,
Albert van Peppen
** WiX Releases Archive - All WiX releases since WiX 2.0.5213.0
(January
2008) at http://madbutcher.dyndns.org/snippets/wix/
-Oorspronkelijk bericht-
Van: Rob Mensching [mailto:r...@robmensching.com]
Verzonden: 25 September 2013 17:03
Aan: General discussion for Windows Installer XML toolset.
Onderwerp: [WiX-users] [SPAM] Re: Weekly releases
Yeah. There were no changes until late last week. There will be a new
build soon. Were you waiting for those couple changes?
On Wed, Sep 25, 2013 at 1:15 AM, Albert van Peppen alb...@insad.nl
wrote:
Hmm, the latest release is still dated August 26, 2013 (WiX
3.8.826.0)
Best regards,
Albert van Peppen
** WiX Releases Archive - All WiX releases since WiX 2.0.5213.0
(January
2008) at http://madbutcher.dyndns.org/snippets/wix/
-Oorspronkelijk bericht-
Van: Rob Mensching [mailto:r...@robmensching.com]
Verzonden: 25 September 2013 08:33
Aan: General discussion for Windows Installer XML toolset.
Onderwerp: Re: [WiX-users] Weekly releases
They should be back now.
On Tue, Sep 24, 2013 at 10:01 PM, Ivanoff, Alex
alex.ivan...@shavlik.com
wrote:
When will weekly releases be back?
-
---
--
October Webinars: Code for Performance Free Intel
webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get
the most from the latest Intel processors and coprocessors. See
abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/o
stg .c lktrk ___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
---
---
October Webinars: Code for Performance Free Intel webinars
can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
most from the latest Intel processors and coprocessors. See
abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ost
g.c lktrk
Re: [WiX-users] Is the website wixtoolset.org down ?
You can find an archive of WiX at: http://madbutcher.dyndns.org/snippets/wix/ Which has the all latest released available WiX files. Albert van Peppen BTW Just found that wixtoolset.org is back ;) -Oorspronkelijk bericht- Van: Phill Hogland [mailto:phogl...@rimage.com] Verzonden: 11 September 2013 17:58 Aan: wix-users@lists.sourceforge.net Onderwerp: Re: [WiX-users] Is the website wixtoolset.org down ? Yes the wixtoolset.org web site is still down which means that the wix38.exe setup which I have does not run and install on my new build server. However another approach is to go to wix.codeplex.com, select the Source Code tab, select Wix38 in the browse changes, and then click on Download. This delivers a zip of the source code. I extracted the zip to a folder and then I built it as a Debug build, in my situation. (There are additional steps necessary to create a Release build, but I will wait for the web site to be repaired and download a release package for that purpose.) I had previously installed Wix 3.7 on my build system, so initially I had difficulty getting the downloaded source code to build. IIRC, I had VS2010 open without opening any wix project. I opened a VS command box with Admin privileges (which reportedly is only needed for executing 'msbuild path to source\tools\OneTimeWixBuildInitialization.proj'). I also did: msbuild path to source\wix.proj /t:Clean (after several unsuccessful builds) msbuild path to source\wix.proj (which is the same as also using /p:Configuration=Debug) I tried to use the process in 'Integrating WiX Projects Into Daily Builds' in the chm but ran into various issues. The changes that worked for me were: 1) Create a debug.targets (which I save in a higher level folder and import into each of my wix projects). It has basically this structure, and does not need to be specific to a Debug configuration but that was my focus.) This code could also be added directly to each project file, but when maintaining more than one project the .targets route is easier to maintain. lt;?xml version=1.0 encoding=utf-8? lt;!-- DebugWix defines Properties used to override WiX tool paths to use a Debug build of Wix tools. Edit the path in this file to match the location of the Debug build of Wix tools on this system. WARNING: Unload all Projects which import this file prior to editing it. Add an Import statement after: PropertyGroup Condition= '$(Configuration)|$(Platform)' == 'Debug|x86' lt;DebugWixTrue/DebugWix lt;/PropertyGroup lt;Import Project=..\..\Tools\Targets\DebugWix.targets / -- lt;Project xmlns=http://schemas.microsoft.com/developer/msbuild/2003; lt;PropertyGroup lt;!-- Root of SVN tree, defaults to my primary development configuration, includes trialing backslash -- lt;SvnInstallsDirSl Condition= '$(SvnInstallsDirSl)' == '' C:\Development\Installs\lt;/SvnInstallsDirSl lt;DebugWix Condition= '$(DebugWix)' == '' Falselt;/DebugWix lt;WixToolPath Condition= '$(DebugWix)' == 'True' $(SvnInstallsDirSl)Tools\WiX_3.8_Debug\build\debug\x86\lt;/WixToolPath lt;WixTargetsPath Condition= '$(DebugWix)' == 'True' $(WixToolPath)\Wix.targetslt;/WixTargetsPath WixTasksPath Condition= '$(DebugWix)' == 'True' $(WixToolPath)\wixtasks.dlllt;/WixTasksPath LuxTargetsPath Condition= '$(DebugWix)' == 'True' $(WixToolPath)\Lux.targetslt;/LuxTargetsPath lt;LuxTasksPath Condition= '$(DebugWix)' == 'True' $(WixToolPath)\LuxTasks.dlllt;/LuxTasksPath lt;!-- Observed ICE validation errors when: $(WIX) was set to default 3.7 installationand the above Properties were set to Wix 3.8 in the SVN ...\Tools archive.-- lt;WIX Condition= '$(DebugWix)' == 'True' $(WixToolPath)lt;/WIX lt;DefineConstants Condition= '$(DebugWix)' == 'True' Debug;TRACElt;/DefineConstants lt;/PropertyGroup lt;/Project On each of my build systems I define a System Envronment variable 'SvnInstallsDirSl' which points at the root of my SVN checkout. For each Wix project (setup, bootstrapper, or lib) I do the following by editing the project file directly (in V2010 right click the project to 'Unload' it, then right-click to Edit it, the reload it). 1) add the the code snippet (in the comments of the above file) to the end of the existing 'Debug' PropertyGroup, adjusting the relative path as needed. 2) If there are any 'WixExtension elements in an ItemGroup, with a HintPath, replace the relative path with '$(WixToolPath)WixXxxxExtension.dll' NOTE that the WixToolPath has a trailing backslash so there is none specified in this path. This and the fact that I included the new target prior to this point, fixes the x64 platform issue that others run into when doing the chm process. Now when I open the project in VS2010 and set the configuration to Debug, all projects build using the locally compiled version of the Wix tools. I hope this helps, although waiting for the web site to return might
Re: [WiX-users] Wix dev and regular dev best practices
We have the WiX tool installed on a shared drive on the network; for building the installer we use the commandline tools in the Project Property Sheets. This way the developers in our team don't need to install WiX but will still use it. Our devs build the apps, test it themselves and put it through to test. During their build they can deceide to test with or without the MSI, build the buildserver basically only generates MSI files for testing. Then we have one project (not generally used b the developers) which generates one set MSI for the entire set of applications. (One set consists of a DBx86, DBx64, ServerApplication and ClientApplication component and some special components (like terminalregistration tools, XML server, webservice controller, etc) Albert van Peppen -Oorspronkelijk bericht- Van: Alain Forget [mailto:afor...@cmu.edu] Verzonden: 31 May 2013 21:43 Aan: 'General discussion for Windows Installer XML toolset.' Onderwerp: Re: [WiX-users] Wix dev and regular dev best practices +1 The chasm between getting things working in a development environment and getting them working seamlessly in the deployment environment (by end users) is a lot wider than some may be willing to admit. Alain -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: May 31, 2013 15:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix dev and regular dev best practices If it doesn't get built, it won't get tested. Period. Dev's have a tendency to consider installer building a waste of time (they always think they can do it better with a 3rd-party zip lib and some sort of XML config document) until it's one week before beta and suddenly you need to shake the bugs out of code that should've been tested since the beginning of the iteration six months prior. Push back HARD on any suggestion that building the installer is expendable. It's one of Wix's greatest strengths, and the installer is the first view a consumer will get of your product. If it isn't a good impression, it will have disproportionate impact. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.® Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Drake, David [mailto:david.dr...@wizards.com] Sent: Friday, May 31, 2013 1:39 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix dev and regular dev best practices Albert, Do you require your regular code writing devs to install Wix on their boxes so they don't get errors opening the wixproj files in the main solution, or do you keep the .wixproj files off in their own little solution so the devs don't notice? Also, do your devs handle the installers, or does someone other than the main app coders do that? Thanks, ~David -Original Message- From: Albert van Peppen [mailto:alb...@insad.nl] Sent: Thursday, May 30, 2013 23:52 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix dev and regular dev best practices We use a lot of (VS) Project Property Sheets. For WiX we have defined several property sheets for this. Our solution gives us the possibility to change the location where WixTools are etc. This way we can easily switch between WiX versions as well (assuming the schema, on what we use, hasn't been broken) Just my 2 ct ;) Best regards, Albert van Peppen -Oorspronkelijk bericht- Van: John Ludlow [mailto:john.ludlow...@gmail.com] Verzonden: 30 May 2013 17:06 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Wix dev and regular dev best practices @Mark: Yep, that's what we've gone with, but we had issues getting the right set of properties to set up the paths properly because there's a number of cascading properties. Also, we had issues in that we have to do this with every .wixproj. (I guess we might create a customized .wixproj which has those changes already) Thanks On 30 May 2013 15:28, Freedman, Mark P. mark.freed...@jhuapl.edu wrote: I've recently added WiX to my continuous integration server, Team City. They key is to not have to install stuff on the build machines. WiX includes the install binaries that can be put right in your source tree. However the binaries do not include the files necessary for Custom Actions (CAs), so I had to include some extra files that come with the standard WiX developer install. http://wix.codeplex.com/releases/view/99514 Then, update your .wixproj projects to point to the relative path to your wix binaries. See the Wix tags in PropertyGroup. PropertyGroup Configuration Condition= '$(Configuration)' == '' Debug/Configuration Platform Condition= '$(Platform)' == '' x86/Platform ProductVersion3.7/ProductVersion ProjectGuidz/ProjectGuid SchemaVersion2.0/SchemaVersion
Re: [WiX-users] Wix dev and regular dev best practices
We use a lot of (VS) Project Property Sheets. For WiX we have defined several property sheets for this. Our solution gives us the possibility to change the location where WixTools are etc. This way we can easily switch between WiX versions as well (assuming the schema, on what we use, hasn't been broken) Just my 2 ct ;) Best regards, Albert van Peppen -Oorspronkelijk bericht- Van: John Ludlow [mailto:john.ludlow...@gmail.com] Verzonden: 30 May 2013 17:06 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Wix dev and regular dev best practices @Mark: Yep, that's what we've gone with, but we had issues getting the right set of properties to set up the paths properly because there's a number of cascading properties. Also, we had issues in that we have to do this with every .wixproj. (I guess we might create a customized .wixproj which has those changes already) Thanks On 30 May 2013 15:28, Freedman, Mark P. mark.freed...@jhuapl.edu wrote: I've recently added WiX to my continuous integration server, Team City. They key is to not have to install stuff on the build machines. WiX includes the install binaries that can be put right in your source tree. However the binaries do not include the files necessary for Custom Actions (CAs), so I had to include some extra files that come with the standard WiX developer install. http://wix.codeplex.com/releases/view/99514 Then, update your .wixproj projects to point to the relative path to your wix binaries. See the Wix tags in PropertyGroup. PropertyGroup Configuration Condition= '$(Configuration)' == '' Debug/Configuration Platform Condition= '$(Platform)' == '' x86/Platform ProductVersion3.7/ProductVersion ProjectGuidz/ProjectGuid SchemaVersion2.0/SchemaVersion OutputNameMy Installer/OutputName OutputTypePackage/OutputType WixToolPath..\..\InstallTools\wix\3.7.1224.0\/WixToolPath WixTargetsPath$(WixToolPath)Wix.targets/WixTargetsPath WixTasksPathwixtasks.dll/WixTasksPath /PropertyGroup If you're doing bootstrappers prerequisites with the GenerateBootstrapper command, you can do something similar in your project's bootstrapper to redirect them to a relative path so that the build machine doesn't need to have Visual Studio installed, or whatever puts them in the default Microsoft SDK package. GenerateBootstrapper ApplicationFile=MyInstaller.msi ApplicationName=My App BootstrapperItems=@(BootstrapperFile) ComponentsLocation=Relative CopyComponents=True OutputPath=$(OutputPath) Path=..\..\Bootstrapper / Mark Freedman -Original Message- From: John Ludlow [mailto:john.ludlow...@gmail.com] Sent: Thursday, May 30, 2013 5:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix dev and regular dev best practices We're looking at simply making WiX part of the toolkit you need to build our solutions. We've tried this with some smaller projects and it's worked really well. Developers can follow up on their own impacts, and they can tell when they've broken the install. This increases build quality and frees up install developers from the add a file, remove a file monkey-work we seem to spend 80% of our time doing. Some of the developers grumbled a bit, but it's also been taken positively by others, and everyone gets a bit more respect for their poor, abused install developers. :) In fact, the main issues are related to integrating it into our build system (which is more down to the fact that we don't want to install stuff onto our build system - we want the build to be able to xcopy install whatever it needs). On 29 May 2013 18:46, keith.doug...@statcan.gc.ca wrote: I don't know if our approach will work well long term since we are still developing all of this, but we decided we'd build front end utilities for developers to use with presets implicitly written out to wxs for them (like Manufacturer and expected directories to install to, etc.). This way in principle we could also have developers (or in your case, a build server) drop off their files and an installer build person / process can then pick them up with the front end to WIX. Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -Original Message- From: Drake, David [mailto:david.dr...@wizards.com] Sent: May-29-13 1:41 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Wix dev and regular dev best practices I am attempting to bring an extra layer of automation to my area of concern and have chosen to start packaging up each of our
Re: [WiX-users] Quotes in IniFile lost on rollback
Did you try Microsoft Connect (Category: Visual Studio and .NET Framework)? I saw several installer issues there (although mostly about Visual Studio Installer) Best regards, Albert van Peppen -Oorspronkelijk bericht- Van: Rob Mensching [mailto:r...@robmensching.com] Verzonden: 23 January 2013 15:30 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Quotes in IniFile lost on rollback I honestly don't know. I haven't tried contacting Windows Installer team from outside Microsoft yet. smile/ If you find out, I know I would appreciate a pointer. On Wed, Jan 23, 2013 at 1:41 AM, Rob Hamflett rob_hamfl...@sn.scee.netwrote: On 22/01/2013 15:55, Rob Mensching wrote: You'd have to contact the Windows Installer team. Any idea how to do that? There used to be newsgroups but these were meant to be replaced with forums. There were a posting telling us this would happen and that a future post would give us the details. There wasn't. The newsgroups were just shut down. I hunted through the new forum pages but couldn't find anything about Windows Installer itself (just issues installing other products, etc). I've had another look at the support forums (http://support.microsoft.com/gp/gp_newsgroups_master) and still no luck. I had a look at the Windows Installer Team Blog (http://blogs.msdn.com/b/windows_installer_team/) but there's no contact information (that I can see) and the last post was over 4 years ago. Sowho do I report this to? Is there a more appropriate support site than the public forum? Thanks, Rob -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing service using domain account
Did you tried setting the account of the running the Windows Installer service a domain user who also has local installation rights (local admin rights will do :))? This might not be the answer you're looking for but it may give you a clue ;) Albert -Oorspronkelijk bericht- Van: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com] Verzonden: 18 January 2013 10:52 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Installing service using domain account Using an elevated command prompt the service installs fine, I did add InstallPrivileges=elevated and removed Property Id=MSIUSEREALADMINDETECTION Value=1 / but with no luck still :( -Original Message- From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com] Sent: 17 January 2013 04:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing service using domain account Thank you Mr Rob :) I'm now a step ahead I'm using an embedded UI to implement installing multiple instances of the service. So had to handle the message box in myself in the IEmbeddedUI derived class. Now I'm getting: [SC] OpenSCManager FAILED 5: Access is denied. When installing the service using sc using a non-administrator command prompt window . Now I just need to figure out why my MSI is not getting elevated eusven though I have the Property Id=MSIUSEREALADMINDETECTION Value=1 / property in the WIX. Thanks allot. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 16 January 2013 05:04 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing service using domain account My favorite way to debug this is: 1. Install the MSI with full UI. 2. When the You do not have privileges error pops up when installing the service, leave it there. 3. Use sc.exe to dig around/create the service/etc using the files that are installed. 4. Usually I find that a dll is not installed in the correct place or the username password isn't right. Basically, the Windows Installer doesn't provide useful information in the error message so you have to try to install the service yourself in the context of the installed files and see what better error messages come up. On Wed, Jan 16, 2013 at 4:51 AM, Albert van Peppen alb...@insad.nl wrote: I guess the windows installer service has no rights on the domain as it is run as a local only service (local system account). I think you need some form of impersonification to use a domain user or another option might be to run the windows installer service on an account which has domain access (Add a Installer account to the active directory which has system access to machines and add a domain policy so all machines run the windows installer service with this account). Just my thoughts :) Best regards, Albert van Peppen Senior System Engineer -Oorspronkelijk bericht- Van: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Verzonden: 16 January 2013 13:13 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Installing service using domain account No problem. The serviceaccount property should be in the format domain\user Check the value in the property dump at the end of the verbose log. If the format is wrong, it will issue that error. If you set start=demand, the service won't run at install time. -Original Message- From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com] Sent: 16 January 2013 12:00 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing service using domain account I did try to install the service without starting it after install, but could not figure out how the ServiceInstaller's properties should work? -Original Message- From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com] Sent: 16 January 2013 01:44 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing service using domain account The only (not) usefull thing in the log file is Error 1923. Service 'ServiceName' (ServiceName) could not be installed. Verify that you have sufficient privileges to install system services. MSI (s) (AC:BC) [12:39:28:321]: Product: ProductName -- Error 1923. Service 'ServiceName' (ServiceName) could not be installed. Verify that you have sufficient privileges to install system services. Thanks for the help :) -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 16 January 2013 01:38 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing service using domain account Are there any clues in a verbose log ? -Original Message- From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com] Sent: 16 January 2013 11:30 To: General
Re: [WiX-users] Invalid Custom Action C++ Project Template in WiX 3.7
- Properties-Linker-General-Additional Library Directories: $(WIX)sdk\VS2012\lib\x64 (for 64-bit) Should be: - Properties-Linker-General-Additional Library Directories: $(WIX)sdk\VS2012\lib\$(PlatformName) So it will work for x64 and Win32 (I always rename the x86 folder to Win32 so it is compatible with my environment :)) Best regards, Albert van Peppen -Oorspronkelijk bericht- Van: Phil [mailto:enterthesave-...@yahoo.de] Verzonden: 17 January 2013 14:06 Aan: wix-users@lists.sourceforge.net Onderwerp: [WiX-users] Invalid Custom Action C++ Project Template in WiX 3.7 Hi, the Custom Action C++ Project Template has invalid paths: - Properties-C/C++-General-Additional Include Directories: $(WIX)sdk\VS2010\inc - Properties-Linker-General-Additional Library Directories: $(WIX)sdk\VS2010\lib In WiX Toolset v3.7 directory it is no longer SDK\VS2010. Instead it's SDK\VS2012. The SDK\VS2010\lib directory has been divided up into SDK\VS2012\lib\x64 and SDK\VS2012\lib\x86. Changing the two paths (see above) to the following should fix the unresolved errors in VS: - Properties-C/C++-General-Additional Include Directories: $(WIX)sdk\VS2012\inc - Properties-Linker-General-Additional Library Directories: $(WIX)sdk\VS2012\lib\x64 (for 64-bit) Maybe someone could take care about these changes in future releases. Best regards Phil -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing service using domain account
I guess the windows installer service has no rights on the domain as it is run as a local only service (local system account). I think you need some form of impersonification to use a domain user or another option might be to run the windows installer service on an account which has domain access (Add a Installer account to the active directory which has system access to machines and add a domain policy so all machines run the windows installer service with this account). Just my thoughts :) Best regards, Albert van Peppen Senior System Engineer -Oorspronkelijk bericht- Van: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Verzonden: 16 January 2013 13:13 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Installing service using domain account No problem. The serviceaccount property should be in the format domain\user Check the value in the property dump at the end of the verbose log. If the format is wrong, it will issue that error. If you set start=demand, the service won't run at install time. -Original Message- From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com] Sent: 16 January 2013 12:00 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing service using domain account I did try to install the service without starting it after install, but could not figure out how the ServiceInstaller's properties should work? -Original Message- From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com] Sent: 16 January 2013 01:44 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing service using domain account The only (not) usefull thing in the log file is Error 1923. Service 'ServiceName' (ServiceName) could not be installed. Verify that you have sufficient privileges to install system services. MSI (s) (AC:BC) [12:39:28:321]: Product: ProductName -- Error 1923. Service 'ServiceName' (ServiceName) could not be installed. Verify that you have sufficient privileges to install system services. Thanks for the help :) -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 16 January 2013 01:38 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing service using domain account Are there any clues in a verbose log ? -Original Message- From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com] Sent: 16 January 2013 11:30 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing service using domain account I just added a custom installer class to test if the service will install using InstallUtil, I't doesn't do anything special like custom actions. -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 16 January 2013 01:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing service using domain account What is installutil doing ? The installer won't run any install class code. -Original Message- From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com] Sent: 16 January 2013 11:17 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing service using domain account Hi Peter, the service installs perfectly using InstallUtil, an sc.exe, I have no Idea why it's doing what it is. -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 16 January 2013 01:13 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing service using domain account It's usually a missing dependency dll. A useful troubleshooting step can be to take the set of files and use sc.exe and the services control panel to try and install and configure the service manually on the same machine. -Original Message- From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com] Sent: 16 January 2013 10:56 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Installing service using domain account Hi, I'm trying to install a service using the following WIX fragment and using an existing domain account as the service account. ServiceInstall Id=EventManagerServiceInstall Name=Service1 DisplayName=Service1 Type=ownProcess Interactive=no Start=auto Vital=yes ErrorControl=normal Description= Service Description Account=[SERVICEACCOUNT] Password=[SERVICEACCOUNTPASSWORD
Re: [WiX-users] Bootstrapping SQL Server 2012 Express
You are trying to install the x64 version of SQL Express, are you sure you tested on a x64 Windows? If you were to run this on a x86 (32 bits) system you're installer will fail with something like the error you mention :) Best regards, Albert van Peppen Senior System Engineer -Oorspronkelijk bericht- Van: Nick Ramirez [mailto:nickra...@hotmail.com] Verzonden: 04 October 2012 05:54 Aan: wix-users@lists.sourceforge.net Onderwerp: [WiX-users] Bootstrapping SQL Server 2012 Express I haven't been able to install SQL Server 2012 Express on Windows 7 64-bit using Burn. Has someone been successful with this that can point out what's wrong with my setup? /ExePackage Id=SQLSERVER SourceFile=SQLEXPR_x64_ENU.exe DetectCondition=SqlInstanceFound InstallCommand=$(var.SqlInstallCommand) UninstallCommand=$(var.SqlUninstallCommand) RepairCommand=$(var.SqlRepairCommand) // I am using these parameters for the install command: //ACTION=Install /Q /INDICATEPROGRESS /IACCEPTSQLSERVERLICENSETERMS /FEATURES=SQLEngine /INSTANCENAME=$(var.SqlServerInstance) /SQLSVCACCOUNT=quot;NT AUTHORITY\Network Servicequot; /SQLSYSADMINACCOUNTS=quot;BUILTIN\Administratorsquot;/ The bootstrapper fails with the message: Invalid pointer. The Burn log shows: /Error 0x80004003: Process returned error: 0x80004003 Error 0x80004003: Failed to execute EXE package. Error 0x80004003: Failed to configure per-machine EXE package. Applied execute package: SQLSERVER, result: 0x80004003, restart: None Error 0x80004003: Failed to execute EXE package./ And the SQL log shows, although I don't know if it's relevant: /Saved .Net security policy file 10/03/2012 23:45:50.370 Attempting to release setup mutex 10/03/2012 23:45:50.386 Setup mutex has been released 10/03/2012 23:45:50.402 SQM key not found 10/03/2012 23:45:50.417 Setup closed with exit code: 0x84C40013/ -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bootstrapping-SQL-Server-2012-Express-tp7581083.html Sent from the wix-users mailing list archive at Nabble.com. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix + MSBuild + content files
Hey Cristian.. Do you just installed a virus/Trojan or something? All the email
addresses in your reply got some java script added to it!
Better check your system!
As for everybody else; be very carefull when replying to this mail!
Best regards,
Albert van Peppen
transmission of this e-mail or any attachments, nor responsible for any delay
in receipt.
-Oorspronkelijk bericht-
Van: Cristian Prieto [mailto:kement...@gmail.com]
Verzonden: 21 September 2012 08:53
Aan: General discussion for Windows Installer XML toolset.
Onderwerp: [WiX-users] Wix + MSBuild + content files
BindPaths was exactly what I was looking for...
Thanks
Cristian Prieto
On Fri, Sep 21, 2012 at 3:44 PM, Rob Mensching
r...@robmensching.comjavascript:_e({}, 'cvml', 'r...@robmensching.com');
wrote:
Why do you want to copy your content to the obj directory? Are you
modifying the content in some way as it goes to the obj directory? If
not, I would just add the content folder as a BindPath and let WiX do
all the heavy lifting grabbing the content and including it into the
MSI appropriately.
On Thu, Sep 20, 2012 at 7:51 PM, Cristian Prieto
kement...@gmail.comjavascript:_e({}, 'cvml',
'kement...@gmail.com');
wrote:
So, in this moment my only options would be:
1. Copy manually the bitmap files to the temporary directory where
wix is compiling the msi file, probably in the BeforeBuild Target of
the wixproj file.
2. Modify the wxs or wxi file where the dialog specify the images
and
pass
a $(var.artdirectory) property (as a DefineConstants) in the MSBuild
file.
==
3. (This is the ideal way but it will take time), Modify
wix.targets,
find
the way where I could specify Content / and allow the option to
copy those Content to the temporary compile directory
(obj/longnamehere)... If this is not needed maybe it could be using
another property like OtherFiles /
Am I right or missing something?
Cristian Prieto
On Fri, Sep 21, 2012 at 1:21 AM, Rob Mensching
r...@robmensching.comjavascript:_e({}, 'cvml',
'r...@robmensching.com');
wrote:
Not sure Content items are supported by the wix.targets.
On Wed, Sep 19, 2012 at 10:19 PM, Cristian Prieto
kement...@gmail.comjavascript:_e({}, 'cvml',
'kement...@gmail.com');
wrote:
Hi Wix user list!
I've been trying to solve a very small issue with a manually
created
Wix
proj file and resource files...
My wixproj file (done without Visual Studio but by hand) looks
like
this:
?xml version=1.0 encoding=utf-8? Project
DefaultTargets=Build xmlns=
http://schemas.microsoft.com/developer/msbuild/2003;
ToolsVersion=4.0
PropertyGroup
ParentDirectory$([System.IO.Directory]::GetParent('$(MSBuildProjectD
irectory)'))/ParentDirectory
ParentDirectory
Condition=!HasTrailingSlash('$(ParentDirectory)')$(ParentDirectory)
\/ParentDirectory
ArtDirectory Condition=$(ArtDirectory) ==
''$(ParentDirectory)art/ArtDirectory
ArtDirectory
Condition=!HasTrailingSlash('$(ArtDirectory)')$(ArtDirectory)\/Art
Directory
/PropertyGroup
Import Project=$(WixTargets) /
!-- blah blah blah, common Wix properties --
!-- Art file is here --
ItemGroup
Content Include=$(ArtDirectory)SetupSplash.bmp
LinkSetupSplash.bmp/Link
/Content
/ItemGroup
ItemGroup
Compile Include=$(SourcePath)setup.wxs /
Compile Include=$(SourcePath)SetupDialogs.wxs /
/ItemGroup
/Project
Ok, I just removed a few lines that were too verbose... but as
you
may
see
it looks ok...
Now, The problem is with the art... my project structure looks
like
this:
src
* setup (the wixproj is here)
* art (banners and images are here)
So, in build time the art stuff should be copied to the
temporary
build
directory for the wix package, I know that I could use a copy
task
but
I
want to void it.
I was expecting that using the Content tag the art bmp file
would be
copied
to the temporary wix build directory, but it is not... I already
tried
with
OtherFiles tag...
Is there any way to specify resource files like this without
doing
the
Copy
task manually in MSBuild? am I missing something?
I know that I could solve all of this just creating the wixproj
in
Visual
Studio and linking manually the files, but I really wanted to
avoid
it
(for
learning purposes).
Thanks for any help!
Cristian Prieto
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics Download AppDynamics
Lite for free today:
http
Re: [WiX-users] Installing into the roaming profile
My policy is always to use a per machine install in roaming profile environments.. Besides the 'standard' discussion to determine if roaming profiles are a good idea in an organization. In most cases you will end up with a fragmented active directory; some users are with a roaming profile, others are not (due to several things). So in this scenario a per machine installation will always work, the per user part will likely only consist of some registry work, which you can handle through active directory policies :) Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. Mollevite 28 6931 KG Westervoort The Netherlands -Oorspronkelijk bericht- Van: Osanger, Martin [mailto:martin.osan...@fabasoft.com] Verzonden: 23 April 2012 09:20 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Installing into the roaming profile Thanks for your answer. Is there any other opportunity or what's a better (supported) way to handle roaming profiles? only per machine installations? kind regards, Martin -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Freitag, 20. April 2012 16:16 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing into the roaming profile I've never heard that Windows supported such behavior. Sounds interesting if it does. On Fri, Apr 20, 2012 at 6:37 AM, Osanger, Martin martin.osan...@fabasoft.com wrote: Hello, Is there a Property or anything else I have to set on a per user installation with roaming profiles, so that the installation will be marked as roamed installation, and my setup will be shown in the ARP on another pc? Kind regards, martin -Original Message- From: Osanger, Martin [mailto:martin.osan...@fabasoft.com] Sent: Mittwoch, 18. April 2012 17:55 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Installing into the roaming profile Hello, My current situation (per user installation): I install my files to the AppDataFolder directory (in a subfolder). Now I can switch the pc's and have the installed data (saved to roaming profile) available. But I'm not able to uninstall the files, if I'm not on the pc where I installed the msi file (cached-msi-file and ARP entry was not roamed) Some customers delete their LocalAppDataFolder on logoff, so I have to install it to the AppDataFolder Are there any best practices for creating a WIX based MSI for roaming profiles? Kind regards, martin -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wow!
We always use the binaries zip file for our own use but I recon that the wix36.exe is merely an example of how you can use burn to download msi files with their dependencies/prerequisites. This is good :) When a development department uses this exe to install their wix stuff I think they are going to get in trouble anyway; I believe that one day the ClickOnce functionality of auto updates (from the web) will reemerge (Would love to use that in my builds :)) Not to mention that the msi files and prerequisites of old versions are no longer available on their original places; WiX nowadays only keeps 3 versions online, as I saw, and Microsoft screws up their servers once and a while, generating those nice messages that the information is moved to some other location, which eventually leads to a 404 message ;) About rebuilding a machine to make an exact rebuild of a particular version which is 5 years old; I've been there several times and it is near to impossible if you don't have snapshots of such machines. The Windows Updates ALLWAYS screw things up; I've been searching for a bug in a 4 year old version for 3 weeks; Not because the bug was hard to find but because a .Net 1.1 security update was triggering issues in that old version of our app.. (I don't go into that ;) ) Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. Mollevite 28 6931 KG Westervoort The Netherlands Phone: *31 (0) 26 319 01 50 Email: alb...@insad.nl Website: www.insad.nl -Oorspronkelijk bericht- Van: Rob Mensching [mailto:r...@robmensching.com] Verzonden: 06 March 2012 06:36 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Wow! Dogfooding is very important. It's the way we learn how to do things better than we are doing them now (aka: we make mistakes, get feedback and adjust appropriately). As I noted above, it is pretty clear that we need to focus on improving the /layout experience for the WiX toolset. The WDK did this by incorporating the /layout option into their UI. I expect the answer is for the WiX BA to do the same. Also, I've toyed with putting together a WiX Toolset Build Machine Edition Bundle primarily as a way to dogfood the wixstdba. It would target the build machine scenario where you want the minimal pieces installed and you choose your NETFX since WiX command-line tools support NETFX2 or NETFX4. Basically, this would be a lot like the binaries.zip but with automatic MSBuild integration. Anyway, thank you all for feedback. Definitely helps us find the gaps. On Mon, Mar 5, 2012 at 1:43 PM, Neil Sleightholm n...@x2systems.com wrote: I don't believe there is any value in WiX being a web based install (other than the very valid point about dog fooding the code). In addition the new install forces me to install .Net 4.0 just because the installer needs it; I would like that to be optional as I don't like polluting build machines with more than it really necessary (I know I could manually install the files but would rather not). I work in a company that has very little internet access and have to request downloads, asking someone to download the exe and then run it with the /Layout is a pain. Neil -Original Message- From: Albert van Peppen [mailto:alb...@insad.nl] Sent: 05 March 2012 16:52 To: chr...@iswix.com; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wow! I agree 100% with this. That is basically why I keep the entire history of WiX in my repository (diskspace isn't that expensive nowadays :) ) Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. Mollevite 28 6931 KG Westervoort The Netherlands Phone: *31 (0) 26 319 01 50 Email: alb...@insad.nl Website: www.insad.nl -Oorspronkelijk bericht- Van: Christopher Painter [mailto:chr...@iswix.com] Verzonden: 05 March 2012 16:49 Aan: Rob Mensching; General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Wow! Rob, Regarding /layout, all developers *SHOULD* be doing it despite losing those savings. (Assuming any savings is actually realized based on how many developers are installing the software. ) Anyone involved in the process of developing software ( especially build and release engineering ) should have mature policies regarding the ability to track and archive changes to the development environment.If I have to rebuild a build machine or developer machine I have to be able go back and reinstall all of the tools exactly the way they were originally intended. Relying on content for a web-enabled installer to be available 1,5,10 years down the road ( we still get requests to rebuild VB6 applications! ) is a horrible practice as the external dependency is outside of your control. You must keep your own archive of the tool to ensure the SLA can b met. Everyone who understands CM
Re: [WiX-users] Wow!
I agree 100% with this. That is basically why I keep the entire history of WiX in my repository (diskspace isn't that expensive nowadays :) ) Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. Mollevite 28 6931 KG Westervoort The Netherlands Phone: *31 (0) 26 319 01 50 Email: alb...@insad.nl Website: www.insad.nl -Oorspronkelijk bericht- Van: Christopher Painter [mailto:chr...@iswix.com] Verzonden: 05 March 2012 16:49 Aan: Rob Mensching; General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Wow! Rob, Regarding /layout, all developers *SHOULD* be doing it despite losing those savings. (Assuming any savings is actually realized based on how many developers are installing the software. ) Anyone involved in the process of developing software ( especially build and release engineering ) should have mature policies regarding the ability to track and archive changes to the development environment.If I have to rebuild a build machine or developer machine I have to be able go back and reinstall all of the tools exactly the way they were originally intended. Relying on content for a web-enabled installer to be available 1,5,10 years down the road ( we still get requests to rebuild VB6 applications! ) is a horrible practice as the external dependency is outside of your control. You must keep your own archive of the tool to ensure the SLA can b met. Everyone who understands CM should be doing this. Thus /layout is not only an annoyance to me, it's an antipattern. Chris From: Rob Mensching r...@robmensching.com Sent: Monday, March 05, 2012 9:38 AM To: chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wow! 1. The WiX install *does* chain NETFX 4 in because that is needed before the WiX BA can show UI (since the WiX BA is written in WPF). 2. Dogfooding is the primary reason. 3. We save *significant* bandwidth using Burn because during normal installs it only downloads the portions of the product that you actually need. If *everyone* start using /layout those savings will be lost. smile/ 4. The wixstdba UI is not as functional as we'd like but the web install experience is significantly better. Click download like, survive the web browser screening process (this gets better if we can get WiX signed), click Run and in a second the ~500kb exe is verified and running. Then you have a nice experience while the process downloads and installs only the parts you need. Admittedly, if you want a full layout, then you do Save and have to run another command-line. That scenario is not optimized. 5. ISOs are inferior to /layout because they do not get the built-in robust downloading of Burn. You could use a 3rd party downloader but that 3rd party download cannot verify the downloaded ISO file the way Burn will verify and retry each file. We are moving the cheese a little bit here to challenge the status quo and see if we can't make things better for advanced users and less-advanced users at the same time. My takeaway is that we may have deprioritized the /layout scenario too much and should evaluate that going into the home stretch. On Mon, Mar 5, 2012 at 7:06 AM, Christopher Painter chr...@iswix.com wrote: Other then being allowing WiX to dogfood Burn, what benefit does the WiX installer even gain from using Burn? I thought the old Mondo UI looked just fine and it was a simpler 1 MSI story to boot. My experience with the Burn based WiX installers is that user experience is inferior relative to what it was. It doesn't seem like to me that WiX.msi needed any of the capabilities of Burn as it doesn't do things like install the .NET framework for you or chain multiple packages together. Personally, I still want my Visual Studio in ISO format and when SP1 comes out I'd appreciate a service release that contains it. I get sick of spending 20 minutes to install Visual Studio and 60 minutes to patch it. From: Bruce Cran br...@cran.org.uk Sent: Monday, March 05, 2012 8:43 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wow! On 05/03/2012 14:01, keith.doug...@statcan.gc.ca wrote: The below news is somewhat distressing for those of us who have no Internet connection at all on our development workstations and have to use others (non-development machines) to get such access. Is downloading the /layout way and then (say) moving a directory or something going to work, or does /layout change other things (registry)? If it is going to work, will the procedure be well documented? If not, what do you propose people in my sort of situation to do? (And if Visual Studio 2011 works either of those ways we're going to be in a world
Re: [WiX-users] RegistrySearch
For a x64 MSI this should work, for a Win32 MSI you should use Software\MyApplication\MyApp and let the MSI engine handle the WOW6432 stuff :) Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. -Oorspronkelijk bericht- Van: loyalty Reddy [mailto:reddy.loya...@gmail.com] Verzonden: 30 January 2012 13:34 Aan: wix-users@lists.sourceforge.net Onderwerp: [WiX-users] RegistrySearch Hi, I am using Windows 7, 64 bit. I ma having trouble reading if a key exists in registry. The key that I am using for is in HKLM\Software\Wow6432Node\MyApplication\MyApp. I am using the following code: Property Id=ISPRESENT RegistrySearch Id=PathSearch Root=HKLM Type=raw Key=Software\Wow6432Node\MyApplication\MyApp Name=DbPath Win64=yes / /Property Whether or not DbPath exists, the ISPRESENT is not set. I compared the ISPRESENT value with 1 and #1, nothing works. I also tried not using Wow6432Node, still it fails. what am I doing wrong? Thanks, Reddy -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] RegistrySearch
You can use ISPRESENT in a condition wherever you like; for example in enabling a button in your UI. Read the tutorial on how to use condition on the appropriate place :) Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. -Oorspronkelijk bericht- Van: loyalty Reddy [mailto:reddy.loya...@gmail.com] Verzonden: 30 January 2012 15:51 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] RegistrySearch And how can I check if ISPRESENT is empty or not? On Mon, Jan 30, 2012 at 2:16 PM, Albert van Peppen alb...@insad.nl wrote: For a x64 MSI this should work, for a Win32 MSI you should use Software\MyApplication\MyApp and let the MSI engine handle the WOW6432 stuff :) Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. -Oorspronkelijk bericht- Van: loyalty Reddy [mailto:reddy.loya...@gmail.com] Verzonden: 30 January 2012 13:34 Aan: wix-users@lists.sourceforge.net Onderwerp: [WiX-users] RegistrySearch Hi, I am using Windows 7, 64 bit. I ma having trouble reading if a key exists in registry. The key that I am using for is in HKLM\Software\Wow6432Node\MyApplication\MyApp. I am using the following code: Property Id=ISPRESENT RegistrySearch Id=PathSearch Root=HKLM Type=raw Key=Software\Wow6432Node\MyApplication\MyApp Name=DbPath Win64=yes / /Property Whether or not DbPath exists, the ISPRESENT is not set. I compared the ISPRESENT value with 1 and #1, nothing works. I also tried not using Wow6432Node, still it fails. what am I doing wrong? Thanks, Reddy -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] weekly updates
If someone of the wix team can provide me with the weekly set I am more than happy to put it on my WiX mirror. But as said, there are currently no weekly releases, to my knowledge, so I can't update my mirror. :( Albert van Peppen WiX Mirror: http://madbutcher.dyndns.org/snippets/WiX/ -Oorspronkelijk bericht- Van: Bruce Cran [mailto:br...@cran.org.uk] Verzonden: 30 November 2011 11:22 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] weekly updates On 30/11/2011 09:07, Sean Farrow wrote: Hi: Havv3.6.2221.0? I don't see any and wondered whether updats had moved. Regards Sean.e there been any weekly updates later than That's an impressively mangled email! I believe there's a plan being worked out since the bandwidth quota was being exceeded on Sourceforge and so the weekly builds had to be removed. -- Bruce Cran -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Missing files in http://wix.sourceforge.net/releases/
Hi, When will the next (weekly release?) version appear on Codeplex? Is the given date/time always corrected when a new version is put on Codeplex? And is it possible to mention a buildnumber of the beta available? Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. -Oorspronkelijk bericht- Van: Bob Arnson [mailto:b...@joyofsetup.com] Verzonden: 27 October 2011 04:12 Aan: wix-users@lists.sourceforge.net Onderwerp: Re: [WiX-users] Missing files in http://wix.sourceforge.net/releases/ On 26-Oct-11 16:29, Tobias S wrote: When having a look at http://wix.sourceforge.net/releases/ it seems that there exists nothing else than the RSS feeds (No WiX.exe , msi ...) We won't be putting them on SourceForge any more; SF has a bandwidth quota we were exceeding with all the downloads. The beta build is on Codeplex. -- sig://boB http://joyofsetup.com/ -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Missing files in http://wix.sourceforge.net/releases/
Or check out one of the following (unofficial) mirrors: :) http://madbutcher.dyndns.org/snippets/WiX/ http://bluestop.org/wix Albert -Oorspronkelijk bericht- Van: Bob Arnson [mailto:b...@joyofsetup.com] Verzonden: 27 October 2011 04:12 Aan: wix-users@lists.sourceforge.net Onderwerp: Re: [WiX-users] Missing files in http://wix.sourceforge.net/releases/ On 26-Oct-11 16:29, Tobias S wrote: When having a look at http://wix.sourceforge.net/releases/ it seems that there exists nothing else than the RSS feeds (No WiX.exe , msi ...) We won't be putting them on SourceForge any more; SF has a bandwidth quota we were exceeding with all the downloads. The beta build is on Codeplex. -- sig://boB http://joyofsetup.com/ -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 3.6 beta installation failed
Hi Rob, I saw that you have deleted all versions from sourceforce; only the RSS files are there :( Can you provide the last weekly build to me, so I can put them into my archive, in this case people can at least found it on more than one place :) Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. -Oorspronkelijk bericht- Van: Rob Mensching [mailto:r...@robmensching.com] Verzonden: 25 October 2011 17:42 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] WiX 3.6 beta installation failed Hmm, I thought we fixed the bandwidth problem by removing most of this content. Albert, can you refresh your browser to see if you're just hitting a cached page or not. Maksim, can you look in your %TEMP% folder and paste in the failing log file? I'd like to understand why the project aggregator is being downloaded if you already have it installed (I thought we fixed tha bug). I'll look for a work around at the same time. On Tue, Oct 25, 2011 at 1:36 AM, Albert van Peppen alb...@insad.nl wrote: Hi, this is most likely because there is an issue at wix.sourceforce.org; When you go to that site you'll see a message like 'This project has been temporarily blocked for exceeding its bandwidth threshold' So maybe someone has the power to fix this??? I can't download the last weekly build also... Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. -Oorspronkelijk bericht- Van: maksim.vazhe...@emc.com [mailto:maksim.vazhe...@emc.com] Verzonden: 25 October 2011 08:27 Aan: wix-users@lists.sourceforge.net Onderwerp: [WiX-users] WiX 3.6 beta installation failed Hi, Is there any way now to download full package for WiX 3.6.beta installation (which doesn't try to download something during the installation)? I tried to install Wix36.exe but it failed with the following error: Error 0x80070002: Failed to download payload from URL:' http://wix.sourceforge.net/releases/data/ProjectAggregator2.msi' (By the way I have already ProjectAggregator2 installed). Thanks, Maksim -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WiX Weekly update is missing / message from sourceforge
I've modified the title of this thread, since it has nothing more to do with installation problem :) My archive, for those who didn't knew yet, is at http://madbutcher.dyndns.org/snippets/WiX/ I try to keep it up to date as much as possible :) Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. -Oorspronkelijk bericht- Van: Albert van Peppen [mailto:alb...@insad.nl] Verzonden: 26 October 2011 09:28 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] WiX 3.6 beta installation failed Hi Rob, I saw that you have deleted all versions from sourceforce; only the RSS files are there :( Can you provide the last weekly build to me, so I can put them into my archive, in this case people can at least found it on more than one place :) Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. -Oorspronkelijk bericht- Van: Rob Mensching [mailto:r...@robmensching.com] Verzonden: 25 October 2011 17:42 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] WiX 3.6 beta installation failed Hmm, I thought we fixed the bandwidth problem by removing most of this content. Albert, can you refresh your browser to see if you're just hitting a cached page or not. Maksim, can you look in your %TEMP% folder and paste in the failing log file? I'd like to understand why the project aggregator is being downloaded if you already have it installed (I thought we fixed tha bug). I'll look for a work around at the same time. On Tue, Oct 25, 2011 at 1:36 AM, Albert van Peppen alb...@insad.nl wrote: Hi, this is most likely because there is an issue at wix.sourceforce.org; When you go to that site you'll see a message like 'This project has been temporarily blocked for exceeding its bandwidth threshold' So maybe someone has the power to fix this??? I can't download the last weekly build also... Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. -Oorspronkelijk bericht- Van: maksim.vazhe...@emc.com [mailto:maksim.vazhe...@emc.com] Verzonden: 25 October 2011 08:27 Aan: wix-users@lists.sourceforge.net Onderwerp: [WiX-users] WiX 3.6 beta installation failed Hi, Is there any way now to download full package for WiX 3.6.beta installation (which doesn't try to download something during the installation)? I tried to install Wix36.exe but it failed with the following error: Error 0x80070002: Failed to download payload from URL:' http://wix.sourceforge.net/releases/data/ProjectAggregator2.msi' (By the way I have already ProjectAggregator2 installed). Thanks, Maksim -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX Weekly update is missing / message from sourceforge
Best regards, I would like to automate this but on codeplex there are several obstacles to take: - You need to download via the website and accept the agreement (not easy to automate, that's the idea of it I suppose) - There is no history.txt so I need to get that one out of the source-zip file On sourceforce I haven't yet tried, but as far as I understand, the files will no longer be put on there? If you give me a (deep)link where I automatically can download the latest set, I'm happy to automate the mirroring :) Albert van Peppen Senior System Engineer Insad Grafisch b.v. -Oorspronkelijk bericht- Van: Rob Mensching [mailto:r...@robmensching.com] Verzonden: 26 October 2011 16:54 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] WiX Weekly update is missing / message from sourceforge Interesting. If you guys are willing to mirror the releases, that may be really useful in spreading the download burden. On Wed, Oct 26, 2011 at 2:38 AM, Bruce Cran br...@cran.org.uk wrote: On 26/10/2011 09:17, Albert van Peppen wrote: I've modified the title of this thread, since it has nothing more to do with installation problem :) My archive, for those who didn't knew yet, is at http://madbutcher.dyndns.org/snippets/WiX/ I try to keep it up to date as much as possible :) I've also started creating a mirror at http://bluestop.org/wix - currently just a few files from codeplex exist at http://bluestop.org/wix/releases/ . I think I have plenty of bandwidth to support it. -- Bruce Cran -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 3.6 beta installation failed
Hi, this is most likely because there is an issue at wix.sourceforce.org; When you go to that site you'll see a message like 'This project has been temporarily blocked for exceeding its bandwidth threshold' So maybe someone has the power to fix this??? I can't download the last weekly build also... Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. -Oorspronkelijk bericht- Van: maksim.vazhe...@emc.com [mailto:maksim.vazhe...@emc.com] Verzonden: 25 October 2011 08:27 Aan: wix-users@lists.sourceforge.net Onderwerp: [WiX-users] WiX 3.6 beta installation failed Hi, Is there any way now to download full package for WiX 3.6.beta installation (which doesn't try to download something during the installation)? I tried to install Wix36.exe but it failed with the following error: Error 0x80070002: Failed to download payload from URL:'http://wix.sourceforge.net/releases/data/ProjectAggregator2.msi' (By the way I have already ProjectAggregator2 installed). Thanks, Maksim -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Request for comment: Where to put Burn log files.
I would favor a property which can be tweaked. My applications that are installed all use their own logging folder, so it only makes sense to me that the installer logs are stored her as well. My applications have a special support tool which collects all sort of data for customer support, including the logdata. At present I always start the MSIExec with logging to a specific log folder (Somewhere like %LOCALAPPDATA%\[MANUFACTER]\[PRODUCTNAME]\Logs) from my bootstrapper. The bootstrapper logs (when enabled) are stored in %LOCALAPPDATA%\[MANUFACTER]\General name for bootrstrapper\Logs. Hope this helps :) Regards, Albert van Peppen Burn does provide a Variable (WixBundleLog) that points to the log location. There is no directory tag so I'm not sure what you are referring to. Ideally, I want a single location where logs are placed so that we can easily ask people, Please send us the logs from folder X to start debugging. Having every bundle put logs in a unique location will make life more difficult. On Thu, Sep 29, 2011 at 2:27 PM, John Bergman john.berg...@xpedienttechnologies.com wrote: I'd like to be able to put this in the markup within the directory tag, and then let WiX's magic decide how that is implemented; This way the log is available and in a known location to the application for error reporting and troubleshooting by anyone, and there's no risk of it getting deleted. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Thursday, September 29, 2011 3:23 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Request for comment: Where to put Burn log files. I need your opinion. Currently Burn logs to the %TEMP% folder by default (you can override it with the -log/-l switch). This is great because most people expect this sort of temporary data to live in the log file and Windows provides built in mechanisms to clean out the %TEMP% folder should it get big. Unfortunately, Windows Server clears out the %TEMP% folder on reboot. This makes %TEMP% a really bad place to store log files if your bundle requires a reboot for any reason. So, I need a new location to put log files. The best idea I've had thus far is to create a new folder in %LOCALAPPDATA%\Logs and put log files there. This folder will be persisted over reboots but doesn't have any built in way to be cleaned out (the user would have to figure it out, or install a WiX disk clean up wizard extension that does not yet exist smile/). Does anyone have better ideas? Any proposed solution needs to work on WinXP-SP2+. -- virtually, Rob Mensching - http://RobMensching.com LLC -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to detect a x64 SQL Server with a x32 wix setup
Hi, I have previously determined if a local SQL server instance is installed by enumerating the REG_MULTI_SZ value HKLM\Software\Microsoft\Microsoft SQL Server\InstalledInstances Beyond that any further SQL instance specific setup/checking I have performed thru WMI. This approach has worked for both 32 or 64-bit SQL server editions. Do you specifically need to know the edition or not care? Regards, Rob. Hi, I wrote a CA for handling this, please check out http://madbutcher.dyndns.org/snippets/SQLMsiCA If you browse to the code you'll understand what problems you will encounter if you want to build your own CS :) There are some more issues that 32/64 bits if you are on a network with SQL2000 and SQL2005/2008/2010 combinations, especially when one ore more SQL2000 instances are hidden. About the last one even Microsoft hasn't got an answer (scan the MSDN forum for it if you're interested in the problems) Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. Email: alb...@insad.nl Phone: *31 (0) 26 319 01 50 Insad Grafisch b.v. Mollevite 28 6931 KG Westervoort The Netherlands Website: www.insad.nl -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Abdoulaye Souleymanou/RSD ist außer Haus.
It's easy; just add another spamrule in your mail read app :) Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. Email: alb...@insad.nl Phone: *31 (0) 26 319 01 50 Insad Grafisch b.v. Mollevite 28 6931 KG Westervoort The Netherlands Website: www.insad.nl -Oorspronkelijk bericht- Van: Rob Mensching [mailto:r...@robmensching.com] Verzonden: 01 July 2011 16:23 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Abdoulaye Souleymanou/RSD ist außer Haus. If this continues over the long weekend, I will. 2011/7/1 Rob Hamflett r...@snsys.com If we're going to get a whole flood of these for the next month, can someone with admin access please remove Abdoulaye from the list (and possible remove the current posts from the newsgroup)? No offence to Abdoulaye, but I've had 35 of these already, and it's only 10:25am on the first day of what looks like a month long holiday. Thanks, Rob On 01/07/2011 09:36, abdoulaye.souleyma...@rohde-schwarz.com wrote: Ihre Nachricht betreffend: / Your Mail about: Re: [WiX-users] Can an x86 msi create a registry key under HKEY_CLASSES_ROOT\Wow6432Node on x64 systems? Ich werde ab 01.07.2011 nicht im Büro sein. Ich kehre zurück am 04.08.2011. Ich werde Ihre Nachricht nach meiner Rückkehr beantworten. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Getting SQL Server instance name?
HKLM SOFTWARE\Microsoft\Microsoft SQL Server returns a MULTI_SZ so you'll need to parse it to a string first... But how should your code function when there are more instances installed -Oorspronkelijk bericht- Van: Pally Sandher [mailto:pally.sand...@iesve.com] Verzonden: maandag 7 februari 2011 14:41 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Getting SQL Server instance name? Check a verbose log. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: kim [mailto:contactme...@gmail.com] Sent: 04 February 2011 19:06 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Getting SQL Server instance name? Using WIX i would like to know what instance of SQL Server is installed on target machine. If installed, get the name and set it as one of the property value to be displayed in my custom dialog. I am using the following code to find if SQL Server is installed and using SQLSERVER property to set the my control's value, but its coming up as empty: Property Id=SQLSERVER RegistrySearch Id=SQLServer Root=HKLM Key=SOFTWARE\Microsoft\Microsoft SQL Server Type=raw Name=InstalledInstances//Property Condition Message=Error: This application requires Microsoft SQL Server 2005/2008 to be installed. Please install Microsoft SQL Server 2005/2008 and run this installer again.SQLSERVER/Condition Custom Dialog: Control Type=Text Id=lblInstanceName Width=100 Height=14 X=22 Y=124 Text=Instance Name : TabSkip=yes / Control Type=Edit Id=txtInstanceName Width=150 Height=15 X=22 Y=139 Property=SQLSERVER Text=[SQLSERVER] / Can someone please guide me what am I doing wrong here? Thanks! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Getting-SQ L-Server-instance-name-tp5993646p5993646.html Sent from the wix-users mailing list archive at Nabble.com. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Getting SQL Server instance name?
HKLM\\SOFTWARE\Microsoft\Microsoft SQL Server\InstalledInstances offcourse :) Check out: http://madbutcher.dyndns.org/snippets/SQLMsiCA for a nice example on how to let the user select a SQL instance installed on this computer or, if you wish, any computer in the network. -Oorspronkelijk bericht- Van: Albert van Peppen [mailto:alb...@insad.nl] Verzonden: maandag 7 februari 2011 15:11 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Getting SQL Server instance name? HKLM SOFTWARE\Microsoft\Microsoft SQL Server returns a MULTI_SZ so you'll need to parse it to a string first... But how should your code function when there are more instances installed -Oorspronkelijk bericht- Van: Pally Sandher [mailto:pally.sand...@iesve.com] Verzonden: maandag 7 februari 2011 14:41 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Getting SQL Server instance name? Check a verbose log. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: kim [mailto:contactme...@gmail.com] Sent: 04 February 2011 19:06 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Getting SQL Server instance name? Using WIX i would like to know what instance of SQL Server is installed on target machine. If installed, get the name and set it as one of the property value to be displayed in my custom dialog. I am using the following code to find if SQL Server is installed and using SQLSERVER property to set the my control's value, but its coming up as empty: Property Id=SQLSERVER RegistrySearch Id=SQLServer Root=HKLM Key=SOFTWARE\Microsoft\Microsoft SQL Server Type=raw Name=InstalledInstances//Property Condition Message=Error: This application requires Microsoft SQL Server 2005/2008 to be installed. Please install Microsoft SQL Server 2005/2008 and run this installer again.SQLSERVER/Condition Custom Dialog: Control Type=Text Id=lblInstanceName Width=100 Height=14 X=22 Y=124 Text=Instance Name : TabSkip=yes / Control Type=Edit Id=txtInstanceName Width=150 Height=15 X=22 Y=139 Property=SQLSERVER Text=[SQLSERVER] / Can someone please guide me what am I doing wrong here? Thanks! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Getting-SQ L-Server-instance-name-tp5993646p5993646.html Sent from the wix-users mailing list archive at Nabble.com. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix upgrade process does not consider 4th part of the version string
For the reason mentioned, we use the bootstrapper for handling the correct action on the fourth part of the version string. This is not too hard and you can show a 'Internal release', 'Alpha release' or 'Beta release' logo when installing as well :) Albert van Peppen -Oorspronkelijk bericht- Van: Christopher Painter [mailto:chr...@deploymentengineering.com] Verzonden: zondag 16 januari 2011 18:18 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Wix upgrade process does not consider 4th part of the version string Rob- The comment to not use MSI aside, it is pretty hard for me to justify to build engineers, software developers and product managers that yes they can build DLL's as 1.0.0.0 and 1.0.0.1 but that they can't build their MSI as 1.0.0.0 and 1.0.0.1 because MSI will see it as 1.0.0 and 1.0.0. I'm pretty much left saying you are right, that is the tail wagging the dog. But that's the framework we use so deal. I'd appreciate your detailed thoughts on this. Chris Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me - Original Message From: Rob Mensching r...@robmensching.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Sun, January 16, 2011 10:55:00 AM Subject: Re: [WiX-users] Wix upgrade process does not consider 4th part of the version string Terrifying. You must be in some really controlled environments for that to work out well. smile/ The Windows Installer (for whatever reason) chose to ignore the 4th version. It boggles my mind that management gets to decide a versioning scheme that won't work. You might as well pick a different installation technology that meets the requirement than the Windows Installer if something so fundamental as versioning is going to be ignored. The cognitive dissonance here kills me. smile/ On Sun, Jan 16, 2011 at 7:07 AM, Neil Sleightholm n...@x2systems.comwrote: I have a similar scenario and my workaround is to allow same version upgrades. This means 3.0.1.14900 will upgrade 3.0.1.14500 (but it also means 3.0.1.14500 will upgrade 3.0.1.14900 which might be undesirable). In WiX 3.5 you can do this by setting MajorUpgrade/@AllowSameVersionUpgrades - otherwise just set the appropriate fields in the Upgrade table. Neil -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 14 January 2011 21:33 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Wix upgrade process does not consider 4th part of the version string Hi, I have an installer having 4-part version strings. Our installer stops installation if a newer version is already installed on the system. We often have alpha/beta releases of our product in which we do not change first 3 parts of the product. Suppose we have two releases of our product : Release1 : 3.0.1.14500(Alpha) Release2 : 3.0.1.14900(Beta) Our users are able to install alpha release even if beta is already present on their systems. I went through this article http://wix.sourceforge.net/manual-wix3/major_upgrade.htm see the paragraph having text Windows Installer only uses the first 3 parts of the Is there any way in Wix to take care of 4th part of version string in upgrade process ? OR Do I need to dive into clumsy custom action thing to take care this ? Regards, Sanjay Rao -- Sanjay Rao Digital Media Group, Interra Systems s...@interrasystems.com Phone: +1-408-873-1212 http://www.interrasystems.com -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how
Re: [WiX-users] Upgrading wixproj
Hi, I keep an extensive archive of older versions of WiX at http://madbutcher.dyndns.org/snippets/WiX/ In case anyone needs it :) Regards, Albert van Peppen -Oorspronkelijk bericht- Van: Rob Mensching [mailto:r...@robmensching.com] Verzonden: vrijdag 7 januari 2011 17:37 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Upgrading wixproj Unfortunately, no. That build was a (now very old) intermediate release. We don't save intermediate releases for very long. We don't have the resources to support drops at all points in time of the development cycle. If you're using the the development branch of the WiX toolset (which both WiX v3.5 and WiX v3.6 are) then you need to upgrade regularly. I know it's a pain but that is the cost to pay while being able to see and participate in every step of the development process. Also note that if you stay current and find issues, it is easier for us to accommodate your needs. -- virtually, Rob Mensching - http://RobMensching.com LLC On Wed, Jan 5, 2011 at 10:48 AM, Eric Goforth eric.gofo...@gmail.comwrote: Thanks Rob, I'd like to avoid having to upgrade all our projects at this time. Is there a version at http://wix.sf.net/releases that will work with my \Microsoft\WiX\v3.5\Wix2010.targets style wix projects? -Eric On Wed, Jan 5, 2011 at 2:31 AM, Rob Mensching r...@robmensching.com wrote: And to answer the actual question, I think 3.5.1419 has rolled off. That build is almost a year out of date, we don't keep development builds around for more than a few months typically (and less when we get to Escrow like with WiX v3.5). On Tue, Jan 4, 2011 at 11:30 PM, Rob Mensching r...@robmensching.com wrote: Weekly release are at http://wix.sf.net/releases. Yes, I know, we need to clean all this stuff up. Sorry. Eventually http://wixtoolset.org will have all the information. On Tue, Jan 4, 2011 at 2:14 PM, Eric Goforth eric.gofo...@gmail.com wrote: Hmmm, I'm on codeplex (http://wix.codeplex.com/releases/view/44406) right now and I don't see a way to download 3.5.1419, is it possible to do that? I checked out http://wixtoolset.org/ too, but it looks like that's just a place-holder site for now. -Eric On Tue, Jan 4, 2011 at 5:03 PM, Eric Goforth eric.gofo...@gmail.com wrote: Thanks, it looks like he has 3.5.1419, I have 3.5.2415. On Tue, Jan 4, 2011 at 4:40 PM, jhennessey jack.hennes...@hyland.com wrote: All builds will say Windows Installer XML Toolset 3.5 but you need to check the actual build version (I think the latest is 3.5.2430.0). v3.x\Wix.targets is what is current -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading- wixproj-tp5890061p5890254.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl
Re: [WiX-users] Install skips welcome page
Hi, I think that since the installation will run only once or so, the extra click on Next should be not a problem to most users. The fact that the installation behaves differently is more of an issue, this will generate some additional stress to our helpdesk I fear. I think that the entire issue might be off the table when we're using a bootstrapper with interface. In this case the welcome and license dialog might be handled in the bootstrapper. This because you want to present the user the license agreement before the user selects the x86 or the x64 installation, for example. But I think that it should be optional to show the welcome dialog with a Next button or not. I think it shouldn't be that hard to implement a property for it? (And I wouldn't care if it is default on or off, as long as I can put it on or off from my bootrstrapper :) ) Regards, Albert van Peppen -Oorspronkelijk bericht- Van: Tobias S [mailto:tobias.s1...@gmail.com] Verzonden: maandag 29 november 2010 14:30 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Install skips welcome page Hi, From my point of view the concept to kick the Welcome dialog is ok if there is no additional information than on the default dialog sets. Usability clearly says if something doesn't provide additional information kick it. And (IMO) the Welcome dialog is one of these dialogs as there is not much more information in the Welcome and LicenseAgreement dialog of default UI sets compared to the AdvancedWelcomeEulaDlg from WixUI_Advanced. I mean by default it says The Setup Wizard will install [ProductName] on your computer. Click Next to continue or Cancel to exit the Setup Wizard.. And the WixUI_Advanced says Click Install to install the product with default options just for you. Click Advanced to change installation options. So actually I think AdvancedWelcomeEulaDlg is almost the perfect dialog for starting an installation (IMO the dialog set should be only as a per machine installation set). Maybe to have no information loss here a formulation like Please accept the License Agreement and click Install to install [ProductName] with the default installation options on your computer. To change installation options click on Advanced. To exit the Setup Wizard click Cancel might be better. Actually I also click several times each day through the dialog set and also don't care anymore about the number of dialogs the installer shows. But in fact, even this is a well established practice, the users (and here the simplicity, or less mouse clicks, to install an application) should be considered and maybe both dialog sets should be offered. Tobias 2010/11/29 David Watson dwat...@sdl.com: Hi, We have been following the scheme that Rob is suggesting for a few years, I think in our main product we are down to two dialogue in most scenarios. We have a welcome/license page and then a ready to install page. I have noticed other applications doing this too, Visual studio setup has lots of information about licensing etc on the initial page. Dave -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: 29 November 2010 08:53 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install skips welcome page Lack of welcome page is what I find retrograde. I guess it is personal opinion, I am quite happy with both the welcome and licence dialogs - it is what other installs do so I prefer not to show my users something different. Jumping straight to licence just looks odd as I haven't seen it before and I had to explain the change to testers and tell them it wasn't a bug. (As a side issue I would like to see the licence dialog being optional in the standard WiX release but that is just so I don't have to code it myself - it is also something that is regularly requested on the user list.) Neil Neil Sleightholm X2 Systems Limited n...@x2systems.com mailto:n...@x2systems.com From: Rob Mensching [mailto:r...@robmensching.com] Sent: Mon 29/11/2010 00:39 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install skips welcome page What do you find retrograde? The license page or the lack of welcome page? Personally, I find clicking through a bunch of pages just to get the install started retrograde. Wizard'97 was a long time ago, I think we can move beyond it. The first page clearly needs to say what is being installed. Ideally, the Install button should be availble as well. If you have to have a license before the Install button can do it's thing, then so be it. After that, progress is probably required (unless your install is fast enough to not need it). Then, it seems, you still need a final confirmation whether the install succeeded or failed. I still would like to push in the direction that instead of a success page that the application
Re: [WiX-users] Custom Action
Hi, First of all the path C:\WINDOWS\System32 should be C:\WINDOWS\SysWOW64 where C:\WINDOWS can be any path where Windows is installed. Therefore you should use the appropriate properties. Secondly, using RD ..etc.. implies the use of the commandline which is (imho) bad practice.. So basically, I think you should drop that idea. Regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. The Netherlands -Oorspronkelijk bericht- Van: sagar shinde [mailto:sagar.i...@gmail.com] Verzonden: donderdag 4 november 2010 6:48 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Custom Action Hi, I have mentioned in mail that my vbscript is working fine. there is no error in it.but i still want to know why this cmd custom action is failing My earlier code was containing custom action which calls cmd. *i have two different installers for 32 bit Os and 64 bit Os which cantains same custom action as shown in below The main Problem is this custom action fails in 64 bit Os and works in 32 bit Os.Why it is so?* Binary Id=cmdexe SourceFile=C:\WINDOWS\system32\cmd.exe / Custom Action=DeleteFolder After=InstallFinalizeInstalled/Custom CustomAction Id=DeleteFolder BinaryKey=cmdexe ExeCommand='RD /S /Q C:\Program Files\ul' Execute=immediate Return=check / Thank you. On Wed, Nov 3, 2010 at 9:55 PM, Wilson, Phil phil.wil...@invensys.comwrote: This is very confusing. Your log of the error appears to be about your earlier custom action , command: /c RD /S /Q C:\Program Files\ultac , not your new VBScript. It's still true that on UAC systems an immediate custom action will run with limited user privilege even if your are administrator, and not be able to remove anything in the Program Files folder. And if WiX RemoveFolder wasn't working because the folder contained some files, that's what the WiX RemoveFile element is for. Phil Wilson -Original Message- From: sagar shinde [mailto:sagar.i...@gmail.com] Sent: Wednesday, November 03, 2010 2:41 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Custom Action Hi, Thanks for replay,I got one solution to delete Folders WiX RemoveFolder was unable to delete folders as it was containing user data. So i was trying to delete that folder with cmd which was failing to delete folders so i created property with VBScript and folders are deleted successfully This is code for property Property Id=vbscript ![CDATA[ Function main() strFolderPath = Session.Property(VERSIONPATH) Set fso=CreateObject(Scripting.FileSystemObject) if fso.FolderExists(strFolderPath) Then fields = Split(strFolderPath,\) For i = 0 To UBound(fields)-1 if i UBound(fields)-1 then FolderPath=FolderPath fields(i) \\ else FolderPath=FolderPath fields(i) End if Next fso.DeleteFolder FolderPath else msgbox Folder not deleted End if End Function ]] /Property And called this *property in custom action* CustomAction Id =DeleteFolder VBScriptCall=main Property=vbscript/CustomAction *This was my earlier custom action by which i was trying to delete folders* CustomAction Id=DeleteUBFolder BinaryKey=cmdexe ExeCommand='/c RD /S /Q [VERSIONPATH]' Execute=immediate Return=check / this custom action is working fine with 32 bit Os but it is faling in 64 bit Os This is Error i am getting There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: DeleteFolder, location: C:\Windows\Installer\MSIE2A4.tmp, command: /c RD /S /Q C:\Program Files\ultac DeleteFolder. Return value 3. INSTALL. Return value 3. Error code 3 :- is for invalid path If i am doing any thing wrong in this custom action plese sugget me the correct way to do it Thank you. On Tue, Nov 2, 2010 at 11:08 PM, Wilson, Phil phil.wil...@invensys.com wrote: You're getting an error, you say. What is the error? The folder you're trying to remove, exactly what is this folder. There's an obvious explanation in a couple of areas. First, it's a 64-bit path in a folder that's not the same as a 32-bit system. Or your 64-bit system is a UAC system and your immediate custom just doesn't have the rights to remove the folder. The right way to do this has been pointed out, WiX RemoveFolder. If that didn't work, that was the time to ask questions about it. Why go off in the wrong
Re: [WiX-users] Calling a managed custom action from a UI control
Hi, I suggest you read the manual, tutorial or the book on WiX or at least look at the online help on MSI. The part about properties should help you well underway. Same for the initial problem Chris has. Or to be in your language: RTFT or RTFM :) Albert van Peppen Senior System Engineer Insad Grafisch b.v. The Netherlands -Oorspronkelijk bericht- Van: sagar shinde [mailto:sagar.i...@gmail.com] Verzonden: maandag 25 oktober 2010 13:57 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Calling a managed custom action from a UI control hi i am trying something similer to this,i want to delete folders at uninstall time,i have one VBscript for that, but how can i set path for that or how ur VBscript is getting path in ur code. how u called ur VBscript from wix installer On Wed, Oct 20, 2010 at 1:06 AM, McKinnon, Chris cmckin...@atb.com wrote: You are absolutely right. I just wanted to keep all my custom actions in the same DLL. I have two other actions for encrypting and decrypting the .config files. I switched my code to a VBScript and it works nicely. Here's the script if anyone is interested: Function DirectoryExists() Dim path, fso path = Session.Property(_DirectoryExists_Path) Set fso = CreateObject(Scripting.FileSystemObject) If (fso.FolderExists(path)) Then Session.Property(_DirectoryExists_Result) = yes Else Session.Property(_DirectoryExists_Result) = no End If DirectoryExists = ERROR_SUCCESS End Function It's still frustrating that the DLL approach didn't work. Thanks, Chris McKinnon -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Tuesday, October 19, 2010 11:38 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Calling a managed custom action from a UI control Are you really cranking up all this infrastructure just to see if a directory exists? There's got to be a simpler way, even if it's only a horrible little VBScript 10 line custom action. At least that is natively supported by Windows Installer. Phil Wilson -Original Message- From: McKinnon, Chris [mailto:cmckin...@atb.com] Sent: Tuesday, October 19, 2010 8:58 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Calling a managed custom action from a UI control Hi Blair, No log entries, unfortunately. I've let my installer sit spinning for about 20-30 minutes. I could let it sit longer but I don't think that would help. I'm going to try my installer on a Windows 2000 Professional workstation when I have a chance today. Let me know if there's anything else I can do to track down this issue. Thanks, Chris McKinnon -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, October 19, 2010 12:06 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Calling a managed custom action from a UI control Whenever Windows Installer launches a DLL-type custom action, it does so from a separate msiexec.exe process instance (sandboxing the custom action code, if you will). However, because this sandbox process may be reused, and because loading pre-4.x CLR runtimes marks the process preventing a different runtime from ever being loaded, DTF runs the assemblies in their own child process. When you build a DTF custom action assembly, a native stub is built/modified that contains an entry point for each method with a CustomActionAttribute, along with being packed with your assembly, config, and dependencies. This stub sends a copy of itself to RunDll.exe after creating a two-way communications pipe to communicate with its child process (which allows for querying the session for properties, running queries, etc.). The stub in the (grandchild) process establishes communication with its parent (the stub in the sandbox), extracts its payload, loads the indicated CLR, loads your assembly into an AppDomain, and finally calls your code (this is where the transition into managed code finally occurs). You seem to be hanging somewhere in this paragraph (at least until you kill the rundll.exe process). Are there any System or Application event log entries that may explain/describe some failure with the CLR spinup? Unfortunately calling MsiProcessMessage is documented to not work from a DoAction so any error or progress logging performed by the stub won't show up. -Original Message- From: McKinnon, Chris [mailto:cmckin...@atb.com] Sent: Monday, October 18, 2010 10:52 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Calling a managed custom action from a UI control Thanks for the ideas Steve. I tried running my code in a separate thread, like yours, but it still hangs. I'm running on Windows Vista Business 32-bit. I noticed, by accident, that in Process Explorer when the custom action starts up
Re: [WiX-users] Calling a managed custom action from a UI control
Hi, The reason why not to use RemoveFolder might be valid (I wrote my own CA for exactly the same reason) but it doesn't mean that you shouldn't know anything about properties as this is where the problem lies in the VB script as given by Chris. I think this is one of the basic need-to-knows when working with WiX (and there are more important need-to-knows :) ). Personally I use a C++ CA in a staticly linked DLL which has more to offer than just this specific function. Another benefit is that it runs much -and I mean MUCH- faster than VB script as wel that it has better errorhandling possibilities etc. Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. The Netherlands -Oorspronkelijk bericht- Van: sagar shinde [mailto:sagar.i...@gmail.com] Verzonden: maandag 25 oktober 2010 15:31 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Calling a managed custom action from a UI control hi thanks for reply, but i can not use this removefolder as my installer will create new folders and diffrent files will be created in that folder by user so RemoveFolder will not work in this case is ter any other option thank you. On Mon, Oct 25, 2010 at 6:00 PM, Albert van Peppen alb...@insad.nl wrote: Hi, I suggest you read the manual, tutorial or the book on WiX or at least look at the online help on MSI. The part about properties should help you well underway. Same for the initial problem Chris has. Or to be in your language: RTFT or RTFM :) Albert van Peppen Senior System Engineer Insad Grafisch b.v. The Netherlands -Oorspronkelijk bericht- Van: sagar shinde [mailto:sagar.i...@gmail.com] Verzonden: maandag 25 oktober 2010 13:57 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Calling a managed custom action from a UI control hi i am trying something similer to this,i want to delete folders at uninstall time,i have one VBscript for that, but how can i set path for that or how ur VBscript is getting path in ur code. how u called ur VBscript from wix installer On Wed, Oct 20, 2010 at 1:06 AM, McKinnon, Chris cmckin...@atb.com wrote: You are absolutely right. I just wanted to keep all my custom actions in the same DLL. I have two other actions for encrypting and decrypting the .config files. I switched my code to a VBScript and it works nicely. Here's the script if anyone is interested: Function DirectoryExists() Dim path, fso path = Session.Property(_DirectoryExists_Path) Set fso = CreateObject(Scripting.FileSystemObject) If (fso.FolderExists(path)) Then Session.Property(_DirectoryExists_Result) = yes Else Session.Property(_DirectoryExists_Result) = no End If DirectoryExists = ERROR_SUCCESS End Function It's still frustrating that the DLL approach didn't work. Thanks, Chris McKinnon -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Tuesday, October 19, 2010 11:38 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Calling a managed custom action from a UI control Are you really cranking up all this infrastructure just to see if a directory exists? There's got to be a simpler way, even if it's only a horrible little VBScript 10 line custom action. At least that is natively supported by Windows Installer. Phil Wilson -Original Message- From: McKinnon, Chris [mailto:cmckin...@atb.com] Sent: Tuesday, October 19, 2010 8:58 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Calling a managed custom action from a UI control Hi Blair, No log entries, unfortunately. I've let my installer sit spinning for about 20-30 minutes. I could let it sit longer but I don't think that would help. I'm going to try my installer on a Windows 2000 Professional workstation when I have a chance today. Let me know if there's anything else I can do to track down this issue. Thanks, Chris McKinnon -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, October 19, 2010 12:06 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Calling a managed custom action from a UI control Whenever Windows Installer launches a DLL-type custom action, it does so from a separate msiexec.exe process instance (sandboxing the custom action code, if you will). However, because this sandbox process may be reused, and because loading pre-4.x CLR runtimes marks the process preventing a different runtime from ever being loaded, DTF runs the assemblies in their own child process. When you build a DTF custom action assembly, a native stub is built/modified that contains an entry point for each method with a CustomActionAttribute, along with being packed with your assembly
Re: [WiX-users] Calling a managed custom action from a UI control
Hi, This is the simple way which might not always work; When files have a special attribute (like read only, system) or are in use the entire uninstall will fail while the issue can be handled correct in your CA (change attributes, give a message or stop a service that is using a config file or something like that before deleting the file(s)) Another thing is that it might be necessary to ask the user if some files (like logfiles or config files) should remain on the system or not. Regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. The Netherlands -Oorspronkelijk bericht- Van: David Watson [mailto:dwat...@sdl.com] Verzonden: maandag 25 oktober 2010 16:01 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Calling a managed custom action from a UI control Try something like this... DirectoryRef Id=SomeDir Component Id=removeSomeDir Guid=9FFCB64B-796A-4576-8EC3-5E01CBFD75F8 KeyPath=yes !-- remove this folder and empty it on uninstall -- RemoveFolder Id= SomeDir.removeinstallfolder On=uninstall Directory=SomeDir / RemoveFile Id= SomeDir.removeinstallfiles Name=*.* On=uninstall Directory=SomeDir/ /Component /DirectoryRef -Original Message- From: sagar shinde [mailto:sagar.i...@gmail.com] Sent: 25 October 2010 14:31 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Calling a managed custom action from a UI control hi thanks for reply, but i can not use this removefolder as my installer will create new folders and diffrent files will be created in that folder by user so RemoveFolder will not work in this case is ter any other option thank you. On Mon, Oct 25, 2010 at 6:00 PM, Albert van Peppen alb...@insad.nl wrote: Hi, I suggest you read the manual, tutorial or the book on WiX or at least look at the online help on MSI. The part about properties should help you well underway. Same for the initial problem Chris has. Or to be in your language: RTFT or RTFM :) Albert van Peppen Senior System Engineer Insad Grafisch b.v. The Netherlands -Oorspronkelijk bericht- Van: sagar shinde [mailto:sagar.i...@gmail.com] Verzonden: maandag 25 oktober 2010 13:57 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Calling a managed custom action from a UI control hi i am trying something similer to this,i want to delete folders at uninstall time,i have one VBscript for that, but how can i set path for that or how ur VBscript is getting path in ur code. how u called ur VBscript from wix installer On Wed, Oct 20, 2010 at 1:06 AM, McKinnon, Chris cmckin...@atb.com wrote: You are absolutely right. I just wanted to keep all my custom actions in the same DLL. I have two other actions for encrypting and decrypting the .config files. I switched my code to a VBScript and it works nicely. Here's the script if anyone is interested: Function DirectoryExists() Dim path, fso path = Session.Property(_DirectoryExists_Path) Set fso = CreateObject(Scripting.FileSystemObject) If (fso.FolderExists(path)) Then Session.Property(_DirectoryExists_Result) = yes Else Session.Property(_DirectoryExists_Result) = no End If DirectoryExists = ERROR_SUCCESS End Function It's still frustrating that the DLL approach didn't work. Thanks, Chris McKinnon -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Tuesday, October 19, 2010 11:38 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Calling a managed custom action from a UI control Are you really cranking up all this infrastructure just to see if a directory exists? There's got to be a simpler way, even if it's only a horrible little VBScript 10 line custom action. At least that is natively supported by Windows Installer. Phil Wilson -Original Message- From: McKinnon, Chris [mailto:cmckin...@atb.com] Sent: Tuesday, October 19, 2010 8:58 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Calling a managed custom action from a UI control Hi Blair, No log entries, unfortunately. I've let my installer sit spinning for about 20-30 minutes. I could let it sit longer but I don't think that would help. I'm going to try my installer on a Windows 2000 Professional workstation when I have a chance today. Let me know if there's anything else I can do to track down this issue. Thanks, Chris McKinnon -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, October 19, 2010 12:06 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Calling a managed custom action from a UI control Whenever Windows Installer launches a DLL-type custom action, it does so from a separate
Re: [WiX-users] ComboBox question
Hi, You can check out my sample code on this page: http://madbutcher.dyndns.org/snippets/ Here you can find a SQL instance selector CA for WiX 2.0 but it still works for WiX 3.6. It has also some tricks to correctly detect 32 and 64 instances correctly (in a tricky way) Regards, Albert van Peppen -Oorspronkelijk bericht- Van: Bob Arnson [mailto:b...@joyofsetup.com] Verzonden: vrijdag 17 september 2010 18:46 Aan: wix-users@lists.sourceforge.net Onderwerp: Re: [WiX-users] ComboBox question On 16-Sep-10 14:00, Michael_A wrote: What is set the property to the associated value mean, if its SQLINSTANCENAME initially I have no idea what the values are. Selecting an item in a combo box sets the combo box's property to the value of the item (separate from the text). The revert is also true: To select an item in a combo box, set the combo box's property to the value of the item you want selected. -- sig://boB http://joyofsetup.com/ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix mailing lists open to public = more spam
Correctly if I am wrong but the member list of a mailling group can be scanned to known spammers and get bounced from it; this way you can bounce a spammer from all groups in one go (although it will give some frustration if your mistakenly get bounced...) smile / Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Martin MacPherson Verzonden: woensdag 23 april 2008 0:22 Aan: John Vottero CC: wix-users@lists.sourceforge.net Onderwerp: Re: [WiX-users] wix mailing lists open to public = more spam They must be really desperate joining a wix-user mailing list ;) On 22/04/2008, John Vottero [EMAIL PROTECTED] wrote: If anyone has any other opinions on this topic, please do make your voice heard. I'm still following this thread and trying to figure out if I should lock non-members out of the list. I'm still very hesitant to do that since it raises the bar for people just starting to get involved with WiX (and we don't need to make anything *harder* smile/). What will keep the spammers from joining the list? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j avaone ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Repair issue
Hi, Does anyone know how the debug problems with the ARP repair functionality? The problem in my case is that the repair gives a 1706 error; (Dutch version sorry ;) Fout 1706. Kan geen installatiepakket vinden voor product Drumis - Databaseonderdelen V2.90.2352.0. Voer de installatie opnieuw uit met een geldig exemplaar van het installatiepakket DatabaseSetup.release-3.msi. MSI (s) (30:60) [15:52:35:015]: Product: Drumis - Databaseonderdelen V2.90.2352.0 -- Fout 1706. Kan geen installatiepakket vinden voor product Drumis - Databaseonderdelen V2.90.2352.0. Voer de installatie opnieuw uit met een geldig exemplaar van het installatiepakket DatabaseSetup.release-3.msi. What basically fails it that the installer attempts to read the source MSI file from the original installation source (which might be a CD or a temp-folder). Anyway, after installation the MSI file is no longer available. In the WINNT\Installer cache is a copy of the msi file. This matches the one found in the registry at; HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\Userdata\S-1-5- 18\Products\some id\InstallProperties\LocalPackage Am i doing wrong? Or is there something that is required in the WiX file? I am using WiX 2.0.5325.0, tested on Windows XP, SP 2. I have my own CA DLL embedded in the MSI file. Regards, Albert van Peppen - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Failed to open XML file on Vista
Hi, First of all sorry for the late reply; It's near the summer holliday so things are a bit busy at home ;) What i mean that went wrong is best illustrated with the following 3 sample pieces (i think you understand what the problem is from this). 1. When i use the following everything works as expected: ... CustomAction Id=MyAction BinaryKey=MyCustomActions DllEntry=MyAction / UI ProgressText Action=MyActionMy action in progress/ProgressText /UI InstallExecuteSequence Custom Action=MyAction After=SchedXmlFile / /InstallExecuteSequence ... DirectoryRef Id=INSTALLDIR Component Id=MyOwn.xml Guid=PUT-GUID-HERE File Id=File_MyOwn.xml Name=MyOwn.xml DiskId=1 Source=$(var.MySourcePath)\MyOwn.xml Vital=yes / XmlFile Sequence=10 Id=MyOwn.xml_License File=[INSTALLDIR]MyOwn.xml Action=createElement Name=License ElementPath=//FooBar / XmlFile Sequence=11 Id=MyOwn.xml_LicenseMarker File=[INSTALLDIR]MyOwn.xml Action='setValue' Name='marker' Value='IGTMB100' ElementPath='//FooBar/License' / /Component /DirectoryRef FeatureRef Id=MainFeature ComponentRef Id=WInsad.dat / /FeatureRef ... 2. When i drop the XML file but forget to fix the scheduling of MyAction, the error appears. Checking with orca i found that SchedXmlFile is still scheduled and that the entire CA for XML handling was linked into my MSI, although it was not used. The XmlTable doesn't exist, this might eventualy be the problem ? Eg. it does not works as expected: ... CustomAction Id=MyAction BinaryKey=MyCustomActions DllEntry=MyAction / UI ProgressText Action=MyActionMy action in progress/ProgressText /UI InstallExecuteSequence Custom Action=MyAction After=SchedXmlFile / /InstallExecuteSequence ... !-- Commented out the XML file -- !-- DirectoryRef Id=INSTALLDIR Component Id=MyOwn.xml Guid=PUT-GUID-HERE File Id=File_MyOwn.xml Name=MyOwn.xml DiskId=1 Source=$(var.MySourcePath)\MyOwn.xml Vital=yes / XmlFile Sequence=10 Id=MyOwn.xml_License File=[INSTALLDIR]MyOwn.xml Action=createElement Name=License ElementPath=//FooBar / XmlFile Sequence=11 Id=MyOwn.xml_LicenseMarker File=[INSTALLDIR]MyOwn.xml Action='setValue' Name='marker' Value='IGTMB100' ElementPath='//FooBar/License' / /Component /DirectoryRef FeatureRef Id=MainFeature ComponentRef Id=WInsad.dat / /FeatureRef -- ... 3. After fixing the scheduling it works again: ... CustomAction Id=MyAction BinaryKey=MyCustomActions DllEntry=MyAction / UI ProgressText Action=MyActionMy action in progress/ProgressText /UI InstallExecuteSequence !-- No longer after Xml scheduler! Custom Action=MyAction After=SchedXmlFile / -- Custom Action=MyAction After=InstallFiles / /InstallExecuteSequence ... !-- Commented out the XML file -- !-- DirectoryRef Id=INSTALLDIR Component Id=MyOwn.xml Guid=PUT-GUID-HERE File Id=File_MyOwn.xml Name=MyOwn.xml DiskId=1 Source=$(var.MySourcePath)\MyOwn.xml Vital=yes / XmlFile Sequence=10 Id=MyOwn.xml_License File=[INSTALLDIR]MyOwn.xml Action=createElement Name=License ElementPath=//FooBar / XmlFile Sequence=11 Id=MyOwn.xml_LicenseMarker File=[INSTALLDIR]MyOwn.xml Action='setValue' Name='marker' Value='IGTMB100' ElementPath='//FooBar/License' / /Component /DirectoryRef FeatureRef Id=MainFeature ComponentRef Id=WInsad.dat / /FeatureRef -- ... Hope this helps :-) And yes, INSTALLDIR has the correct value and has nothing to do with the problem. I am still using WiX-2.0 (latest) and have not tested the above on WiX-3.0. Regards, Albert van Peppen Van: Bob Arnson [mailto:[EMAIL PROTECTED] Verzonden: woensdag 4 juli 2007 17:00 Aan: Albert van Peppen CC: wix-users@lists.sourceforge.net Onderwerp: Re: [WiX-users] Failed to open XML file on Vista Albert van Peppen wrote: The message appears when you don't have any XmlFile entries in your wxi script but has an action scheduled as After=XmlSched. This implies XmlSched CA is used and so it is placed in the InstallExecuteSequence but since it has nothing to do, it seems to generates the error because it's trying to open an empty file (which is indeed an invalid XML file). Can you clarify what's happening? Scheduling an action after another that does no work is perfectly legal. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Failed to open XML file on Vista
Hi, Finally found the problem (although it was away since 11 may 2007 because of changes in my wxi file).. It turned out that it has nothing to do with Office or anything on Vista. The message appears when you don't have any XmlFile entries in your wxi script but has an action scheduled as After=XmlSched. This implies XmlSched CA is used and so it is placed in the InstallExecuteSequence but since it has nothing to do, it seems to generates the error because it's trying to open an empty file (which is indeed an invalid XML file). I think it would be an idea to generate a warning / error on this in the linker (light.exe) or , better yet, the linker should optimize this; Build the sequence list and before writing to the MSI table, check all CA / Actions are really used, if not drop them from the list :) I don't know what WiX 3.0 does with the above problem, i still use WiX 2.0 because it's stable. As soon WiX 3.0 is stable enough i will switch :-) Regards, Albert van Peppen Van: Rob Mensching [mailto:[EMAIL PROTECTED] Verzonden: zaterdag 12 mei 2007 19:17 Aan: Albert van Peppen; Wix-Devs Onderwerp: RE: [WiX-users] Failed to open XML file on Vista No idea. You might use FileMon to watch the access to the file to see what happens and why the system is messing with your file. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Albert van Peppen Sent: Friday, May 11, 2007 4:59 AM To: Wix-Devs Subject: Re: [WiX-devs] [WiX-users] Failed to open XML file on Vista Hi, I tried again on this notebook; now it works without any problem :( The only thing done on this notebook since the problem was reproducable is that now Office 2003 Pro is installed; Doing so gave the (well known?) error 1913. After google-ing on this i found a solution at: http://phaq.phunsites.net/?p=91 I did follow this solution only partionally; I just made the administrators group owner of the system32 folder. That did the trick for Office 2003 Pro. Since the MSXML dlls are located in the system32 folder this might be the 'solution' to this? Although i don't fully understand why this is like this; and thus causeing the problem with installing Office 2003 Pro. I'll try to setup a clean Vista out of the box on another machine to validate this is causing my installer to run well.. Maybe you have more insight in this (known issues with such things ?) Regards, Albert van Peppen Van: Rob Mensching [mailto:[EMAIL PROTECTED] Verzonden: vrijdag 11 mei 2007 6:40 Aan: Albert van Peppen Onderwerp: RE: [WiX-users] Failed to open XML file on Vista Okay, tried this install on Vista. Worked exactly as expected. I'm not sure what problem you are seeing. The ExecXmlFile CustomAction is running in the elevated CustomAction Server so it is elevated as well. From: Albert van Peppen [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 09, 2007 6:56 AM To: Rob Mensching Subject: RE: [WiX-users] Failed to open XML file on Vista We don't ACL any files. The XML file is just installed by the MSI installer in elevated mode. The user running the installer has least user access (LUA). It is possible to log in what user state runs the COM InProc server, i doubt the COM is indeed called in any elevated state.. The mentioned problem also exists on XP with a very restricted user, so it is not just a Vista problem, but we've found it first in Vista so we thought it was a problem in/with Vista. Can you checked the issue yourself? I am willing to try and change some things in the WiX sources; just to see i'm right ;) But it seems a bit of task to get the WiX sources compiling.. (At least at this moment) Regards, Albert van Peppen Van: Rob Mensching [mailto:[EMAIL PROTECTED] Verzonden: woensdag 9 mei 2007 15:36 Aan: Albert van Peppen; Wix-Devs Onderwerp: RE: [WiX-users] Failed to open XML file on Vista The ExecXmlFile is already running in an elevated process so the elevation moniker should be unnecessary. Besides, the fact that you're failing when running as a local administrator means that UAC is not the issue. It looks like the problem is somehow related to the file only being accessible by the domain administrator. Did you ACL the file down such that only the domain admin can access it? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Albert van Peppen Sent: Wednesday, May 09, 2007 5:58 AM To: Wix-Devs Subject: Re: [WiX-devs] [WiX-users] Failed to open XML file on Vista Hi, I posted this though to wix-dev since i believe the problem lies in WiX. When looking at the source coude i found that XmlFile is useing the MSXML COM object. This is done by calling ::CoCreateInstance(). When looking into ::CoCreateInstance() and COM and Elevation i found that you should use a Elevation Moniker. Check
[WiX-users] Failed to open XML file on Vista
Hi, I try to install a XML file through my WiX Installer. On WinXP i have no problems. On Windows Vista (Business Edition), client in a Win2003 AD network, i have some strange problems; - Installing as a domain administrator gives no problems. - Installing as a local administrator gives an error; installation fails. - Installing as a local or domain user with restricted rights gives an error; installation fails. - Installing with elevated rights / run as gives an error; installation fails. (With the exception of Run As domain Administrator) In all cases where the installation fails the following error appears: 'Failed to open XML file WInsad.xml, system error: -2147024786' The logfile shows: MSI (s) (18:E0) [12:50:19:270]: Running as a service. MSI (s) (18:E0) [12:50:19:317]: Hello, I'm your 32bit Elevated custom action server. MSI (s) (18!68) [12:50:19:364]: Creating MSIHANDLE (4645) of type 790531 for thread 4456 ExecXmlFile: Error 0x8007006e: failed to load XML file: WInsad.xml MSI (s) (18!68) [12:50:19:489]: Closing MSIHANDLE (4645) of type 790531 for thread 4456 MSI (s) (18!68) [12:50:19:536]: Creating MSIHANDLE (4646) of type 790531 for thread 4456 Fout 25531. Failed to open XML file WInsad.xml, system error: -2147024786 MSI (s) (18!68) [12:52:31:146]: Product: Drumis - Programma V2.90.2267.0 -- Fout 25531. Failed to open XML file WInsad.xml, system error: -2147024786 MSI (s) (18!68) [12:52:31:177]: Closing MSIHANDLE (4646) of type 790531 for thread 4456 MSI (s) (18:10) [12:52:31:208]: Closing MSIHANDLE (4644) of type 790536 for thread 3812 Actie beëindigd 12:52:31: InstallExecute. Retourwaarde 3. The following piece of code is what i use in WiX: !-- = WInsad.xml = License file = -- DirectoryRef Id=INSTALLDIR Component Id=WInsad.dat Guid=--xxx-xxx-xxx File Id=File_WInsad.dat Name=WInsad.dat DiskId=1 Source=$(var.MyApplicationSourcePath)\WInsad.dat Vital=yes / /Component Component Id=WInsad.xml Guid=--xxx-xxx-xxy File Id=File_WInsad.xml Name=WInsad.xml DiskId=1 Source=$(var.DrumisApplicationSourcePath)\WInsad.xml Vital=yes / XmlFile Sequence=10 Id=Winsad.xml_License File=[INSTALLDIR]WInsad.xml Action=createElement Name=License ElementPath=//WInsad / XmlFile Sequence=11 Id=Winsad.xml_LicenseType File=[INSTALLDIR]WInsad.xml Action='setValue' Name='type' Value='Demo' ElementPath='//WInsad/License' / /Component /DirectoryRef !-- Features -- FeatureRef Id=MainFeature ComponentRef Id=WInsad.dat / ComponentRef Id=WInsad.xml / /FeatureRef The initial WInsad.xml file is installed on the targetsystem before the error. It initially looks like: ?xml version=1.0 encoding=windows-1252? WInsad /WInsad The WiX version used in Wix-2.0.5213.0 Am i doing something wrong or is it something with Wix-2 / Vista? The InstallerVersion in the Package is set to 200, the InstallerPrivileges is set to elevated. Any help is welcome. Regards, Albert van Peppen - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Microsoft Setup Analysis Tool
Did you try the Validate option in Orca? It will show you all ICE errors and warnings ;) Regards, Albert -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Michael Saupe Verzonden: donderdag 22 maart 2007 13:41 Aan: wix-users@lists.sourceforge.net Onderwerp: [WiX-users] Microsoft Setup Analysis Tool Hello, I've created an application installer with WiX toolset (v2.0). Everything works fine during my tests. But today I tested the installer with the Microsoft Setup Analysis Tool (SAT) (included in the Microsoft Application Compatibility Toolkit) and I got the error message setup_installer.msi did not run successfully. ERROR: The run did not complete successfully.. What could be the problem? Btw: When I tested the samples of the WiX tutorial, I got the same error message. Any input would be very helpful. Regards, Michael -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE V ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] ICE27 ERROR
Hi all, When i try to validate my msi file i get the following ICE27 error: ICE27 ERROR Action: 'RMCCPSearch' in InstallExecuteSequence table must come after the 'CCPSearch' action. I do nothing with the actions RMCCPSearch and CPSearch myself and after some searching i found these actions are defined in wixui.wixlib (src\wix\Data\actions.xml). Is there a bug in the sequence in the ui lib here? What can i do to resolve this? I am currently running wix 2.0.2612.0 Albert van Peppen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ICE27 ERROR
Sorry, i meant wix-2.0.5116.0(2612 was a 3.0.2612.0 on which ive did some tests earlier but it still doesnt run as it should :) ) Albert van Peppen Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Albert van Peppen Verzonden: dinsdag 20 maart 2007 15:43 Aan: wix-users@lists.sourceforge.net Onderwerp: [WiX-users] ICE27 ERROR Hi all, When i try to validate my msi file i get the following ICE27 error: ICE27 ERROR Action: 'RMCCPSearch' in InstallExecuteSequence table must come after the 'CCPSearch' action. I do nothing with the actions RMCCPSearch and CPSearch myself and after some searching i found these actions are defined in wixui.wixlib (src\wix\Data\actions.xml). Is there a bug in the sequence in the ui lib here? What can i do to resolve this? I am currently running wix 2.0.2612.0 Albert van Peppen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ICE27 ERROR
Hi again ;) I've found that the error goes away when i don't include the MSM module of CrystalReports (11.5 aka 11R2). Somehow this mergemodule seems to be the problem of all kind of problems and generates a lot of ICE warnings.. Are there more people out there experiencing the same problems? But what is more important; what can I do to fix this? (Besides filing a bug report with the guys at BO) The Crystal Mergemodules are dated Februari 14 2007. And are the latest available (AFAICS).. The following mergemodules are merged in: - CrystalReports11_5_RDC_License.msm 2.189.312 14-02-2007 - CrystalReports11_5_RDC_Reportengine.msm47.831.040 14-02-2007 - CrystalReports11_5_RDC_Runtime.msm 10.262.528 14-02-2007 Albert van Peppen Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Albert van Peppen Verzonden: dinsdag 20 maart 2007 15:55 Aan: wix-users@lists.sourceforge.net Onderwerp: Re: [WiX-users] ICE27 ERROR Sorry, i meant wix-2.0.5116.0(2612 was a 3.0.2612.0 on which ive did some tests earlier but it still doesnt run as it should :) ) Albert van Peppen Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Albert van Peppen Verzonden: dinsdag 20 maart 2007 15:43 Aan: wix-users@lists.sourceforge.net Onderwerp: [WiX-users] ICE27 ERROR Hi all, When i try to validate my msi file i get the following ICE27 error: ICE27 ERROR Action: 'RMCCPSearch' in InstallExecuteSequence table must come after the 'CCPSearch' action. I do nothing with the actions RMCCPSearch and CPSearch myself and after some searching i found these actions are defined in wixui.wixlib (src\wix\Data\actions.xml). Is there a bug in the sequence in the ui lib here? What can i do to resolve this? I am currently running wix 2.0.2612.0 Albert van Peppen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ICE27 ERROR
We did the same thing, however in order to pass certification you are not allowed to have a list of ICE errors. So when preparing for this we want to resolve these issues. I saw on the Business Objects forum that there are alot of installation issues with their merge modules (CRW installs ok on Viste but applications who use the MSM dont seem to work well :( ) So the issue seems to be know.. Regards, Albert Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens [EMAIL PROTECTED] Verzonden: dinsdag 20 maart 2007 16:41 Aan: wix-users@lists.sourceforge.net Onderwerp: Re: [WiX-users] ICE27 ERROR We certainly are getting ICE warnings (with CR 11). Fortunately, we are currently using WiX 2, so the ICE errors, while annoying, don't cause a build failure. They also don't cause the specific error you mention. I coded my WiX script with conditional inclusion of the Crystal merge module. I use the build without including it to check that I don't have any ICE problems in the parts of the setup I have coded and have control over, then include the Crystal Reports merge module in the actual build and trust that even though the installation generated fails validation to some extent it still does what it should. I don't like it much, but we don't have enough buying power to slap Business Objects (or whoever owns Crystal this month) around the head and tell them to do it right! :-) Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Albert van Peppen Sent: Tuesday, March 20, 2007 11:30 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] ICE27 ERROR Hi again ;) I've found that the error goes away when i don't include the MSM module of CrystalReports (11.5 aka 11R2). Somehow this mergemodule seems to be the problem of all kind of problems and generates a lot of ICE warnings.. Are there more people out there experiencing the same problems? But what is more important; what can I do to fix this? (Besides filing a bug report with the guys at BO) The Crystal Mergemodules are dated Februari 14 2007. And are the latest available (AFAICS).. The following mergemodules are merged in: - CrystalReports11_5_RDC_License.msm 2.189.312 14-02-2007 - CrystalReports11_5_RDC_Reportengine.msm47.831.040 14-02-2007 - CrystalReports11_5_RDC_Runtime.msm 10.262.528 14-02-2007 Albert van Peppen * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Peek Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Any documentation on WiX/Windows Installer limits?
Hi, I guess that will work. I still believe the ~2GB limit is the problem here. I cannot find the max filesize for System.IO.File but I recon its 64bit (unsigned)? If it is 32bit (signed), then the ~2GB Limit is the problem... Usualy in VC++.NET 2005 you use Cfile, which is adapted to use ULONLONG which is 64bit (unsigned). But since I'm not a C# guru I place this question for another guru ;) Another problem might be that you're temp files are on a FAT 32, or worse a FAT 16, partition? Regards, Albert van Peppen -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Bob Arnson Verzonden: woensdag 31 januari 2007 5:49 Aan: Alex Lian CC: wix-users@lists.sourceforge.net Onderwerp: Re: [WiX-users] Any documentation on WiX/Windows Installer limits? Alex Lian wrote: But that still doesn't address the problem I consistently see when I increase the overall MSI size (with multiple cabs of 2GB size) seems to be 2GB... Have you tried using external cabs? My day job is working with a multi-gigabyte package but the .msi itself is only ~70MB. light.exe : warning LGHT1011 : Access denied; cannot delete 'pathremoved\Temp\gblw976s'. That's a sign another process is using the directory. -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE V ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with CDATA and default values inConditionstatements
Hi, I think this more a MSXML problem than it is a WiX problem ;) But I don't know. Regards, Albert van Peppen -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Geoff Finger Verzonden: dinsdag 30 januari 2007 23:15 Aan: wix-users@lists.sourceforge.net Onderwerp: Re: [WiX-users] Problem with CDATA and default values inConditionstatements Swapping in lt;gt; fixed both issues! Thank you! Why is it necessary to use that in some cases though when in other spots I used without any problem? Shouldn't using the CDATA wrapper have prevented it from being an issue? On 1/30/07, Albert van Peppen [EMAIL PROTECTED] wrote: Did you try using lt;gt; instead of in your condition? Like: ConditionFOOVAR lt;gt; /Condition Iso: ConditionFOOVAR /Condition Regards, Albert van Peppen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE V ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with CDATA and default values in Conditionstatements
Did you try using lt;gt; instead of in your condition? Like: ConditionFOOVAR lt;gt; /Condition Iso: ConditionFOOVAR /Condition Regards, Albert van Peppen -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Geoff Finger Verzonden: maandag 29 januari 2007 21:00 Aan: wix-users@lists.sourceforge.net Onderwerp: [WiX-users] Problem with CDATA and default values in Conditionstatements I can't get the comparison to work in the CDATA statement for my Condition elements and trying to set a default value on the property that is being tested is breaking them as well. I have a radio button selection during the setup that determines whether the service that is being installed will be run by the system or a user, with elements such as this: Control Id=AccountName Type=Edit X=120 Y=85 Width=150 Height=18 TabSkip=no Property=SVCACCOUNTNAME Condition Action=disableSVCLOGONTYPE = System/Condition Condition Action=enableSVCLOGONTYPE = User/Condition /Control I haven't determined a better way to handle the actual installation than to have two almost identical components, one with Account and Password attributes in the ServiceInstall element and the other without. In the feature I have two sub-features that I'm trying to choose between using Condition elements. I've gotten the following code which works: Feature Id=SystemService Display=hidden TypicalDefault=install Level=1 ComponentRef Id=SystemServiceComponent/ Condition Level=0![CDATA[SVCLOGONTYPE = User]]/Condition /Feature Feature Id=UserService Display=hidden TypicalDefault=install Level=1 ComponentRef Id=UserServiceComponent/ Condition Level=0![CDATA[SVCLOGONTYPE = System]]/Condition /Feature There are two changes I'd like to make, I'd like to change it so that the condition for disabling the SystemService feature is that SVCLOGONTYPE is not set to System, rather than disabling it if it is set to User. However if I change the = to and swap the names then no matter which option I select neither gets installed. The log file shows Feature: SystemService; Installed: Absent; Request: Null; Action: Null Feature: UserService; Installed: Absent; Request: Null; Action: Null but as far as I can tell there's no logging of the evaluation of the Condition statement so I can't tell what's going wrong. Second I want to have the radio buttons default to System rather than neither being selected when I get to that page. However if I add Property Id=SVCLOGONTYPESystem/Property then again neither element gets installed and the same messages show up in the log. There are also messages like PROPERTY CHANGE: Modifying SVCLOGONTYPE property. Its current value is 'System'. Its new value: 'User'. So I know that the default is being used and then getting overridden, but again there's no debug info about the Condition evaluation so I don't know why neither feature is being installed. Any help on how to fix this, especially the default property value, or some other workaround on how to make the dialog start with System selected, would be greatly appreciated! Thanks! - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE V ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] SQL Script limit?
Hi, I am handling this in my application; when the app is executed for the first time (it checks this) then the database is created by the application. This way you have more control over your database creation process. It also runs much faster indeed and when the application is already installed you can use some logic of your own to determine if the database needs to be updated or not. I think installing something that takes more than one hour is something i would consider as bad; As a standpoint of a developer as well as a standpoint of a system administrator. But i can understand that it is sometimes not possible to install your database at first run. In this case i would recommend using a CA. In this case you have lowlevel access to the database which means speed. Inside MSI installer it is hard to tell what the problem is, i think data is copied around which means lots and lots of memory is wasted, add to that the memory usage of SQLServer (assuming the SQL Server is running on the same machine as you are installing) and you have a blueprint for disaster whith such a SQL script (which will cause a huge transaction log in SQL memory i supose). Regards, Albert van Peppen Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Rob Mensching Verzonden: woensdag 24 januari 2007 16:15 Aan: Ian Couper CC: wix-users@lists.sourceforge.net Onderwerp: Re: [WiX-users] SQL Script limit? Wow, you have a SQL Script that takes an hour to run? I've never seen anything that complicated. Again, as I noted below, due to the way data is passed around inside the Windows Installer, your script may be copied around several times. Also, the WiX toolset is doing a bit of processing to break your script down to pass it around inside the Windows Installer. It is entirely possible that is causing the overhead you're seeing. Just a general question, What is in a 50 MB SQL Script that you need to execute at install time? A one hour wait during installation is not a great user experience. I'm just trying to understand what the WiX toolset could do to help. From: Ian Couper [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 24, 2007 6:25 AM To: Rob Mensching Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] SQL Script limit? I just let the script run overnight and it finally did something. It ended up failing on some line from the script, but aside from that the script took almost 4 hours to run to that point, which wasn't even to completion. This script normally takes about 20 min to 1 hour at the most to run, so there is either something wrong with how I am handling it, or WiX can't handle the size of script I am trying to run. From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 23, 2007 11:55 AM To: Ian Couper; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] SQL Script limit? With the way that MSI works, you'll probably end up pushing the same 50 MB of strings around 3 or 4 times. That could take time. Also, if you don't have the latest WiX v2 code base, you could be hitting some old bugs in the SQL processing. After that, you could try debugging through the code and seeing what is taking the longest. Maybe there is some perf we can improve, but I've never heard anyone complain about this before. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Couper Sent: Tuesday, January 23, 2007 8:25 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] SQL Script limit? I have a large SQL script (30 to 50MBs) that I am trying to run from the MSI using SQLScript. I have been able to run smaller scripts easily, but this large one is not running at all and the MSI hangs. Is this a known issue with Wix 2.0? Is there a way to overcome this issue? Thanks. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] SQL Server List in ComboBox
Hi, If there is a repository for these things i am willing to donate to it; I do have this custom action written myself. It needs some cleaning to be used for general purposes (remove my own application dependant stuff). Can someone tell me where i can put this so everyone can send in these kinda usefull code? Matthew, i'll send it to the wix-users list asap (might be tomorow though) Greetings, Albert van Peppen Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Matthew Rowan Verzonden: maandag 22 januari 2007 6:27 Aan: wix-users@lists.sourceforge.net Onderwerp: [WiX-users] SQL Server List in ComboBox Hi All, I'm trying to present a list of all available SQL Servers to the user allowing them to select their server and enter their credentials then test the connection. I know I need to write a custom action DLL to populate certain MSI tables but I don't know how to go about doing this. It would be much appreciated if someone had some code or examples to do this. Cheers, -Matthew Rowan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] SQL Server List in ComboBox
Hi, I've tried to send a zip to the list but this seems to be not possible :( I have a VC 2005.NET project with a simple CA with the requested code. In some snippets it is mentioned how to use it. If there is a place where i can upload it it's fine with me :-) If there are any problems; try to figure them out yourself and after that you can ask ;) The code is free for use, commercial or non-commercial and is based on some snippets from along tine ago. Hi Rob, i've read the agreement before and it was discussed here also before so i figure you know why i can't just sign it ;) Greetings, Albert van Peppen Van: Rob Mensching [mailto:[EMAIL PROTECTED] Verzonden: maandag 22 januari 2007 17:01 Aan: Albert van Peppen; [EMAIL PROTECTED] Onderwerp: RE: Re: [WiX-users] SQL Server List in ComboBox Yeah, that'd be awesome. If you signed an assignment agreement then we could get this code to be a natural part of the WiX toolset. It make a nice addition to the pubca code. To get an assignment agreement, contact [EMAIL PROTECTED] and they'll get you set up. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Albert van Peppen Sent: Monday, January 22, 2007 4:50 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] SQL Server List in ComboBox Hi, If there is a repository for these things i am willing to donate to it; I do have this custom action written myself. It needs some cleaning to be used for general purposes (remove my own application dependant stuff). Can someone tell me where i can put this so everyone can send in these kinda usefull code? Matthew, i'll send it to the wix-users list asap (might be tomorow though) Greetings, Albert van Peppen Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Matthew Rowan Verzonden: maandag 22 januari 2007 6:27 Aan: wix-users@lists.sourceforge.net Onderwerp: [WiX-users] SQL Server List in ComboBox Hi All, I'm trying to present a list of all available SQL Servers to the user allowing them to select their server and enter their credentials then test the connection. I know I need to write a custom action DLL to populate certain MSI tables but I don't know how to go about doing this. It would be much appreciated if someone had some code or examples to do this. Cheers, -Matthew Rowan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to create single installable exe
You might want to use a self extracting zip and a modified SFX (use SFXMake for instance) so the setup.exe is started automatically after extracting the selfextracting zip :) Regards, Albert van Peppen Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens vijVerzonden: woensdag 20 september 2006 12:01Aan: wix-users@lists.sourceforge.netOnderwerp: [WiX-users] How to create single installable exe Hi, I have multiple msi packages createdusing WiX, a bootstrapper setup.exe and settings.ini (settings.ini contains some configuration information used by setup.exe). How can Ipackage these files (msi packages + setup.exe + settings.ini + some other resources)as a single installable executalbe? Any pointers would be of great help!! thanks Vij All-new Yahoo! Mail - Fire up a more powerful email and get things done faster. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Automatic updating an MSI installation underrestricteduser account
Hi, You might use a special user account with just enough rights to install your application, with just the correct amount of rights in the registry. Then run the service described on this user. By adding impersonation tricks you might be able to switch to the user context and use the HKCU and profile settings from that user. I this this is a nice workaround (i am not using it, but it should do the trick) The user can be created from within your installer MSI (since it is run as administrator) and all the specific rights can be arranged also. Just my thoughts ;) Greetings, Albert van Peppen Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Jason SwagerVerzonden: vrijdag 15 september 2006 4:29Aan: Bob ArnsonCC: Wilson, Phil; wix-users@lists.sourceforge.netOnderwerp: Re: [WiX-users] Automatic updating an MSI installation underrestricteduser account Yep - I fully agree. But when the customer requires this in an application - what else can you do? Privelege escalation is a definite worry. In my solution, I used named mutexs and encrypted memory mapped files using public/private key encryption via Windows CryptoAPI to trigger the installation. A bit of of overkill in this case, but it was a good exercise.Bob Arnson [EMAIL PROTECTED] wrote: Jason Swager wrote: This approach has some drawbacks. First, the possibly extra service running all the time.Which is a source of potential security holes, especially privilege escalation as it's running 100 percent of the time as local system. It works, but it's a sledgehammer of a solution.-- sig://boBhttp://bobs.org-Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimohttp://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___WiX-users mailing listWiX-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WixUI_InstallDir problems
Title: WixUI_InstallDir problems
Most likely becouseyou need to set the property to
your installation location like this:
Property Id="WIXUI_INSTALLDIR" Value="INSTALLLOCATION" /
Albert
Van: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Namens Nordvik,
ChristerVerzonden: maandag 10 juli 2006 10:33Aan:
wix-users@lists.sourceforge.netOnderwerp: [WiX-users]
WixUI_InstallDir problems
Hi!
I have the following wxs
file:
Property Id="INSTALLDIR"
RegistrySearch Id="Search" Root="HKLM" Key="Software\Microsoft\InetStp" Name="PathWWWRoot" Type="raw"
/ /Property
Directory Id="TARGETDIR" Name="SourceDir"
Directory Id="INSTALLDIR" Name="Inet" LongName="Inetpub"
Directory Id="ROOTDIR" Name="MyFld" LongName="MyFolder"
Directory Id="INSTALLLOCATION" Name="v2" LongName="v2.0.0"
Component Id="ConfigFiles" Guid="{myguid}"
File Id="MyAppFile" Name="Web.Co~" LongName="Web.Config" Vital="yes" DiskId="1" KeyPath="yes" Source="Web.Config"
/File ... Property
Id="WIXUI_INSTALLDIR" Value="INSTALLDIR" / UIRef Id="WixUI_InstallDir" /
I want the program location to
be configurable. Like c:\inetpub\wwwroot can be configured to c:\mypub\rootfolder but the program
will always create the directory MyFolder\v2.0.0. So if the user chooses c:\test then the
program will be installed into c:\test\MyFolder\v2.0.0. Everything is working during
installation but the program always gets installed into the default value of the
dialog (the one from registry).
If I change to WixUI_Minimal
then everything works fine (I can change the installation folder).
Any help is very
appreciated!
-Christer
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WixUI_InstallDir problems
Title: WixUI_InstallDir problems
Hi,
I don't have these problems, but did you
checked the wix.chm help (search for WIXUI_INSTALLDIR)?
Another great resource is the tutorial at http://www.tramontana.co.hu/wix/index.php#TOC
I use the DirectoryRef-way.. Maybe that's why i don't have
the problems :)
like:
...
Directory
Id="INSTALLLOCATION" Name="v2" LongName="v2.0.0" /
...
DirectoryRef Id="INSTALLLOCATION"
Directory
Id="mybin" Name="bin" LongName="bin"
...
Property Id="WIXUI_INSTALLDIR" Value="INSTALLLOCATION" /
Albert
Van: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Namens Nordvik,
ChristerVerzonden: maandag 10 juli 2006 12:47Aan:
wix-users@lists.sourceforge.netOnderwerp: Re: [WiX-users]
WixUI_InstallDir problems
Hi.
That almost did it, but I ran into another problem (which
is the same issue really).
I have:
...
Directory
Id="INSTALLLOCATION" Name="v2" LongName="v2.0.0"
Directory Id="mybin" Name="bin" LongName="bin"
...
Property Id="WIXUI_INSTALLDIR" Value="INSTALLLOCATION" /
The installer
defaults to:
C:\Inetpub\wwwroot\MyApp\v2.0.0
I change it to:
C:\Inetpub\wwwroot\MyApp\v3.0.0
And then I
end up with the following folder structure:
C:\Inetpub\wwwroot\MyApp\v2.0.0\bin
C:\Inetpub\wwwroot\MyApp\v3.0.0
It seems that
the bin folder doesn't receive the new value of INSTALLLOCATION so it uses the
previous value. Any idea as to what is causing this behavior?
I feel like I
am doing something wrong here but I don't know what it is...
-Christer
Fra: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] På vegne av Albert van
PeppenSendt: 10. juli 2006 10:54Til:
wix-users@lists.sourceforge.netEmne: Re: [WiX-users]
WixUI_InstallDir problems
Most likely becouseyou need to set the property to
your installation location like this:
Property Id="WIXUI_INSTALLDIR" Value="INSTALLLOCATION" /
Albert
Van: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Namens Nordvik,
ChristerVerzonden: maandag 10 juli 2006 10:33Aan:
wix-users@lists.sourceforge.netOnderwerp: [WiX-users]
WixUI_InstallDir problems
Hi!
I have the following wxs
file:
Property Id="INSTALLDIR" RegistrySearch Id="Search" Root="HKLM" Key="Software\Microsoft\InetStp" Name="PathWWWRoot" Type="raw" /
/Property Directory Id="TARGETDIR" Name="SourceDir"
Directory Id="INSTALLDIR" Name="Inet" LongName="Inetpub"
Directory Id="ROOTDIR" Name="MyFld" LongName="MyFolder" Directory Id="INSTALLLOCATION" Name="v2" LongName="v2.0.0"
Component Id="ConfigFiles" Guid="{myguid}"
File Id="MyAppFile" Name="Web.Co~" LongName="Web.Config" Vital="yes" DiskId="1" KeyPath="yes" Source="Web.Config"
/File ... Property
Id="WIXUI_INSTALLDIR" Value="INSTALLDIR" / UIRef Id="WixUI_InstallDir" /
I want the program location
to be configurable. Like c:\inetpub\wwwroot can be configured to c:\mypub\rootfolder but the program
will always create the directory MyFolder\v2.0.0. So if the user chooses c:\test then
the program will be installed into c:\test\MyFolder\v2.0.0. Everything is working during
installation but the program always gets installed into the default value of
the dialog (the one from registry).
If I change to WixUI_Minimal
then everything works fine (I can change the installation folder).
Any help is very
appreciated!
-Christer
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] job postings...
SourceForge.net offers a service like this; see https://sourceforge.net/people/ Albert -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Stefan Krueger [MVP] Verzonden: vrijdag 23 juni 2006 18:06 Aan: wix-users@lists.sourceforge.net Onderwerp: Re: [WiX-users] job postings... Just wanted to add that there is a section for job postings on the InstallSite.org forum: http://forum.installsite.net/index.php?showforum=65 -- Stefan Krueger Microsoft Windows Installer MVP Please post your questions in the newsgroup or vist one of these web sites: Windows Installer FAQ http://www.msifaq.com - http://www.msifaq.de InstallSite - Resources for Setup Developers http://www.installsite.org http://www.installsite.de (GERMAN) Rob Mensching [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] .corp.microsoft.com... Okay, I thought about that but figured people would think it was overkill. This is why I ask questions... smile/ Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] SQL Extended stored procedures
Hello all, I am currently trying to get some extended stored procedures registered in SQL.I did not found any samples for this. So maybe my code can be of any help in the tutorial ;-) Altough, I'm having some problems with extended stored procedures for SQL. I use the following piece of code in my WiX script: !-- codesnippet -- ?define strD4WXPProcDll = "[D4WBINDIR]xp_D4WProc.dll" ? DirectoryRef Id="TARGETDIR"Component Id="DatabaseComponent" Guid="$(var.guidDatabaseComponent)"ConditionD4WSQLSERVER lt;gt; ""/Condition SqlDatabase Id="DrumisDatabase" Database="master"Server="[D4WSQLSERVER]" CreateOnInstall="yes" DropOnInstall="no" DropOnUninstall="no" DropOnReinstall="no" !-- Uninstall / rollback install --SqlString Id="UnRegister_xp_D4W_Func1"Sequence="1"ContinueOnError="yes"ExecuteOnInstall="no" ExecuteOnReinstall="yes" ExecuteOnUninstall="yes" RollbackOnInstall="yes"SQL="if exists (select * from sysobjects where id = object_id(N'[\[]dbo[\]].[\[]xp_D4W_Func1[\]]') and OBJECTPROPERTY(id, N'IsExtendedProc') = 1) EXEC sp_dropextendedproc 'xp_D4W_Func1'"/ !-- After unregister, before delete xp_D4WProc.dll --!-- After this the xp_D4WProc.dll can be deleted / replaced --SqlString Id="Free_xp_D4WProc"Sequence="2"ContinueOnError="yes"ExecuteOnInstall="no" ExecuteOnReinstall="yes" ExecuteOnUninstall="yes" RollbackOnInstall="yes"SQL="DBCC xp_D4WProc(FREE)"/ !-- Register on install / reinstall --SqlString Id="Register_xp_D4W_Func1"Sequence="3"ExecuteOnInstall="yes" ExecuteOnReinstall="yes" RollbackOnUninstall="yes"SQL="if not exists (select * from sysobjects where id = object_id(N'[\[]dbo[\]].[\[]xp_D4W_Func1[\]]') and OBJECTPROPERTY(id, N'IsExtendedProc') = 1) EXEC sp_addextendedproc 'xp_D4W_Func1', '$(var.strD4WXPProcDll)' GRANT EXECUTE ON [\[]xp_D4W_Func1[\]] TO [\[]public[\]]"//SqlDatabase/Component/DirectoryRef !-- /codesnippet -- Installation goes 100% ok.But uninstalling results in an error: Failed to connect to SQL database. (-2147467259master ) Can anyone help me with this one? Is there a way to debug the uninstall? And another problem with the above code is when an error does occour during installation the rollback attempts to drop the master database. Which is reported as not possible (and so it should!).But how can i add a extended stored procedure to SQL without the need of creating a database? (XPs are usualy registered in the master database) Thanks in advance, Albert van Peppen Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [WiX-devs] [ wix-Feature Requests-1509926 ] Fill property withfileversion
Ok, but then I still cannot point to my main exefile for the version? So what I should do in my nightly build is generate a file with the version and buildnumer in it (like MyVersion.wxi) in which the version and buildnumbers are defined. This file I can then add tou my wxs file and done.. IMHO it would be easier to let candle read the version from the generated EXE file :) (Maybe it is possible, but I didn't found it) Albert -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens SourceForge.net Verzonden: zondag 25 juni 2006 0:57 Aan: [EMAIL PROTECTED] Onderwerp: [WiX-devs] [ wix-Feature Requests-1509926 ] Fill property withfileversion Feature Requests item #1509926, was opened at 2006-06-21 05:42 Message generated for change (Settings changed) made by derekc You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642717aid=1509926gro up_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: compiler Group: Denied Status: Closed Priority: 5 Submitted By: The Mad Butcher (mad_burcher) Assigned to: Derek (derekc) Summary: Fill property with fileversion Initial Comment: Make it possible to implement a way to assign the fileversion of a file (embedded in the MSI) to a property. This property might be used in the rest of the wix- code (eg. my goal is that the Product/@Version can be filled based on my main application in the msi file) But it should also be possible to check for upgrades based on this property. Greetings, Albert van Peppen -- Comment By: Derek (derekc) Date: 2006-06-24 15:56 Message: Logged In: YES user_id=518766 You can already do something like this by using the wix preprocessor. We had a discussion about a feature like this a while ago and the consensus was that its cleanest to just pass in any versioning information as a preprocessor variable which is then used in the appropriate places in the authoring. For example, the upgrade information cannot be populated with a property because it doesn't support formatted columns - so this can only be done with the preprocessor. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642717aid=1509926gro up_id=105970 Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Customizing dialog sets
Hmm.. I did it some other way; maybe the wrong way? But it is much easier (at least it seems to me and it works); 1. Copy the WixUI_xxx.wxs (for example the WixUI_Mondo.wxs) to your projects include folder (yes, i really using them) as WixUI_MyCustom.wxi 2. Edit the WixUI_MyCustom.wxi: Change theUI idUI Id="WixUI_Mondo" into UI Id="WixUI_MyCustom" 3. Remove/insert your refs to dialogs and reorder the dialogs, if you like, by changing the WixUI_xxx_Next and WixUI_xxx_Back properties for the appropriate dialogs 4.Optional: Create your own wxi files with the dialogs in it; copy sample code from the library sources but don't use fragments. (Make sure to use unique IDs like MyCustomLicenseAgreementDlg) 5. Optional: Include your dialog include files in WixUI_MyCustom.wxi with ?include ...? (try to maintain the same structure in your dialog as in the code in the WixUI lib-sources) 6. Include WixUI_MyCustom.wxi in your wxs file and use the UIRef UIRef Id="WixUI_MyCustom" / 7. Build your project This way there is no need to build a seperate wixlib and you can keep everything in one project easily. It would be neat if you could 'override' a specific dialog. Then you you can change a single dialog tou your own needs without all the other fuss.. As said; it works for me. Now in Wix-2.0. But i don't know if it'll work in Wix-3.0 (most likely not ?) But then again, i hope the UI handling in Wix-3.0 is somewhat 'better' (don't ask me how to define 'better' :-) ) Hope this can help heating the discussion? smile / Albert van Peppen Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Neil SleightholmVerzonden: donderdag 22 juni 2006 20:50Aan: wix-users@lists.sourceforge.netOnderwerp: Re: [WiX-users] Customizing dialog sets The WiX Tutorial covers some of this but the process I used: 1. Copy all the files in src\ui\wixui to a newfolder 2. Copy src\ui\wixui\mondo\WixUI_Mondo.wxs (or which ever base file you want) to the same folder. 3. Rename WixUI_Mondo.wxs and edit it to add/remove the features you want. 4. Remove any redundant wsx files. 4. Compile with: candle*.wxs 5. Followed by: lit -out customui.wixlib *.wixobj 6. Copy the wixlib file (customui.wixlib) to your main WiX folder (where candle.exe etc is). 7. You can then reference the new ui in your wxs file: UIRef Id="WixUI_MyUI" / and light against the new wixlib file. e.g. light -out Setup.msi *.wixobj customui.wixlib -loc WixUI_en-us.wxl Hope this helps Neil From: John Hidey [mailto:[EMAIL PROTECTED] Sent: 22 June 2006 18:29To: Bob Arnson; Neil SleightholmCc: wix-users@lists.sourceforge.netSubject: RE: [WiX-users] Customizing dialog sets After doing this, does anything need to be recompiled? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob ArnsonSent: Thursday, June 22, 2006 12:13 PMTo: Neil SleightholmCc: wix-users@lists.sourceforge.netSubject: Re: [WiX-users] Customizing dialog sets Neil Sleightholm wrote: In the online help there is this paragraph: "You can most easily add and remove dialogs from the stock dialog sets by copying one of the existing sets and modifying it. For an example, see the project in the doc/examples/wixui/custom directory." This example doesn't seem to exist, is it missing from the downloads? Is the example available somewhere? It's currently broken, which is why it hasn't been added. It's on my bug list but hasn't come up the priority list yet. All I want to do is remove the License dialog as it is not appropriate for internal releases. Is there an easy way to remove it? What the example shows is copying one of the "set" fragments (e.g., WixUI_InstallDir.wxs) and modifying the properties and adding/removing DialogRefs to point to different dialogs. -- sig://boBhttp://bobs.org Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] RFC: Moving Wix 3.0 to use the .NET Framework 2.0
I don't see any problems with this; most of our environments are running VS 2005 or is a Windows 2003 Server as compileserver, on which .NET 2.0is installed for various uses. And i suppose you should think about future development possibilities in new environments such as .NET 2.0 whenever needed. But when it stays on .NET 1.1 it is also fine by me ;) Albert Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Justin RockwoodVerzonden: woensdag 14 juni 2006 22:20Aan: wix-users@lists.sourceforge.netOnderwerp: [WiX-users] RFC: Moving Wix 3.0 to use the .NET Framework 2.0 There has been some talk on the core team about moving Wix 3.0 over to use the .NET Framework 2.0 instead of 1.1. We wanted to know how many people this would affect and in what ways. If you have any concerns about using .NET 2.0, please respond to this email and let us know. Conversely, if moving to .NET 2.0 would help you, please let us know that as well. Thanks, Justin ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
