views:

154

answers:

3

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).

+3  A: 

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.

Jim McKeeth
+1  A: 

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.

Rob Kennedy
This unfortunately does not solve the issue that the component publisher could release an updated .bpl wich contains the same unit names but is incompatible with the old .bpl. In that case Delphi will refuse to load either the components or the plugin because of duplicate unit names or missing entry points.
dummzeuch
The risk of the vendor releasing a new BPL incompatible with previous releases is always present, but it's also the vendor's fault for breaking existing consumers of the BPL by removing something from a published interface.
Rob Kennedy
+1  A: 

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.

dummzeuch