Back with limited service... data recovery expected to go late into Friday night. Hopefully after that, *everything* will be back.
On Wed, Sep 11, 2013 at 9:18 PM, Albert van Peppen <alb...@insad.nl> wrote: > 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. > > <?xml version="1.0" encoding="utf-8"?> > <!-- > 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' > "> > .... > <DebugWix>True</DebugWix> > </PropertyGroup> > > <Import Project="..\..\Tools\Targets\DebugWix.targets" /> --> > <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003";> > <PropertyGroup> > <!-- Root of SVN tree, defaults to my primary development > configuration, includes trialing backslash --> > <SvnInstallsDirSl Condition=" '$(SvnInstallsDirSl)' == '' > ">C:\Development\Installs\</SvnInstallsDirSl> > > <DebugWix Condition=" '$(DebugWix)' == '' ">False</DebugWix> > <WixToolPath Condition=" '$(DebugWix)' == 'True' > ">$(SvnInstallsDirSl)Tools\WiX_3.8_Debug\build\debug\x86\</WixToolPath> > <WixTargetsPath Condition=" '$(DebugWix)' == 'True' > ">$(WixToolPath)\Wix.targets</WixTargetsPath> > <WixTasksPath Condition=" '$(DebugWix)' == 'True' > ">$(WixToolPath)\wixtasks.dll</WixTasksPath> > <LuxTargetsPath Condition=" '$(DebugWix)' == 'True' > ">$(WixToolPath)\Lux.targets</LuxTargetsPath> > <LuxTasksPath Condition=" '$(DebugWix)' == 'True' > ">$(WixToolPath)\LuxTasks.dll</LuxTasksPath> > <!-- Observed ICE validation errors when: $(WIX) was set to default > 3.7 installation and the above Properties were set to Wix 3.8 in > the SVN > ...\Tools archive.--> > <WIX Condition=" '$(DebugWix)' == 'True' ">$(WixToolPath)</WIX> > > <DefineConstants Condition=" '$(DebugWix)' == 'True' > ">Debug;TRACE</DefineConstants> > </PropertyGroup> > > </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 be > easier. > Phill > > > > > > > > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Is-the-website-wixtoolset-org-down-tp7588837p7588897.html > Sent from the wix-users mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. Consolidate legacy IT systems to a single system of record for IT 2. > Standardize and globalize service processes across IT 3. Implement > zero-touch automation to replace manual, redundant tasks > http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. Consolidate legacy IT systems to a single system of record for IT > 2. Standardize and globalize service processes across IT > 3. Implement zero-touch automation to replace manual, redundant tasks > http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
