IO Generated Errors - which component?

Fellow GH users,

I created a custom DLL in Visual Studio that I use to store a lot of scripted VB.Net component. Problem is that I keep on adding stuffs and modifying components inside, to face new needs. When I tried to open an old definition, logically IO generated a lot of errors due to these outdated components.

My question is : is there a way to know which component is throwing an error? I don't remember all changes I have made on the past weeks. IO report only says : Archive is corrupt.

And generally speaking, what is the best way to deal with custom components compatibility? Is there a way to link a GH definition to a specific build of a DLL?

Any feedback or experience would be appreciated,

Thanks!

Replies to This Discussion

Permalink Reply by Andrew Heumann on August 15, 2016 at 5:23am

you will run into trouble if you open a GH file with components from an older version of a GHA if the inputs/outputs on the components have changed since that version. Errors in stored data serialized/deserialized in Read() and Write() may also cause problems. You may be able to better discern which component is throwing the error by debugging from visual studio.

The best practice when making breaking changes like these to a component is:

Take your component class and duplicate it completely.
In the new class, assign a NEW GUID. this is very important!!!!
in the old class, rename it to something like "MyComponentClass_Deprecated" or something like that to let you know it's old
Override its "Obsolete" property to "true" so the "old" sticker will show up on the component
Override its Exposure to GH_Exposure.Hidden so it won't show up in the toolbar anymore
Make any necessary changes to your new class and recompile.
OPTIONALLY: Create a public "MyComponent_Upgrader" class that implements the IGH_UpgradeObject interface, so that when you go to the Solution menu: Upgrade Components it will be able to automatically upgrade all the old versions of your components to the newest ones.

The benefit of this is that code that relies on old versions of your component will still function as it did before your changes, but any time you place the component in the future it will be using the latest-and-greatest code.

Permalink Reply by Xavier AM on August 16, 2016 at 3:01am

Thanks Andrew,

I should have thought that using VS will give me the outdated component! Anyway, the way you describe sounds quite useful, I will start using ourdated components and an Upgrader from now. Btw, changing the class name from XXX to XXX_Deprecated doesn't create a problem for old scripts as long as you keep the GUID, inputs and outputs, is that correct?

Cheers!

Permalink Reply by Xavier AM on August 16, 2016 at 3:04am

Hello Tom,

I think that's definately a best practice to code the way you describe. Since I am not a programmer, I am slowly figuring out that not doing it is a pain whenever you wanna change a piece of code :-) Will do it from now, Thanks for the advice!

RSS