search

BHoM / Grasshopper_UI

Tools for Grasshopper
GNU Lesser General Public License v3.0
16 stars 5 forks source link

Referencing Grasshopper_UI in another project #654

Open alelom opened 2 years ago

alelom commented 2 years ago

Context

I am trying to reference some types defined in Grasshopper_UI. Although cases like mine are quite uncommon, I remembered that for BHoM_UI we do provide a Nuget package, which I found useful.

Related to this, I tried to reference the Grasshopper_UI compiled assembly from our C:\ProgramData\BHoM\Assemblies folder. However, unlike for other assemblies, our PostBuild events in Grasshopper_UI copy a "renamed version" of the assembly, changing its extension to .gha.

This makes referencing the Grasshopper_UI.dll from a central location impossible, am I mistaken?

Question/proposal

Could we consider packaging also Grasshopper_UI as a Nuget? In my case, it would be quite useful, although I'm conscious it is and will remain an edge case.

Alternatively, would storing two copies of the assembly (a .gha for Grasshopper, and a .dll for referencing) create problems?

al-fisher commented 2 years ago

I don't see a problem with packaging a Nuget here! Makes sense in principle. And in support of edge cases we can certainly look at facilitating additional deployment pipelines etc. beyond the set up for the standard desktop installer and plugins.

Did have the additional thought about whether there is also an option to look at moving the code/types you want and need to reference from within the Grasshopper_UI.proj - to the Engine or oM as dependencies mean the UI can still utilise - and such that they are not in the .gha ? This would actually be more work and so might not even make sense. Nuget or simply having alternate versions of the gha/dll would be easier

alelom commented 2 years ago

Thanks - making a Nuget does seem the way forward here. From my perspective (and I think in general) the interesting types are those classes that represent the Grasshopper components (which in turn represent BHoM types). Essentially, when analysing or deserialising a GH script, it is useful to have those types in order to distinguish them from other plugins components. Therefore I agree, the argument for a Nuget holds I think. Happy to work on it.