Houston we probable have a problem...

Houston we probable have a problem...
I'm not 100% sure but close enough to be sure. It is about using of the TurboPack components simultaneously in the Berlin and Seattle.

Part one - how to...
1. Install and register "Delphi 10.1 Berlin" without uninstall of "Delphi 10 Seattle";
2. Use "Delphi 10.1 Berlin" - everything is ok;
3. Install the third party components from some folders - no problems;
4. Install something from GetIt - for example VirtualTree(TurboPack);
5. Try to build and after that to run a project from "Delphi 10.1 Berlin" - without problems;
6. Stop the "Delphi 10.1 Berlin" and try to do the same from "Delphi 10 Seattle". Upss... (for me - access violations and... problems);


Where is the problem? I think that it is a cumulative.

1. The installation of the "Delphi 10.1 Berlin" added an information in the environment/System variables of the OS:
- in the beginning of the values for "Variable=Path"... "C:\Users\Public\Documents\Embarcadero\Studio\18.0\Bpl"

So... most probable - "Delphi 10 Seattle" looking for bpl's - first in this folder: "...Studio\18.0\Bpl"


2. The packages version of the Berlin must be 240.
I'm not so sure but... look at this page:
http://docwiki.embarcadero.com/RADStudio/Berlin/en/Compiler_Versions

So I think that as a result - the packages for VirtualTree (and so on... from TurboPack) must be something like:
- "VirtualTreesDD240.bpl"
- "VirtualTreesDR240.bpl"
For AsyncPro:
- "AsyncProDD240.bpl"
- "AsyncProDR240.bpl"
and so on...

But when I install the components from GetIt(Berlin) the results are:
AsyncPro:
- "AsyncProDD230.bpl"
- "AsyncProDR230.bpl"
VirtualTree:
- "VirtualTreesDD230.bpl"
- "VirtualTreesDR230.bpl"
and probably so on...
They are the same as these for "Delphi 10 Seattle". And probably not the same...

3. For Delphi Seattle look at this folder:
- "C:\Users\Public\Documents\Embarcadero\Studio\17.0\Bpl"
For example AsyncPro:
- "AsyncProDD230.bpl"
- "AsyncProDR230.bpl"

Am I right or not?

When I uninstall the components from GetIt(Berlin) and remove them manually from "...Studio\18.0\Bpl" - again no problems for the old project in Seattle.

And people... do not remove JVCL from GetIt in "Delphi 10 Seattle"!!!
Just don't do this!

Regards and if someone knows how - please help to boys in the Emb/Idera team.
GetIt + TurboPack is a great idea.
http://docwiki.embarcadero.com/RADStudio/Berlin/en/Compiler_Versions

Comments

  1. I encountered something similar: https://quality.embarcadero.com/browse/RSP-14243

    I think some packages in GetIt are flagged as Berlin-ready when they haven't been changed to have Berlin packages yet. I actually thought this had already been fixed, but I guess not.

    ReplyDelete
  2. It's about time that embarcadero adds an option to automatically add the correct suffix for the current Delphi version to a package. That shouldn't be too difficult and would easily solve such problems.

    ReplyDelete
  3. Can you explain why you say "Dont uninstall JVCL from GetIt" ?  Perhaps Marco Cantù could comment if there is a work around to GetIT working for Seattle and Berlin or if this is being worked on ?  Be nice to know the state of the various packages before installing, I say this as I haven't had a chance to install things yet.

    ReplyDelete
  4. Am I the only one who doesn't use GetIt?

    ReplyDelete
  5. Brett Wilton Well - this is just an advice which is not correct and valid for all cases. I use in the same PC Delphi/7/XE2/XE10/XE10.1 - the reason old projects and so on.

    The wizard of the installer of JVCL detect that I already have old versions (installed in the old Delphi) and want to update them and also to install the newest version for XE10. Ok but...

    For some of the old versions - the newest installer detect an usage of the BDE are with the BDE.
    But... for newest versions - we are without BDE in the Delphi(I use FireDac currently which is great).If you switch off the update of the oldest versions - the usage of the BDE is still required from installer of the JVCL. So - the mess is full. The compilation failed for Delphi 10 and...
    I resolve the situation manually but... it is not so fast. :)

    I think that the JVCL problem is not a problem of the GetIt manager. It was just advice.

    Also... unfortunately - for Delphi 10.1 JCL and JVCL are still not ready. I plan to remove Delphi 10 and migrate all my projects to 10.1 immediately after the release of the JVCL for Dephi 10.1

    ReplyDelete
  6. Krasimir Ivanov no you're not. I tried it and couldn't find any advantage for me. But that might have something to do with the fact that most of my programming is still done with Delphi 2007. Seeing that various libraries and components are still not available in GetIt for Delphi 10.1 and some of them apparently are broken, I think it will go the way of the dodo. In the next version, there will be even less usable entries and the one after that will have dropped it for good.
    Anybody care to bet when it will be gone? I bet 10 Euros on the version after the next, that would be Delphi 10.3 with the current versioning scheme.

    ReplyDelete
  7. Thomas Mueller :)))))))
    Well, I'm in the bet :) 10 euros are a good start for beer night here in Sofia.
    I believe that GetIt will still exist in 10.3 and will be more fast and useful than current version.
    It is a good idea for me.

    ReplyDelete
  8. Krasimir Ivanov No, I don't use it either. GetIt would have been perfect back in D7 days, but misses the mark by a long way as usable modern package manager. No real versioning, no dependencies, no easy way to submit packages (fill out a pdf?), no way to have alternate package sources (ie in house server or network share). Want to use different versions of a package with different projects.. nope, can't do. I have started on a better (imho) package manager but I'm struggling to find the time to work on it at the moment!

    ReplyDelete
  9. We are aware that using many GetIt packages in both 10 Seattle and 10.1 Berlin causes trouble, as the packages have the same name and both folders are on the path by default. We are in the process of updating the Berlin packages, but it is taking more time than expected, for an internal re-organization

    ReplyDelete
  10. thanks Marco Cantù for you comment, appreciated

    ReplyDelete

Post a Comment