Why design-time components shouldn’t have install EXEs
Lots of Delphi components and .NET controls ship as EXEs that “install” the design-time component for you. I hate that, and here’s why.
-
Revision-control unfriendly. I don’t want you sticking code under C:\Program Files. It’s code. It needs to be in source control with all my other code. That’s kind of the point of revision control. I want a ZIP that I can extract into my source tree and check in, so that later I can go back to that same point in time and rebuild my code as it was then.
Xceed is the worst offender here. Good WinForms controls, but you can’t put them in Subversion — they have to be “installed” if you’re even going to be able to compile. You have to actually run their stupid installer on every development computer, including the automated build machines. I cannot express how deeply this offends me.
-
Delphi-version unfriendly. If Delphi 2007 comes out and there’s no installer for FooComponentLibrary for Delphi 2007, what do you do? Sure, you can make a new package, compile it, and install. But you could do the same thing if you had a source ZIP, and you wouldn’t have to sit through an installer that might or might not work correctly if its intended version of Delphi isn’t installed.
Of course, if it’s a Delphi component that ships without source code, then you’re screwed anyway, since DCUs aren’t compatible across Delphi versions. But no sane person would ever use a Delphi component that shipped without source code, mainly for this very reason. (Not an issue for WinForms controls, as compiled DLLs are much more version-agnostic than Delphi DCUs.)
-
What about Turbo? The last Delphi version that I personally own is either 3 or 5, I don’t remember which. There’s no way I’ll use it anymore. I’ve been spoiled by strict private and records with methods. When I’m tinkering at home, I use Turbo Delphi Explorer, ’cause it’s free, and sort of recent. But it doesn’t support third-party design-time components. And it doesn’t have a command-line compiler. So what’s going to happen when the installer gets to the “compile and install the package” step? It wouldn’t surprise me if the installer failed and rolled back, leaving me back at square one. I try not to find out.
Component installers are probably meant to make life easier for hobbyists and beginning Delphi developers, but they make life harder for experienced developers — sometimes much harder. So component authors, please, provide a ZIP file. (And please, make it an actual, industry-standard ZIP, not a fringe format like RAR.) For Delphi components, the ZIP should contain the source code. For WinForms components, it could have either the source code, or the compiled DLLs. And in either case, of course you’re including sample code, right?
You can provide an installer too, if you must. But it should be a separate download.
(This rant was provoked by (un)DelphiX, which does provide both an installer and a source RAR (grr), but states fairly prominently that the source archive will be discontinued at some point in the future.)
January 6th, 2008 at 12:37 pm
Don’t understand why it’s bad to offer an installer. There are still many developers that do not work much with packages and don’t know how to go about installing them.
If source code is offered, you can just install it anyway you want after the initial installation. However, for different reasons some component vendors don’t even offer source (like Atozed) and therefore it doesn’t make sense to not provide an automatic installer that takes care of the registering of the design-time packages and path modifications.
January 6th, 2008 at 1:33 pm
In one regard I agree yet in another I *highly* disagree, I may even have to say vehemently.
Part of what I constantly struggle with is how to quickly deploy a build environment, going from a fresh install to a Delphi that can build our products with *minimal* user intervention. Many components won’t work unless you modify the library path and also need to be built/compiled and so if we only had a .zip that means hand adding all the paths into the library and hand building, which becomes a huge pain when you have at least a dozen or more components you need installed. A zip file may be nice for the solo developer but it’s hell when you step up to teams or the corporate level and start caring about automation and solid testing.
So while I agree that it’s better to have something that you can commit into version control there still needs to be some level of automation in installing it in order to build out full dev machines quickly.
For years I’ve wanted CodeGear to create a unified component packager/installer that bundles components correctly and in a way that is both versionable as well being able to worked into an automated script. Instead, because there is no standard and no solid guidelines from CodeGear, we have this hodge-podge of random zip files, massive installers, home-grown third-party utilities and everything in between. Our corporate install document that we give to new developers trying to setup Delphi is 4 pages long and there are at least 6 distinct methods in which various components are installed. It basically sucks.
January 6th, 2008 at 8:35 pm
Hadi: I never said it was bad to offer an installer. I said it was bad to ONLY offer an installer. Make the source (or DCUs) available separately, for those who don’t want the installer crap.
Shawn: So why haven’t you automated it? If you use their installers, it *will* take you four pages and at least half a day to get everything set up. But if you *don’t* use their installer every time you set up a new computer — if you use your revision control well — then setting up a new computer is as simple as setting your PATH correctly and importing one or two Registry keys.
In fact, I think that merits another Mere-Moments Guide. I’ll start working on one.
January 7th, 2008 at 4:21 am
Totally agree. In fact, I’ve been messing around today checking in Report Builder into svn. Would’ve loved to just have a zip of the source. Thank goodness for VMWare. Not looking forward to InfoPower (ugh!).
We’re in the process of linking all third-party code to our projects in svn. That way, all a developer needs on their workstation, is Delphi and svn. The problem with this, which Shawn touched on, is that its ridiculous having to load/unload the design time components, especially when we have quite a few projects. We’ll probably have to write a little script that does the loading/unloading of the components (modify registry) but that requires Delphi to be closed.
January 7th, 2008 at 6:43 am
When we made the switch to Delphi 2007 (from 5 and 7) I was put in charge of testing all of our ThirdParty components. Since we have had sooooo many problems with different versions of thirdparty packages and even our own components, I quickly decided to put everything in subversion.
I’ve put all source and compiled BPLs en DCUs. I decided to register the compiled BPLs en DCUs with Delpi and the source just in the Browsing path. This way, everyone uses the exact same versions of the components.
Then I created a simple program that reads in an XML file that specifies which packages are available (with a name, list of BPLs, List of Source Paths, list of DCU paths). This list is then shown as a TCheckListBox, so you can just select which packages you want installed/uninstalled.
So, when everyone else moved to Delphi 2007, they just had to do a checkout and run my little installer (takes 1 second to install all packages) and they were good to go.
Maybe CodeGear should make a publicly available installer that works in the same way?
January 7th, 2008 at 9:56 am
Zip is on its way out. 7Zip is the future. Faster and better compression, and completely free (open source). http://www.7Zip.com/
Why WinRAR is better then Zip
http://www.codinghorror.com/blog/archives/000798.html
Why 7Zip is better then WinRAR
http://www.codinghorror.com/blog/archives/000799.html
Zip has server us well, but it is past its prime.
January 7th, 2008 at 2:41 pm
Joe: Actually, I *have* automated it as well as I think I can by using Subversion and the excellent MultiInstaller which extracts, compiles and registers components that are inside of zip files. When I get a new EXE installer I run it, commit the new files into svn and roll that into the MultiInstaller build.
I’m not saying it can’t be done, just that it’s silly and a huge waste of time for both component developers and users to not have a unified, structured, standard way to distribute and install components.
I’d be very curious to see a Mere-Moments guide to your process of installing components using just version control in an automated way. The parts that give me headaches are correctly registering the library paths as well as getting the bpls built. I generally consider it a Bad Idea to commit bin artifacts into source control so those bpls need to get built somehow, and some components can have up to 5 or 6 different packages that need to be compiled. Perhaps I’m missing something but I fail to see how proper source control and a few registry entries will get those bpls built for me in an automated fashion.
Anyway, I look forward to your ideas on this, I’ve beat my head against it for so long that it’ll be good to have some fresh perspectives. My goal is to someday just have a nice CruiseControl script that can fully build out a build environment.
Oh, and the 4 page install guide is for our new developers that should know how to install components manually. We make them go through it at least once so they know how.
March 2nd, 2008 at 1:29 pm
[…] is available in two forms: as an installer, and as a RAR file. Component installers are a huge pain, and probably wouldn’t work with Turbo Delphi anyway. So I recommend downloading the RAR. […]