I need the packages to be defined correctly, as it causes problems with our build when they are not,
I have to update the code myself each time we update so I am request this to avoid it in the future.

I am using XE6
are all marked as designtime and runtime when it appears to be 100% runtime.

VCL_FlexCel_ComponentsDESIGN200.bpl  is marked as designtime and runtime when it requires DesignIDE can only be designtime.


The thing is: We do install the runtime packages in the IDE. And for that, they must be "designtime and runtime". If they are only runtime, the option to install them is disabled.

Now, the reason we install the runtime packages in the IDE is just so Delphi finds them, even if they are not in the system PATH. The story goes like this:

BPLs are supposed to be in the system path, so when you run an app using packages outside of the IDE, the app can find the bpls. We don't really like to dump the bpls into the default delphi folder (but that's a story for another post...), so originally we had an option in the setup to add the packages to the System path. The problem of course was that every component does the same, and the Windows path is limited to something like about 1k (path is compressed, so this isn't exact, and I don't remember the exact number anyway). So soon people was getting paths longer than what Windows supports, which doesn't give you any error, but it doesn't work.

But note that technically, changing the system path is only needed for people running with runtime packages: As long as the package is registered in Delphi, Delphi will find it in normal use, even if you don't add it to the path.

So that's the reason we mark those packages as designtime and runtime: So we can register them and people who didn't modify the system path will still be able to use them.

Now, since 6.6 we changed the system and we don't modify the path anymore. The new method came as I was thinking how much simpler this is in the unix/linux world. There you don't modify the path for every new executable, you just drop the binaries in their correct place and then create a symbolic link to /bin or /usr/bin. So thinking about it, I didn't see a reason why we can't do the same in Windows. Since Vista symbolic links are fully supported, and we could then send the bpls to the correct folder, but then add a link to the "delphi bpls" so it will be in the system path. If you are installing in XP (which you shouldn't...) then the setup just offers to modify the path as before. For newer Windows versions, we offer to create symbolic links instead.

I think the symbolic link route is the best of both worlds: It allow us to keep the bpls inside our folder, but we don't need to mess with the system path. And except for some teething problems in the first 6.6. release has been working flawlessly (you can find the posts in this newsgroup when that happened)

But it is too soon yet to know if they are a 100% perfect solution, and so at least for now and until this is more tested, I prefer to keep registering the runtime packages in Delphi. This way even if the symbolic links don't work, your apps will work fine as long as they don't use runtime packages. 

About VCL_FlexCel_ComponentsDESIGN200.bpl you are completely right, it could be design time only. But I wonder if it will make any difference to you that we change that one, if we don't change the others. The reason this package is runtime and designtime is just to avoid "special cases" We need to test FlexCel in many Delphi versions (from XE to XE7 and counting), and the less special cases we have the better. So if all the other packages are runtime and design time, it made sense to make this other one too, even if technically it won't be used at runtime. One less special case to test. Given the complexity of the setup and all the existing options, I am not sure changing it to "designtime only" won't break anything, and we have to test this in all supported delphi (and c++ builder) versions. So unless it is really critical for you I would prefer to keep it as is. (the last change I made in the setup were the symbolic links, and even when I tested it here for weeks, the same day I published I started getting reports of them not working, as you can see in other posts in this group)


We have 200+packages to manage so we open up the BPL check to see if they are runtime only or runtime & designtime and then deploy them with our application.     It's a nightmare to manage any other way.

So at the very least can you please mark the design time only package that way we don't deploy them.   I have to say that flexcel is far better than some of the other TMS libraries that I posted about, in other forums.  


I can see your point. I've updated the build process so the design time only packages are now marked as designtime only. I am now testing that nothing brea, but the build process is slow, it takes about 14 hours, and I have to manually test this change isn't breaking anything, so this will probably be ready for tomorrow. If you need it urgently email me to and I'll send you a version as soon as it is ready. But I assume you've already modified the packages, so you don't really need it urgently, just to be like this in the next release?

About the runtime packages, as explained in the other mail I am not ready to make them "runtime only" since I still want to register them on the IDE. But after answering yesterday, I got thinking that what I could send you is a little pascal snippet similar to the one we use here that you could run after installing FlexCel and it would mark those packages as "runtime only". This way at least you won't have to do it manually. I am not sure if that is really needed, or just having the design packages as "design only" will be enough?

Correct, I have already modified it, and can wait until the next release. Having them marked design only is enough.   

I can understand the point of view on the need to install them into the IDE.    It's an interesting idea to use symbolic links to the files.    We use the Path, but don't use the global one, we override it in the IDE environment settings.