Exclude DLL From Global Assembly. (NCalc DLL Conflicts with Alias in Visual Scripting Package)

Unity Engine
, ,
1

This is potentially a remote issue.

The visual scripting package uses Ncalc.

In Formula.cs (com.unity.visualscripting@1.9.4/Runtime/VisualScripting.Flow/Framework/Formula.cs) Ncalc is aliased for just the expression object.

This aliasing is problematic if you are using NCalc in your project itself. I have an Ncalc dll in the project proper (obtained via NuGet). This causes the Ncalc namespace to conflict inside the visual scripting project:

Library\PackageCache\com.unity.visualscripting@1.9.4\Runtime\VisualScripting.Flow\Framework\Formula.cs(16,17): error CS0576: Namespace '<global namespace>' contains a definition conflicting with alias 'NCalc'

I’ve tried to see if I can use the NCalc dll in my project through an asmdef or something and I can’t quite resolve the error.

Alternatively maybe I could somehow exclude this dll from the global assembly so the package doesn’t conflict with it.

I can possibly replace the dll for Ncalc with the source of Ncalc itself and put all that under an asmdef.

The other route to take is to embed the visual scripting package locally and just remove the alias in the script listed above. But this would make getting updates to the package problematic. I’d like to avoid this if possible.

It would be great if this could be solved via configuration and keeping the Ncalc dll in the project itself.

Or, alternatively, I’d suggest simply removing the Alias from the Visual Scripting package altogether and just use the Expression type on line 16 of Formula.cs. I’m not sure what aliasing that Ncalc does–frankly it makes the script harder to understand from my POV.

Cannot use NCalc due to Namespace conflicts caused by VisualScripting
2

You can exclude a precompiled assembly (DLL) from default assemblies (Assembly-CSharp etc.) and assembly definition assemblies like the Visual Scripting assemblies by disabling Auto Reference in the Inspector settings for the DLL. Then, default assemblies will no longer be able to reference those DLLs, and assembly definition assemblies will require explicitly adding the DLL to the “Assembly References” section of their Inspector.

You should disable Auto Reference for assemblies that create such aliasing issues in Unity or third-party packages, and reference the assemblies manually when you use them.

What is “the global assembly?” Are you referring to Assembly-CSharp, Assembly-CSharp-Editor, etc.?

3

Ah! Auto reference checkbox was not something I was familiar with. Thank you, that does solve the problem.

By global assembly I was just mistyping “global namespace” from the error itself getting it mixed in my head.

I do think it would still be best for unity to remove this alias from the package itself (no reason to introduce this potential issue at all) but this certainly solve sthe problem. Thank you!