Weird error when doing GetCustomAttribute() in Unity

The background is that we are using another plugin and kept getting a TypeLoadException with that plugin and spent a lot of time trying to debug it as the error emanates from there. However, I have dived into what it was doing and have managed to repro it with a clean project only with speckle.

Here is the code to add:

Assembly[] assemblies = AppDomain.CurrentDomain.GetAssemblies();
foreach (Assembly assembly in assemblies)
{
    Debug.Log(assembly.FullName);
    if (assembly.GetCustomAttribute<AssemblyCompanyAttribute>() == null)
    {
        continue;
    }
}

In the scene to play, a GameObject with a SpeckleProperties component is what is needed to trigger the error with the code above.

The output is as follows:

As you can see, it seems to search for Objects.Converter.Revit2025 and tries GetCustomAttribute(), fails and throws an error.

The full error here :

TypeLoadException: Could not resolve type with token 01000010 from typeref (expected class 'System.Runtime.Versioning.TargetPlatformAttribute' in assembly 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a')
System.MonoCustomAttrs.GetCustomAttributesBase (System.Reflection.ICustomAttributeProvider obj, System.Type attributeType, System.Boolean inheritedOnly) (at <356d430fdcb04bbf8dc54776e1d3627f>:0)
System.MonoCustomAttrs.GetCustomAttributes (System.Reflection.ICustomAttributeProvider obj, System.Type attributeType, System.Boolean inherit) (at <356d430fdcb04bbf8dc54776e1d3627f>:0)
System.Reflection.RuntimeAssembly.GetCustomAttributes (System.Type attributeType, System.Boolean inherit) (at <356d430fdcb04bbf8dc54776e1d3627f>:0)
System.Attribute.GetCustomAttributes (System.Reflection.Assembly element, System.Type attributeType, System.Boolean inherit) (at <356d430fdcb04bbf8dc54776e1d3627f>:0)
System.Attribute.GetCustomAttribute (System.Reflection.Assembly element, System.Type attributeType, System.Boolean inherit) (at <356d430fdcb04bbf8dc54776e1d3627f>:0)
System.Attribute.GetCustomAttribute (System.Reflection.Assembly element, System.Type attributeType) (at <356d430fdcb04bbf8dc54776e1d3627f>:0)
System.Reflection.CustomAttributeExtensions.GetCustomAttribute (System.Reflection.Assembly element, System.Type attributeType) (at <356d430fdcb04bbf8dc54776e1d3627f>:0)
System.Reflection.CustomAttributeExtensions.GetCustomAttribute[T] (System.Reflection.Assembly element) (at <356d430fdcb04bbf8dc54776e1d3627f>:0)
Test.Start () (at Assets/Test.cs:14)

However, the odd thing is that it doesn’t occur on all pcs. This will still occur in executable builds, and executable builds will have the same failure for the same PCs but work on the rest. I have been trying to figure this out for quite a bit and have finally narrowed it down to this for now. The usual advice for deleting the obj/library folder doesn’t work, and using different projects, or as detailed above, even a clean project with minimal code will reproduce this error, and will consistently occur on the same PCs, executable builds or otherwise.

My current theory is that it is occuring on PCs that have Revit installed where Revit 2020 does not exist. We do not have that many pcs/license combinations and currently its not feasible to test it out for now.

Any ideas on what to do to solve this problem?

With the speckle-sharp v2 SDK, it will search for converter “kits” (.NET dlls) in %appdata%\Speckle\Kits folder.

It seems this behaviour is causing this other plugin an issue because its scanning all loaded assemblies for that AssemblyCompanyAttribute


While the v2 code is setup to load kits, For the Unity connector, this is not required functionality, since all the required converter dlls are already directly loaded by the Speckle Unity Packages.

I would suggest you try overiding the path the SDK looks for these kits.
If you call this SpecklePathProvider.OverrideKitsFolderName function before trying to use anything speckle related (e.g. put in an Awake callback)
I’d suggest setting this path to some empty folder in your project, or in temp folder, since we don’t actually want it to find any dll files, but we do want to give it a valid path to try.

1 Like

Hi Jedd,

Thanks for the quick reply!
This seems to be working in our tests so far. Thanks !