I am sorry for this stupid question, but I really need to install version 3.9 of the Wix Toolset. I can only find version 3.10 and 3.11. There is a link on the website to download older archives (also for 3.9rc2), but in this 1.2Gb file I cannot find an installer.
Please do not tell me to install the latest version, I have my own reasons for 3.9 that goes beyond the scope of this question. Any help is truely appreciated.
I should leave this for the WiX guys to answer, but maybe you are very busy and just need to test something?
Building it yourself from the sources isn't an option is it? https://github.com/wixtoolset/wix3/releases (towards the bottom, click the blue image - it says "Show 5 other tags" here). Sounds painful to work that out...
The 3.9 binaries seem to be here (looks like R1): https://github.com/continuoustests/ContinuousTests/tree/master/Installer/ContinuousTests.WixInstaller/wix39-binaries, but not as an installer file. Maybe you just need to test something quickly? If so, obviously please accept your own risk here, I am not sure what these files really are.
I hope I haven't linked to something that is problematic, just delete the whole answer if this should be the case (i.e the binaries pointed to should not ever be used - for some reason, etc...).
I recently had a need to get the old wix38.exe installer for legacy project maintenance, and it was a pain. Tom Blodget's comment above was the key on how to find the required file from the CodePlex archive.
Because there are likely to be other people in the future who require access to these things, I've created a github repository https://github.com/CasaDeRobison/wixtoolset-codeplex that includes the state of the git repository from the CodePlex archive and also makes available the various files from those releases at https://github.com/CasaDeRobison/wixtoolset-codeplex/tree/master/archived-stable-versions
Hopefully others will find this useful as well so that we don't all have to collectively puzzle this out if we have a need for this older software.
Related
Firstly, I saw some topics about these two but weren't my answer.
I'm looking for a good FPC(Free Pascal Compiler) IDE on GNU/Linux.
There are some IDE's like Lazarus and CodeTyphon. I need suggestion to choose one of those.
I've tried Lazarus once but all windows was separated. It looks messy and not interesting.
I would like to know what are the distinguishes between these two ?
I would like to know advantages / disadvantages each of those. Thank you
CodeTyphon is a distro of Lazarus, like Ubuntu and Debian are distros of Linux.
CodeTyphon comes with a large package of components and plugins, that otherwise you would have to google and download and install.
CodeTyphon have their own idea what are stable versions and what are not stable yet for both of FPC (compiler) and Lazarus(IDE). Whether their assessment is better or worse than upstream's Lazarus Team's, I don't know.
What about one-single-window plugin, it is work-in-progress and it doesn't seems to me it is ready for production use, no matter would you get it as part of CT or download and add it to vanilla Lazarus. However maybe it better works on Linux than on Windows, I don't know.
There were however issues with code legality in CT grande bundle. It is widely believed that Orca (if I remember the name) violates copyrights of glScene/vgScene, which also happened in early Delphi FMX releases but was fixed by EMBA later. There also were disputes in FPC forums/wiki about CodeTyphon pirating some open-source components. See answer by Peter Dunne below.
Your question is akin to asking the difference between Linux and Ubuntu. Lazarus is an IDE/component library, based on FreePascal (FPC). And CodeTyphon is a distribution of Lazarus and FPC. So CodeTyphon is just one way to install a functioning installation of Lazarus.
Lazarus uses the same floating window design as older versions of Delphi. Installing from CodeTyphon won't change that.
Myself and several friends highlighted several licensing issues with codetyphon
most of which could have been corrected by sourcing the included files from known good source and ensuring the correct license headers were included
PirateLogic refused to correct the issues which means they are using code in direct violation of the original license terms
The fact its open source code does not change the fact they are pirating the code by not including the correct license even after the issue was highlighted
I also found several instances of copyright code included which appears to be proprietary and not FOSS at all
They also changed the path & file names on some libraries so that source is no longer compatible with standard lazarus/component installs
This in my view is totally illogical
These 2 factors heavily undermine what was potentially the best FPC/Lazarus distro
Hardly professional
Lazarus can be a daunting installation process due to it's nature as a cross compiling environment. You don't just download an installer and click ok. A typical "installation" is actually a bootstrap FPC compiler doing a three-pass compilation of an "install". There are plenty of good installation scripts/methods from the official Lazarus/FPC team and in the community for a . But, understandably, the installation process is a skill in itself.
CodeTyphon is a a different/separate branch of an installer system, which is more of a utility suite/tools/third party code compilation library. If you want the simplest installation experience go with CodeTyphon. It has the nice graphical front end for managing the compiler. You can conveniently do the fancy stuff like build "cross-compilers" for almost every "target" operating system out there. It also is jam packed with hundreds of the best components/libraries pre-installed. It is a very actively maintained project and very professional. A whole lot of work is done for you.
Even if you want to be learn the low level compiler capabilities, CodeTyphon is a good place to start. It is written in FCP/Lazarus and is open source. Simply study it as "working demo app" and the other info on the compiler details. If you crash it, at least you don't have to learn to climb the hill. You get to get to start from the top and lose control on the way down. Start from scratch (and a three hour reinstallation) Hahaha
Lazarus also has a package "AnchorDock" which allows you to dock all the windows into one. Either install the anchor dock design package after installing Lazarus, or install Lazarus using the script at getlazarus.org which will do it for you.
I have written a plugin for an application which has an installer as an executable. My plugin is installed using an msi, written in wix. We've now been given permission to distribute the two together. Ideally, this would be in a single file with two installations. Both parts would need to be updated seperately, particularly the main program, I have read that this restricts the methods of installation.
I'm having trouble installing the main program first, then the plugin. I have tried including this main exe in the wix as a custom action, but I'm worried that this will mess things up when either program needs updating. I have seen something called an MsiEmbeddedChainer but can't seem to find anywhere that describes how to implement it.
Any advice, or pointers of useful articles would be greatly appreciated.
Most of what you need to know is linked from the Not supported in Windows Installer 4.0 document, but it will likely still take a lot of trial and error. This blog post has a lot of interesting points to help with rough patches along the way. However let me warn you that my experience with InstallShield has shown that MsiEmbeddedChainer chaining is not as reliable as bootstrap chaining, at least in environments with Terminal Services.
I specifically want to be able to use Ackmate bundle, peepcode (the new 'Go to file' seems good enough) and some other custom bundles with TM2.
I tried moving the existing bundles to a location
~/Library/Application Support/TextMate/Managed/Bundles/Managed
which seem to contain all the new installed bundles, and a few other hack. But no luck yet.
I did manage to get the older themes working with TM2 though, with an approach similar to the one above.
EDIT:
I found this article on the topic.But still not able to get some older bundles to work.
http://blog.macromates.com/2011/locating-bundles/
Just copy all your bundles from ~/Library/Application\ Support/TextMate/Bundles to ~/Library/Application\ Support/Avian/Bundles/
I did not find much success with the above. I guess its stil in 'Alpha'. Although you might try to drop some of the older bundles into
~/Library/Application Support/Avian/Pristine Copy/Bundles
to get it working with some hacks for now.I have managed to get Cucumber, Uber Glory and some of my custom bundles working.
Also you can follow the README of this Whitespace bundle to figure out which directory to place your new bundles in. This seems to be only bundle (not packaged) exculsively for TM2 so far.
The Textmate url that explains the difference between
Avian/Pristine Copy/Bundles/
and
Avian/Bundles/
is here:
http://blog.macromates.com/2011/locating-bundles/
It didn't recognize my old bundles at first, but the second restart of the app worked for me.
Since this is alpha software, I think that the mailing list is the best venue for your question. Either way, I haven't yet seen anything definitive on the backward compatibility of bundle support.
Sometimes I did some mistake. After that I made some bug and for some reason the program won't run. I want to go back to previous version. How would I do that?
In xCode 4 you can create a local git repository on creating a project. Look here.
If you are not using xCode 4, you can use external tools for git or svn. Just google for it, you will find a lot of solutions!
You need to use a revision control system. This is a big topic, so start by reading the Wikipedia page.
Xcode has support for a few revision control systems. This question discusses most of them, but git support wasn't available back then (although, personally, I have an irrational hatred of git).
I found that Wix v3 uses a tool (heat.exe) to "harvest" information into WiX fragments. Either I am looking in the wrong location, or this is thinly documented.
What is the best way to auto-generate a WiX fragment (likely using heat.exe) for a complex folder structure that contains media files:
Of varying types (ico/png/xaml/etc)
That may change regularly (names/locations/adds/removes)
That are classified as "Content" and included in a .csproj
such that they can be built into an installer via WiX and would withstand upgrades and patches with decorum?
Background Information
I found heat.exe, which seems to solve the autogenerate WiX fragment requirement
In getting the "dir" harvester working, I noticed the "project" harvester (commandline help)
Media is already in C# project file, and so noted that "-pog:Content" might do very well
Cursory search found out of date documentation that didn't mention "project" harvester
Realized entire project installer could probably done with "project" harvester, but was unsure how well this was supported, and what the pitfalls were.
Saw the generation of "PUT-GUID-HERE" and realized that autogeneration of guids would likely have upgrade/patch implications.
Realized that there must be people who use these tools for similar purposes and could probably point me in the right direction.
It was (fairly) pointed out that v3 is not yet "done" (thus the scarceness of documentation and tutorials). The sense that I get now is that it is non-trivial to automate this in my build scripts, and the tools are growing right now to ease this.
In my experience John Robbins' Paraffin solves alot of the issues with tallow.exe (heat.exe in v3). I'm not sure if Paraffin plays nicely with v3, but it might be worth checking out.
FYI, I've used Paraffin in a build process and it allowed me to remove the previous 2-3 step cleanup process that involved a powershell script.
For the upgrade implications of auto-generated setups, read this. The take-home message:
Windows Installer doesn’t let you
remove components in a minor upgrade
It is hard to guarantee that components continue to exist if you generate your setup automatically. Therefore you have to chose between auto-generation of components and the ability to do minor upgrades.
If you have some auto-generated components, then just stick to major upgrades. You can use this sample by Rob as an example.
Thanks for the background, I wasn't aware that they were working on a new version of Wix. According to the project page, it isn't RTM yet, so that may explain the problems you're having. I hope to hear from the WIX developers in one of the replies.
I can't help you use the under-development heat.exe features. However, I have been in your situation and my solution was to create a tool that took directory and file information as input and generated valid wix project files as output. A .vsproj file is just an XML file, and you can use XSL, C#'s LINQ, PowerShell, or a number of other tools to do the work. I personally have used (pre-LINQ) C#/XMLDOM to parse VS project files for this purpose.
Good Luck,
Dave
For documentation, check out the help file that is installed with WiX - WiX.chm provides the most up to date information (along with the command line -help option).