You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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
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.
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?The text was updated successfully, but these errors were encountered: