ZT library - namespace support needed

I’m starting to dive into the world of Zero Touch nodes with C# and Visual Studio. I’m trying to create a very basic node that gets the length of a curve and multiplies it by two (pointless, I know). When trying to load the .dll in Dynamo, I get an error saying:

Can’t import Autodesk.DesignScript.Geometry.Curve, Curve is already imported as Autodesk.DesignScript.Geometry.Curve, namespace support needed.

Here is my code:

using Autodesk.DesignScript.Geometry;

namespace CurveTest
{
    public class CurveTest
    {
        public static double DoubleLength(Curve curve)
        {
            return curve.Length * 2.0;
        }
    }
}

I’m using Dynamo Sandbox 2.7 and .NET Framework 4.8. Any ideas?

Hi @mzjensen

Looks good to me:

Did you imported ‘ProtoGeoemtry.dll’ Assembly? Did you get any errors when you build?

@Kulkul by ‘import’ do you mean add the reference in Visual Studio? If so, then yes. And I did not get any errors when building. The error I get comes from Dynamo’s notification manager, and the nodes never show up in the left sidebar.

Mmm… Interesting.
I tested in DynamoSandbox 2.8 and it works fine for me:

Are you using the latest Nugets Package? If not then make sure you do.

https://www.nuget.org/packages/DynamoVisualProgramming.Core/2.7.0.9206

And also this will guide you step by step if your new to this:

1 Like

Yes, I have the latest packages.

Here is exactly what I am seeing on build:

Thanks for the link! I am new and have been using this guide:

OK, I didn’t realize that I needed to have an installation of Revit, FormIt, or Civil 3D in order to use geometry within Sandbox.


So I installed FormIt, but I’m still getting errors with geometry nodes in Sandbox.

Error

All good @mzjensen?

ok don’t worry. I will be on my pc soon. Meanwhile, Can you locate LibG.ProtoInterface.dll on your C drive and paste in your desktop folder where it says it’s missing.

These folders are in the DynamoCoreRuntime2.7.0 folder on my Desktop and they all contain a LibG.ProtoInterface.dll. Should I be looking somewhere else?

Figured it out - just needed to change the references in Visual Studio so that “Copy Local” was set to false. Thanks @Kulkul!

3 Likes

@mzjensen The issue was not just “Copy Local”, You where also missing Build Events:

xcopy /Y "$(TargetDir)*.*" "$(AppData)\Dynamo\Dynamo Core\2.7\packages\$(ProjectName)\bin\"
xcopy /Y "$(ProjectDir)pkg.json" "$(AppData)\Dynamo\Dynamo Core\2.7\packages\$(ProjectName)"
1 Like

Yes, copying the package files is necessary for debugging. I had accomplished this in a different way by editing the .cs file with this at the end.

<Target Name="AfterBuild">
    <!--Copy the package to the Dynamo package root directory-->
    <GetReferenceAssemblyPaths TargetFrameworkMoniker=".NETFramework, Version=v2.0">
      <Output TaskParameter="FullFrameworkReferenceAssemblyPaths" PropertyName="FrameworkAssembliesPath" />
    </GetReferenceAssemblyPaths>
    <GetAssemblyIdentity AssemblyFiles="$(OutDir)$(TargetName).dll">
      <Output TaskParameter="Assemblies" ItemName="AssemblyInfo" />
    </GetAssemblyIdentity>
    <ItemGroup>
      <SourceDlls Include="$(TargetDir)*.dll" />
      <SourcePdbs Include="$(TargetDir)*.pdb" />
      <SourcePdbs Include="$(TargetDir)*.pdb" />
      <SourceXmls Include="$(TargetDir)*.xml" />
      <SourcePkg Include="pkg.json" />
    </ItemGroup>
    <RemoveDir Directories="$(AppData)\Dynamo\Dynamo Core\2.7\packages\$(ProjectName)\bin" />
    <Copy SourceFiles="@(SourceDlls)" DestinationFolder="$(AppData)\Dynamo\Dynamo Core\2.7\packages\$(ProjectName)\bin\%(RecursiveDir)" />
    <Copy SourceFiles="@(SourcePkg)" DestinationFolder="$(AppData)\Dynamo\Dynamo Core\2.7\packages\$(ProjectName)\" />
    <Copy SourceFiles="@(SourcePdbs)" DestinationFolder="$(AppData)\Dynamo\Dynamo Core\2.7\packages\$(ProjectName)\bin\" />
    <Copy SourceFiles="@(SourceXmls)" DestinationFolder="$(AppData)\Dynamo\Dynamo Core\2.7\packages\$(ProjectName)\bin\" />
</Target>

But if you don’t do it this way, then you do need to add the Build Events in the project properties like you mentioned. In my case, having both was redundant.

2 Likes