What I did was removed the absolute path from the variable you mentioned. I then modified the method that loads the assembly (I forget the name of the auto generated method but it has Load in the name and I think it's the only method that references the assemblypath variable).

I store the install location of the assembly in the registry so that's where I get the path information:

gnv_app.of_GetInstallDirectory() + is_assemblypath

If I ever have to regenerate the nvo, I have to make these changes again.

I do think a valid point is being made here:

Appeon could incorporate some options in the DLL importer tool:

1) give us the option to generate an ancestor class or not

2) that ancestor class would hold all the basic instance variables, basic functions and events.

3) the imported user functions would go to an object inherited from this ancestor class, as also would the assembly name assigned somewhere in the child object.

4) the ancestor class would then call a function to get the ancestor class name from the child object

This would give us the possibility to write generic functionality in the ancestor class.

When re-importing a library, we would use our already existing and adopted version of the ancestor class and delete the newly generated ancestor class. (it would be nice if the tool would ask us to overwrite the already existing ancestor in case we are importing things in to the same library where the modified ancestor was saved before).

Or even better, give as 2 checkboxes:

- use an ancestor class (yes or no)

- generate the ancestor class (yes or no): this would "use" an ancestor class, but not necessarily generate a new one, since we indicate with this checkbox that we already have one. 

I'll make a feature request of this, pointing to this Q&A

regards.