Now that I am learning more about design time aspects of component development, I have what may turn out to be a couple of IDE "plugins" targeting Delphi 2007 (+ others if compatible).
The forms / UI for these, ideally, will utilize some of the third party components I use regularly. Assuming the licensing is okay to distribute those components for an IDE plugin, etc., what do I need to do differently to prepare the distribution package, as compared to from what one would do on a package with "full source"?
(I hope this question makes sense. Please be kind and ask questions if not).
You need to distribute the BPL compiled for each version of Delphi you will support (Version + Update) and then only distribute the BPL. Set up a Virtual Machine to test it in. The BPL is a special DLL, so you are only distributing a binary, which should work with your licenses.
Distributing the .PAS or .DCU would violate the license agreement most likely.
You will probably find that this causes all sorts of problems.
GExperts does it differently. It is a DLL that statically links to some 3rd party controls and references only Delphi's own runtime packages. This cannot cause any conflicts with other packages because the statically linked units are not visible to the IDE. It also means that GExperts does not need to distribute any runtime packages.
Do not distribute those components in your design-time package. It will cause headaches for you and your customers if your customers also happen to want to use those same components in their own projects. If you put those components' units in your design-time package, then your customers will not be able to also have their own copy of those components installed on the Tool Palette because only one copy of a unit may be loaded at a time.
The components you're using should have come in a run-time package from their vendor already. Put that package in your design-time package's "requires" list. Distribute the .bpl file only; I think you can install it in the same directory as your design-time package.
That run-time package will also be a requirement of the vendor's design-time package, which is what your customers will have installed in their IDE.
Related
Using Embarcadero RAD Studio XE7, I wrote a runtime package containing a VCL component (it's a TGraphic descendent). Now I want to distribute this component, but only the compiled package without his source code. I cannot include it in the distribution because I wrote this package for a company that want to sell it and keep the control on his sources, so distributing the source code isn't an alternative in this case.
The component package depends on 2 other packages I also wrote. All of these packages are runtime, however a graphic filter is registered. After the package is installed, this filter allows me to open a new kind of image file from several native VCL components like TImage on my development computer. This behavior is very important and I want to keep it on the target IDEs.
Ideally I want my package to be installed on all RAD Studio platforms between XE and 10.2 Berlin. However I recently tried to compile my package in release on my devel computer and deploy it manually on another computer installed with RAD Studio XE4. The result was unconvincing:
Trying to install the .bpl file using the Component->Install packages... failed with a "The specified module could not be found" error. When opening the .bpl file with the Dependency Walker tool, I noticed that several dependencies like RTL210.bpl were missing
I also read somewhere that only design time package may be installed this way, it is exact?
Putting all the files (.bpl, .lib, .hpp, ...) of one of my package manually in the XE4 common dirs, I was able to compile a test project successfully. However several functions in my package were unavailable (resulting to an unresolved external when trying to use them)
Although I have several past experience about software and package distribution, I must confess that I have absolutely no idea about how to build a such package for deployment. In all my past scenarios I always distributed the package projects and source codes, and let the user install them on their own IDE.
I searched information about that in the past days but I found nothing. So if somebody can explain how to achieve a such package, or can point me to a document or website describing the process, or eventually give the name of a tool that can do the job, I would be very grateful to him.
Regards
If you don't want to to distribute the source files, you then need to provide the .dcu and bpl files. As Uwe says, you need different packages for each Delphi distribution.
What I have done in the past is to create an installer which builds and registers the packages. You can find the full description here:
http://www.kouraklis.com/2016/10/build-and-install-packages-in-delphi-ide-using-innosetup/
I think you can modify the script to skip the call to MSBuild.
Hope this helps.
Installing components under Delphi XE3 is a nightmare.
First I need to add source files to
Tools -> Options -> Library
then I need to find a normal package and compile it
finally I need to find design time package and install it.
This is just quite tedious and error prone. Is there a nicer way to install components?
I have found Delphi Package Installer. Unfortunately it doesn't support Delphi XE3 or above.
I have heard that there is something similar which produces exe packages that install themselves (something like Inno Setup) but I can't find such thing.
No. The steps above are required.
First, adding the file path to Tools->Options->Delphi Options->Library Path is so the compiler knows where to find the files to compile them. (Actually, it's not required - you can eliminate this step by making sure that the .dpk files are in the same folder as the .pas files, and that all .pas file names are listed in the includes section in the .dpk. If the .pas files are in a different location, you'll need to either use relative paths in the .dpk (eg., MyComponents in '..\Source\MyComponents.pas') or add the location of the .pas files to Project->Options->Delphi Compiler->Search Path.)
The next step (finding the "normal package") is in order to build the runtime package. It's required, because the design-time package (next step) requires the code that's in that package in order to function in the Form Designer. It's also needed when you decide to build your application with runtime packages, if you use the third-party components and want to distribute the runtime package for it.
The separate design-time package (the third step) is required because designtime code can only be used at design-time; there's nothing that can be distributed with an application if it's built with runtime packages and the package build in step 2 is one of them.
This has been the way components are installed since around Delphi 3 or so, and the requirement to separate out designtime code into it's own package started being advised in Delphi 5 and enforced in Delphi 6 (when they relocated much of the IDE designtime support into their own separate packages and stopped distributing the source for them).
There really are no other options, unless the vendor supplies pre-build designtime and runtime packages for you, or supplies an installer that will do all of the above steps. (Most don't.) But if you update your Delphi version, you'd still have to go through the steps above.
What about the built-in component installer? It is part of Delphi XE, XE2 and XE3 and a description can be found here (I wrote it). It will even install components in C++Builder. You can instal into an existing package or into a new one, which it will create for you.
I would say that the best way to install components is to use your build manager (for example FinalBuilder) and add each component to a manager-project file which sets the necessary paths, builds the DPK files, and 'installs' the component in the IDE by making a registry entry. That way you have a documented procedure which allows you reliably to set up or repair your complete, tested, Delphi development environment. You can simply re-run the project when a component has been updated and tested. It is also quite easy to tweak an existing project to handle a new Delphi version.
The big disadvantage of a vendor-supplied installer is that all the ones I have seen simply overwrite the previous version on updates. I prefer to control the install myself, so that I have previous component source versions archived and available for comparison, in case testing reveals a problem with an upgrade. The 'one-click install' sounds fine, until a minor component upgrade suddenly causes your application to stop working.
Take a look at "Lazy Delphi Builder". It was created to simplify build/installation of many components at once. It resolves packages dependencies automatically. Free to use.
Link to some old tutorial
I'm trying to make a package for a custom component I made. It's based on several libraries, including Graphics32, GraphicEx and CCR.Exif.
I created a Package project, wrote the unit including its Register procedure, added some extra references Delphi notified me about to the requires section (including dbrtl.dcp, inet.dcp, soaprtl.dcp, vclimg.dcp, xmlrtl.dcp and dclGraphicEx140.dcp) and added many units to the contains section to avoid warnings about it happening implicitly. The project compiles and can be installed and used on my own machine without issues. However, when I want to install it on another machine, the troubles begin. In the end, I had to copy about all DCUs from all 3rd party components I used, plus both the DCP and BPL from GraphicEx, which I had to install even.
Supplying a lot of files is a bummer, yet surmountable, but having to install other packages as well is a no go. I could get rid of that DCP and BPL by putting even more units in the contains section, but that resulted in error messages on my own machine where GraphicEx is actually installed. This is confusing to me, because with Graphics32 nothing like that occurs...
Anyway, how do I keep my distribution to a minimum and avoid such situations? I want other developers on my team to be able to use the package without worrying about what I used to build it. For a start, can't all the 3rd party units be compiled into my own DCU?
What you experienced is an usual thing to the ones who write components. The distribution is always like that. Packages do not carry other packages, insted they reference them. It´s in their nature.
In order to overcome such a situation I always treat my components in the same way I would if they were a product to sell: I build a setup wizard that distributes and registers everything the package needs.
In my case InnoSetup works very well (http://www.jrsoftware.org/isinfo.php).
Summary
Haven't use Delphi for a while, but, did develop my custom visual controls (Last version I work was Delphi 6).
There are 2 issues when dealing with packages dependencies. One is installing at the Delphi enviroment, making controls appear on the component palette, plus, component editors & property editors.
And another when distributing the compiled packages into customers machines.
It also depends, on which version on Delphi you are running.
Design Time
When developing a custom package, there is a tab for package options, that indicates the destination folders.
The manuals usually tell the developers to leave those textboxes empty. That sometimes works, sometimes doesn't. I explicity write each folder path, in the respective textbox.
There is a textbox path for the ".dcp" files, other for the ".dcu", and so on.
If you have visual controls and stuff like property editors or component editors, its better to split the code in 2 packages ("Runtime" & "Designtime").
I usually put the delphi (packages) projects outside the delphi installation folder.
Run Time
Usually, the quick way is to put the "*.bpl" ".dcp" files in the Windows (32) / system folder, or similar "DLL" windows folder.
Packages folder structure source code suggestion
Managing packages can be difficult. I don't know how much the installation process has changed with Embarcadero, and the newer versions of Delphi. The following chart,is an example on how organize the source code. Hope it helps.
[-]--+--c:
.....|
.....+--[-]--+--software
.............|
.............+--[+]-----java
.............|
.............+--[+]-----php
.............|
.............+--[-]--+--delphi (not the delphi folder in program files)
.....................|
.....................+--[+]-----apps (source code for delphi programs)
.....................|
.....................+--[+]-----other
.....................|
.....................+--[-]--+--packages (all delphi packages source code here)
.............................|
.............................+--[+]-----lib (a single package for non visual controls, libraries)
.............................|
.............................+--[+]-----tools (package pair for non visual tcomponent descendants)
.............................|
.............................+--[+]-----json (example)
.............................|
.............................+--[+]-----xml (example)
.............................|
.............................+--[-]--+--mycontrols (folder custom visual controls)
.............................|.......|
.............................|.......+--[-]--+--delphi40 (folder for delphi40 version of "mycontrols")
.............................|.......|.......|
.............................|.......|.......+----------dsgvclctrls40.dpk (design-time package "mycontrols")
.............................|.......|.......|
.............................|.......|.......+----------runvclctrls40.dpk (run-time package "mycontrols")
.............................|.......|.......|
.............................|.......|.......+--[+]--+--demos (individual example for each "mycontrol")
.............................|.......|.......|
.............................|.......|.......+--[+]--+--design ("*.pas" component editors destination folder)
.............................|.......|.......|
.............................|.......|.......+--[+]--+--sources ("*.pas" source code destination folder)
.............................|.......|.......|
.............................|.......|.......+--[+]--+--bin ("*.dcu" destination folder)
.............................|.......|........
.............................|.......+--[+]--+--delphi50 (folder for delphi50 version of "mycontrols")
.............................|.......|........
.............................|.......+--[+]--+--delphi60 (folder for delphi60 version of "mycontrols")
.............................|.......|........
.............................|.......+--[+]--+--delphi70 (folder for delphi70 version of "mycontrols")
.............................|................
.............................+--[-]-----etc...
Cheers.
Thijs, you simply cannot do that with only a package. The target developer will require almost everything you added to the package. But there is an alternate way of doing what you want: Build a DLL with all the components/libraries you are using in your own component and wrap all those external components/libraries into some code you will export from the DLL. Then build your component without using the external components directly but the DLL you've built. You cannot in you component "use" any unit of the other external components/Libraries. You have to build a new unit with all the datatypes and required declaration for anything you export from your DLL. All this is perfectly working but will quickly becomes very complex for a large number of external components or libraries.
I think AlexSC has the best answer, but I think there might be an alternative if you ansolutely must have a custom component that has no dependencies.
I ran into the Delphi dependency frustrations a little while back trying to create an in-house component for our developers. My suggestion:
Uninstall all dependencies your component uses
In your component package, remove the above dcp from the requires section from your package.
Copy the source files of your dependencies to your components
When you distribute the component, you'll have to distibute it with the code of the required dependecies
You'll run into issues if you want to use the dependcies separately since Delphi won't allow you to have duplicate unit names in installed packages.
Also, the reason you don't want to use DCUs is the fact that the DCUs are compiled for a specific platform and compiler. So unless you are sure that all devolpers are on the same platform ad using the same version of Delphi, dependency code needs to be recompiled.
Again, AlexSC has the best answer and InnoStudio is a great little tool.
I'm writing delphi app which should have capability of loading plugins. I'm using JvPluginManager as plugin system/manager ;) Now, in the new plugin wizard they say it's better to use .bpl type plugins instead of .dll plugins ... What are the pros of this solution versus dll type plugins?
So far I've found only cons of this solution:
I have to put all the common interface units in separate package so that while loading plugins it won't throw any error about the other package containing common unit
if, let's say, one of plugin developers decides to uses some well-known unit (like synapse), which doesn't have runtime package by default, and the second plugin developer does the same, than bump... it's crash here ...
So, what are actually the pros of using bpls instead of dlls compiled with runtime packages?
Thanks in advance
Another disadvantage to BPL's. When you switch Delphi versions you will have to re-distribute new plugins. After many attempts at attempting to find the perfect plugin system, I ended up with COM and I have never regretted that decision. In a commercial application which has had the plugin requirement for over 8 years, the application has continued to move forward and yet some of the plugins that were released with the first iteration still exist in their ORIGINAL form.
If you choose this method, do yourself a favor and start with a simple interface and then add new interfaces upon it. You don't want to ever change your base interface, so keep it simple and sweet.
As Alexander said, a BPL is basically a DLL. But there are some conditions (from a not-so-short summary I made: http://wiki.freepascal.org/packages ):
A unit can only exist once in BPL's +Exe. This avoids duplication of state (twice the heapmanager and other global vars of system etc, VMT tables etc)
.BPL's can only USE other .BPLs.
This means that dynamic types like ansistring and IS/AS work properly over BPL interfaces.
Initialization/finalization are separate procedure and their initialization order is strictly controlled. For static dynamic loading this is simpler, for dynamic loading (plugin-like) all dependancies on units are checked .
Everything is essentially one big program, which means that the BPL's must be compiled with the same compiler version and RTL and depends on the versions other dependancies. It might be harder to make .BPL's to plugin to an existing EXE, since the Delphi version must match.
This also means that you must deliver .dcp's for (non Delphi) .BPLs the plugin .BPLs depend on
In short: if the plugin architecture is open, make it a DLL. Otherwise people have to have the exact same Delphi version to write plugins.
Hybrid is also possible. An higher level .BPL interface for functionality you factor out into .BPL yourself and selected devels, and a rock bottom procedure DLL interface for the rest.
A third option is using DLLs, but ordain Sharemem. Strings will work, multiple Delphi versions will work. Objects can work but are unsafe (e.g. I guess e.g. D2009 with an earlier version wouldn't work). Even other language users might be able to allocate over COM, not entirely excluding non Delphi.
Your first con is also a pro. If you replicate shared code in each dll the dlls get bigger and bigger. Even when using dlls you can prevent this by moving shared code in a separate dll.
Pros:
Types are shared. No TFont is not a TFont problem
Memory manager is shared. Strings and classes can be used as parameter between plugins without problems.
Cons:
Plugins can be built using Delphi or BCB only.
Plugins should use the same Delphi or BCB version.
Have you considerd using COM? COM makes it possible to share types, strings and classes and the plugins can be written in many programming languages.
I'm not familiar of JvPluginManager, but it depends on how you're going to use BPLs.
Basically, BPL - is just a usual DLL, but its initialization/finalization work is stripped from DllMain to separate functions: 'Initialize'/'Finalize'.
So, if you're going to use BPL like usual DLL, there are no cons that I'm aware of, only pros: there will be no more troubles with DllMain. That's all. The only difference.
But BPL in Delphi also provide a convient way to share code. This means great advantages (common memory manager, no duplicated code, etc, etc). So usual BPL does a lot more than "being just a DLL".
But this also means, that now your plugin system is limited to Delphi only (well, may be C++ Builder too). I.e. both plugins and exe MUST be compiled in the very same compiler to run smoothly.
If this is acceptable for you (i.e. no MS Visual Studio, no, sir, never) - then go ahead, you can use all power of BPLs.
P.S. But upgrading such BPLs plugins can be also a nightmare, if you do not design interface side carefully. In certain worst cases, you may need to recompile everything.
P.P.S. Like I said: I have no idea, how it is applied to plugins, created by JvPluginManager.
Avoid blp approach as you will have to ship a big bag of bpl with you software and thus, distribution will become bulky.
why do we use Delphi to compile small stand alone programs that just RUN anywhere without any runtime dependency. Using bpls means defeating this very purpose.
I don't know as to how comfortable you are with DLLs, but I would suggest you to use DLLs.
This will give other developers (who
may get interested in your software)
a chance to use any development
language (as long as that language
can spit out dll) to write their own
plugins that can be used in your
developed software.
Another thing is that you will be
saved from Delphi's vcl version
dependency tyranny. A major weak
point of Delphi till date.
I have a Delphi DLL that houses a form which uses a variety of third party components. This DLL is used by many different versions of Delphi. I compile the third party components into the DLL. I believe I still need to link to some "base" Delphi packages like rtl, vcl, etc, so my DLL will use the same memory manager and other global resources that the Delphi IDE is using. How do I find out what BPLs I need to link to?
Ideally I'd like to point some utility at my DLL or project and have it list every BPL that it would depend on if I was only using BPL's and had no source files available. Then I could view that list and pick the packages I want to load at runtime. The current list given in the project properties under "Runtime Packages" is incomplete (as it has been tweaked over the years).
Check a tool I wrote called "Required" - you can download from http://www.drbob42.com/tools
Check the "Build with Runtime Packages", leaving the whole list of packages the way it is.
Do a Project|Build (not compile!). After the build completes, use Project|View Information on ; the resulting dialog will give you a list of the actual packages you need to distribute.
After Jeremy's comment about the default list of packages being empty when he enables building with packages, here's the list from that options dialog from Delphi 2010:
vclx;vcl;vclimg;dbrtl;Rave77VCL;bdertl;rtl;vclactnband;xmlrtl;
vcldb;vcldbx;vcltouch;dsnap;dsnapcon;TeeUI;TeeDB;Tee;vclib;
ibxpress;adortl;IndyCore;IndySystem;IndyProtocols;inet;
intrawebdb_100_140;Intraweb_100_140;VclSmp;vclie;inetdb;
webdsnap;websnap;inetdbbde;inetdbxpress;soaprtl;vclribbon;
DbxCommonDriver;DbxClientDriver;DBXInterBaseDriver;DBXMySQLDriver;
dbexpress;dbxcds;SynEdit_R2009
You can evaluate tools like, Dependency Walker (depends) or PE Information (image bellow) included at GExperts.
"This DLL is used by many different versions of Delphi."
Do you mean that you have programs written with Delphi 7 and other programs written with Delphi 2007 etc. that use the same precompiled DLL?
In that case you cannot use any packages to share object types and memory between program and DLL because they will use different versions of the packages wich are not compatible.