Welcome, Guest
Username: Password: Remember me
Visual Objects

Please use this forum to post questions about Visual Objects and Vulcan.NET
  • Page:
  • 1

TOPIC:

VO versions 22 Sep 2022 21:56 #23981

  • NickFriend
  • NickFriend's Avatar
  • Topic Author


  • Posts: 246
  • HI all,

    A quick question about VO versions. I have 2.8 SP2a (2831). I need to copy a repository to someone with 2.8 SP4b (2838).

    If we try simply copying, we're getting a Version mismatch error 40256 - is that just because it's marked as 2831 in the voprj file, or are the repositories actually different between these versions? I know we can export to AEFs and import, but I want to avoid that.

    If it's just the voprj file I imagine I can simply edit it, otherwise we'll have to make sure we're on the same version.

    Thanks

    Nick

    Please Log in or Create an account to join the conversation.

    VO versions 23 Sep 2022 05:29 #23986

    • wriedmann
    • wriedmann's Avatar


  • Posts: 3366
  • Hi Nick,
    it is never a good idea to copy repositories even if you are on the same version.
    The easiest possibility would be to have all handwritten code in external prg files and copy only them.
    This is what I'm doing on my main libraries. But this does not works on modules with binary entities.
    They have to be exported/imported.
    Otherwise you have to export and import AEFs (Paul Pikos VO Productivity Pack does a great job with this).
    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    VO versions 23 Sep 2022 07:22 #23987

    • robert
    • robert's Avatar


  • Posts: 3599
  • Nick,
    What Wolfgang said.

    Robert
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    VO versions 23 Sep 2022 10:19 #23994

    • NickFriend
    • NickFriend's Avatar
    • Topic Author


  • Posts: 246
  • Some context may be useful.

    I do all the programming (remotely), but the head office needs a failsafe so that if I get run over by a bus they have the source code and can continue to compile it as needed. So we're not sharing programming, just getting an easily useable copy of the code to a safe place. I have a backup system which takes regular copies of the repository directory and copies it to a shared OneDrive folder.

    I only need to use VO infrequently, and import/export of a whole bunch of AEFs is not very user friendly or efficient (we don't have VOPP). Given that the repository is just a bunch of files, I don't see why copying it should be any less reliable than exporting each module and copying those files??... and the process I have is completely automated and with multiple backups available (in case one fails for some reason).

    Given this... back to the original question ;-)

    Nick

    Please Log in or Create an account to join the conversation.

    VO versions 23 Sep 2022 10:33 #23995

    • wriedmann
    • wriedmann's Avatar


  • Posts: 3366
  • Hi Nick,
    then you should invest in a copy of VOPP and copy the resulting AEFs regularly to GitHub as I do.
    Copying the repository is unreliable because it is not sure that you will be able to reconstruct the code on another machine with a different directory and/or VO version.
    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    VO versions 23 Sep 2022 10:52 #23996

    • NickFriend
    • NickFriend's Avatar
    • Topic Author


  • Posts: 246
  • Copying the repository is unreliable because it is not sure that you will be able to reconstruct the code on another machine with a different directory

    Really?... why not? If the other install is exactly the same version (this was the root of the original question), and you open a project by navigating to its folder and selecting the voprj file, why should they not be able to reliably access my code? Ignore issues like location of icon files, etc... just focusing on the source code.

    Nick

    Please Log in or Create an account to join the conversation.

    VO versions 23 Sep 2022 11:51 #23999

    • ic2
    • ic2's Avatar


  • Posts: 1667
  • Hello Nick,

    Kees copies my full zipped repo directory from time to time, checks if all his changes he sent have been included by me and it has always worked 100%.

    But it could be a good idea to also export the AEF's; it is easy to import AEF's in an empty repo (as the later VO's first create empty entries if absent and then overwrite when the actual AEF is imported) but building the project is many times faster, as it is automated, in VOPP.

    Dick

    Please Log in or Create an account to join the conversation.

    VO versions 23 Sep 2022 16:37 #24009

    • robert
    • robert's Avatar


  • Posts: 3599
  • Nick,

    Some context may be useful.

    I do all the programming (remotely), but the head office needs a failsafe so that if I get run over by a bus they have the source code and can continue to compile it as needed. So we're not sharing programming, just getting an easily useable copy of the code to a safe place. I have a backup system which takes regular copies of the repository directory and copies it to a shared OneDrive folder.

    I only need to use VO infrequently, and import/export of a whole bunch of AEFs is not very user friendly or efficient (we don't have VOPP). Given that the repository is just a bunch of files, I don't see why copying it should be any less reliable than exporting each module and copying those files??... and the process I have is completely automated and with multiple backups available (in case one fails for some reason).
    Given this... back to the original question ;-)

    Copying the repo is safe, as long as you make sure that external files (bmp, ico etc) are also copied.
    However you will have to consume the repo with the same version in which it was created.
    2.8 SP2 and 2.8 SP4 are binary incompatible
    I would have given these versions a complete new version number, but in the contract between Brian and CA is was stated stated that if Brian created a new version number (2.9) then he had to send more money to Computer Associates. And of course he did not want to do that.

    Robert
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    VO versions 23 Sep 2022 20:58 #24013

    • Jamal
    • Jamal's Avatar


  • Posts: 309
  • Nick,

    Since VO28 has no Windows registry keys to worry about, so may be copying the C:\CAVO28 folder to a different folder,example: C:\CAV28-2831, would do the trick.

    So, basically you will have the different versions side by side. Hope this works for you!

    Jamal

    Please Log in or Create an account to join the conversation.

    Last edit: by Jamal.

    VO versions 24 Sep 2022 00:33 #24014

    • NickFriend
    • NickFriend's Avatar
    • Topic Author


  • Posts: 246
  • Thanks for the info Robert, that's more or less what I suspected.

    Nick

    Please Log in or Create an account to join the conversation.

    VO versions 24 Sep 2022 00:35 #24015

    • NickFriend
    • NickFriend's Avatar
    • Topic Author


  • Posts: 246
  • Good idea Jamal, but probably we'll just keep it simple and make sure we both have the same version. It's really only in maintenance mode now, everything is focussed on a new .Net app.

    Nick

    Please Log in or Create an account to join the conversation.

    • Page:
    • 1