Adding support for method upgrade

[adecler]

NOTE: Depends on

• While it doesn't depend on it, it is good to have Reflection_Engine: Add possibility to include full path for parameters in method.ToText() BHoM_Engine#1335 on as it will make it easier for you to add new method conversions in the ToNewMethod dictionary.
  That engine PR is already merged. Thanks Fraser.
• Kind of depends on Aligning with changes in BHoMAdapter Refactoring Level 04 BHoM_UI#167 but only for testing purposes.

Issues addressed by this PR

Closes #7

Test files

https://burohappold.sharepoint.com/:u:/r/sites/BHoM/02_Current/12_Scripts/01_Test%20Scripts/Versioning_Toolkit/Issue7_MethodUpgradeTest_ForAdapters.gh?csf=1&e=Su4xfT

You will need the following PRs to test this file correctly:

• Adapter refactoring Level 04 BHoM_Adapter#164
• Aligning with changes in BHoMAdapter Refactoring Level 04 BHoM_UI#167
• Aligning with changes in BHoMAdapter Refactoring Level 04 Grasshopper_UI#440
• Aligning with changes in BHoMAdapter Refactoring Level 04 Socket_Toolkit#57

Additional comments

• This has been done within the context of the interface change for the adapters. So the test files focuses on that.
• Methods are a bit more tricky than objects because it is not about recovering the content the best we can this time. It is about finding a method that does the same thing even if the inputs/outputs are different. This is why I haven't changed the method deserialiser in the serialise engine to automatically return the new version of the method. This time I want it to keep failing so the UI get a chance to use the rest of its information (i.e. old input/output parameters) to upgrade the component correctly (i.e. reorganise the inputs).
• Notice that we now have full support for upgrading objects, methods, and namespaces/types. The last two are in a single file (something that we might want to change ?) while the first one is in a folder. I have therefore modified the folder name to Object Converter to clarify the relation with the other two files. Happy for ideas on how better organise the whole thing. Keep in mind though that most of this content (at least types and methods) should be filled automatically through refactoring via the VisualStudio_Toolkit in the medium term.
• I have left the upgrade methods for the adapter in the PR for testing purposes. Those will have to be commented out if merged before the PRs for the level 4 changes on the adapter (more specifically the UI PR)

[adecler]

@pawelbaran , I have added you as a reviewer so you can already give your feedback in preparation of BHoM/Revit_Toolkit#450

[FraserGreenroyd]

@alelom I feel you should take a look at this PR if you can as it is focusing on adapter versioning.

I intend to try and look at it today, but I am cautious of the fact I have reviewed the past couple of versioning PRs and would be good to spread the knowledge to others as well, so @IsakNaslundBh or @epignatelli it would be good if you can take a look today as well? 😄

[epignatelli]

This depends on a draft pr for testing - is this actually to review?

[alelom]

It seems some files are missing and that's blocking compilation for me:

[adecler]

@alelom , sorry about that, it seems that the project file was not pushed properly last time. Now fixed

@epignatelli , yes it is. But we will have to remove the content of the ToNewMethod dictionary (and the dependency of course) before merging (See my last additional comment). I will add the do-not-merge label to reinforce that.

[alelom]

Thanks for that @adecler. I can now compile successfully.

I now aligned both this PR and BHoM/Socket_Toolkit#57 to the latest changes in BHoM/BHoM_Adapter#164.

However, on opening of GH, I get this:

and on the opening of the test script:

Something about my latest changes must've broken it somehow.
The latest changes I've made are rather small, if compared to the refactor I had done up to the point you wrote this -- I can't figure out where the issue is arising.

I'd appreciate if we could have a look at this together. I'm also happy to have a Skype if you think it's quicker.

[adecler]

@alelom , yes, let's try to have a chat when you get to the office (assuming you don't get there too late 😋 )

[alelom]

The errors at #8 (comment) were caused by an issue in the Engine, now corrected by BHoM/BHoM_Engine#1377

[alelom]

This is really quite amazing. I could open several old scripts of mine without having to replace a single Push or Pull.

Here's the result of some testing.

Tests of scripts written in Rhino 5

The script linked by @adecler works fine.

Most of the other scripts (written in Rhino 5) that I tried upgraded the Adapter components correctly. Here is an example of one of them where it worked.

However, for one of them I get an error:

In this same script I get a very weird-looking Pull component 😝

Tests of scripts written in Rhino 6

I could not replicate the desired behaviour for scripts written in Rhino6 / GH version >1.

This is an example of a GH script written in Rhino 6 where this fails.

I always get the following error opening the RH6 scripts:

And Adapter components do not deserialise correctly:

Additional note

I only tested and linked scripts written using the exact same version of BHoM for both Rhino 5 and 6 scripts.
I personally produced those scripts last week by installing the beta release available on the website.

[adecler]

Thanks @alelom , it was actually a bug on the Grasshopper side. If you re-sync and recompile that part, it should now work fine for the pull.

[IsakNaslundBh]

General comment/question here: Should the method upgrades introduced in this PR be moved to a new BHoMUpgrader31 project before merging?

[alelom]

Now very happy with this PR! I've re-tested using the files already linked here: #8 (review)
and this works marvellously for all Adapter components.
Thanks!