Component ID conflict

[Moonpick (Pierre)]

Hi,
I have the following scenario: 2 plugins with different file names (Plugin1.gha and Plugin2.gha let’s say, second one simply renamed in windows explorer) but same content (same components written in VisualStudio) with the 2 differences

1. the components have different GUIDs over the 2 plugins.
2. the plugins have different versions (GH_AssemblyInfo.Version)

I expected Grasshopper to be able to load both plugins, but it is not the case. I get the “Component ID conflict” message.
Looks like the component signature is not only made out of the GUID, am I right? I tried to change the components classe names and the namepaces in 1 plugin but, it I still get the error message. What do I miss?

Thanks.

[w.radaczynski]

What about plugin GUIDs? You can’t have 2 plugins with the same GUID, as far as I remember it will ask you which one you want to load in that case.

[Moonpick (Pierre)]

So I changed it too but still get the same message:

What is strange is that the names and types of the components shown in the warning are the same although I renamed the class and the component itself in the plugin where I changed the ids (component GUID & Plugin GUID). So in the conflicting component the Type and Name should actually be different… Looks like there is a mixing somehow.

[w.radaczynski]

I guess with this can help someone that has an access to the logic behind it, to help us understand how checks looks. Personally I’d believe that if plugin GUID is different and the component GUID is different, then it should load both.

[jbarry]

@Moonpick have you got to the bottom of this? I’m having a similar issue - I’ve done this before without issue to allow me run Debug and Release versions in parallel. But I’m recently getting the same conflict errors you are describing above. Changing the plug-in and component GUIDs and filename was sufficient previously, but not any longer.

[sonderskovmathias (Mathias Sønderskov Schaltz)]

From the screenshot it looks like you have a newId component in the oldId assembly .

[Yan2 (Yan)]

Hello all, sorry for reviving, but has anyone managed to solve this meanwhile?

I came across this when trying to load two versions of the same plugin, but with different guids.

The two GHAs differ in guids in every component and parameter, and also in the assembly, but I still get the same error. (See image below).

What exactly does GH use to tell if something is the same plugin? I also tried changing version string, assembly name, C# namespaces (so it generates different fully qualified type names), but it still conflicts.

When I change loading from ForceDirect to ForceCOFF, it loads without the error dialog, but then both loaded plugins actually point to the same GHA, or in the least the versions get reported incorrectly, so I am hesitant to say this actually fixes anything.

People tell me this used to work fine at some point. Is there a concrete version of Rhino/GH I can install? I don’t need to be on the newest.

[Brayton_Orchard]

I have the same issue, and it appears to me that there are now two possible locations for Grasshopper plugin files (but this is hard to see because the full file path is not displayed in error window):

1. …\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\eleFront"
2. …\AppData\Roaming\Grasshopper\Libraries\elefront512"

Is this because the YAK package manager is automatically downloading files to the first folder location, instead of the second? Which one should I be dropping plugins into if I’m manually downloading them?

Or is this a separate problem from what you guys are describing?

[gankeyu (Keyu Gan)]

your problem is different.

The cause of yours is you have two Elefront installations from (1) Yak (PackageManager) (2) manually installed in the File->Special Folders->Components folder. (the 2nd path)

[Brayton_Orchard]

Got it, thanks!

[sonderskovmathias (Mathias Sønderskov Schaltz)]

Hi Brayton,

We experienced that eleFront 5.1.3 on packagemanager is actually called 5.1.2 when you download it, AND it’s conflicting IDs with previous versions. I think the 5.1.3 is a mis-push to yak…

I recommend deleting 5.1.3 (that could be called 512 locally), downloading the real 5.1.2 AND then the legacy one for Rhino 6 if you need the old components (think it’s version 4.x.x)

[krahimzadeh (Keyan Rahimzadeh)]

Hi all, I am similarly trying to sort out what’s going on with Grasshopper’s ID conflicts.

As @gankeyu has said, you need to only have one installation, preferably the Yak / PackageManager version, as this will be easy to install.

@sonderskovmathias Version 5.1.3 is definitely a new version with some bug fixes, so I’m not sure where you are seeing that it’s called 5.1.2 when you download it. On my system, when I install from the package manger, I see:

That said, I have had reports of folks having issues with conflicting IDs, which seems to be similar to the main topic of this thread. It’s confusing because it’s only been an issue in 5.1.3, even though I didn’t change any of the GUIDs… In any case, if you set the COFF Array loading to “true”, it will load 5.1.3 just fine. I’m hoping to resolve it for future versions.

Of course if none of the old bugs are affecting your work, then no need to upgrade for now (they were mostly related to the Auto-Update features in Reference components).

[Brayton_Orchard]

Thanks @krahimzadeh and @sonderskovmathias for the explanations.

I tried the following, in order:

1. Deleted all versions of Elefront.
2. Downloaded 5.1.3 from Yak. Legacy components in my old scripts were missing.
3. Downloaded Elefront legacy version. Received the following error when I loaded GH:
   
   
4. Deleted 5.1.3 and downloaded 5.1.2 from Yak. Did not receive the component ID conflict error, and all my legacy components were visible in old scripts.

[sonderskovmathias (Mathias Sønderskov Schaltz)]

For the lazy ones in a .bat file:

• removes all elefront in yak
• installs elefront 5.1.2 + legacy 4.3.0 in yak
• removes all elefront from /libraries

@echo off
set Yak="C:\Program Files\Rhino 7\System\yak.exe"

echo e[31me[7mTrying to uninstalling elefront - will be reinstalled...e[0m
%Yak% uninstall Elefront 5.1.3
echo[
echo e[31me[7mReinstalling elefront 5.1.2e[0m
%Yak% install Elefront 5.1.2
echo[
echo e[31me[7mReinstalling elefront 4.3.0 (legacy)e[0m
%Yak% install eleFront-Rhino-6-Legacy 4.3.0
echo[
echo e[31me[7mTrying to delete old plugins /in libraries (you get in PM)...e[0m
dir /b /A-D-H %appdata%\Grasshopper\Libraries>allLibraries.txt
findstr /I gha allLibraries.txt>ghaLibraries.txt

for /f "usebackq delims=^" %%v in (`findstr /I elefront ghaLibraries.txt`) do (
echo[
echo e[31me[7mREMOVING %appdata%\Grasshopper\Libraries\%%v -e[0m
del %appdata%\Grasshopper\Libraries\%%v

)
del ghaLibraries.txt
del allLibraries.txt

echo e[31mDone!
timeout 10

[krahimzadeh (Keyan Rahimzadeh)]

I’ve pushed 5.1.5 to the server and I think/hope/pray it’s fixed the issue.

For others that are running into this issue, I found some insight in these threads:

Coff and Grasshoppper

I would like to ask what is Coff Settings GrasshopperDeveloperSettings. By default it is on. But the problem I have is that I cannot run native C++ wrapper on .NET environment. Only when I turn off Coff settings grasshopper components finds the .dll and it works. So my question is why Grasshopper does not find native dll when Coff are on?

Error: Could not load file or assembly

Grasshopper can load plugins in two ways, and the sequence of decisions that lead to either of these is very complicated, although the default is to load from disk. You can tell by looking at the plugin details once Grasshopper has started. Open up the About dialog, click on the little plus icon in the top left corner, double-click on your plugin icon and look at the loading details. Other question, is the pdf dll file unblocked in Windows?

[Edit: Should be v 5.1.5]