Accessing a plugin from my code is producing this Ambiguous error.

So we have been using the Tower Defense Tool Kit and it has been going good. However we have reached a point where the developer is not willing to help us any further.

Basically he has an script file called Path.cs and in our level generator we are using System.IO for opening pixel maps. Well when we try to access the the GameObject with the Path.cs attached and access it's code we get the following error in the code.




We have yet to find a way to work around this and renaming his class name from Path to something else is a major deal as there are 100s of references in his code to that class.

We are assuming it is because both have the definition of Path and that we are going to have to rename all references in this plugin from Path to something else.

This is really frustrating any advice would be greatly appreciated.

https://i.ibb.co/4t5tZWY/image.png
https://i.ibb.co/wgnRRvk/Capture.png

 

I can't see the image but you can use using alias .
besides, all IDEs have a refactoring utility for renaming types, fields, methods, and variables.
it doesn't matter how many references you have, if you have access to all of it.

 

I added links to the images so you can see larger versions of them. I am reading the link you sent.
Ill look into refactoring in VS

 

Now the image is too small, but okay I can barely confirm that it's the error I expected to see.
"Ambiguous reference" because of System.IO.Path.

The normal way this is solved is by having own classes in separate namespaces, but I can imagine you're doing everything at the top level. If you were keeping your own classes in a separate namespace, you could use System.IO.Path where you need it by specifying

using FilePath = System.IO.Path;

in that file, but most likely you wouldn't even use them both at the same time, so the local references would be unambiguous.

In this case, I'd advise looking into name refactoring. It's two clicks at most and won't break anything.
For the love of god, if you're not using namespaces, pick a decent naming scheme that's not as short as Path.

Obviously the system will take over anything that is supergeneric and lightweight, this is why we need namespaces in the first place. It's not a superbad practice either, Unity wasn't exactly made for sending rockets into space, but you get this problem sooner than later.

 

I actually am using namespaces and the developer of the plugin is too but it was still causing the issue. Also for sure not on the top layer of things.
IDK Why it is happening, it is the first time in a long time I have come across this error and usually I refactor, but refactoring means not being able to update his plugin in the future when we does new releases. But I do not know for the love of god why someone would use the class Path knowing that it is a System.IO class name.

The alias worked as a work around and I know it is not the best thing to do because it over complicates code but unfortunately in this instance it works as a quick fix for a problem that has been plaguing us for days.

 

ok, then if that's the case, go with the using alias. it is the best thing to do as long as you're doing this exactly in that one place where you're actually using System.IO.Path

 

oh, and I forgot to mention one more thing. If the code is referring to System.IO.Path in just one or two places, you can chain reference it as well, i.e.

System.IO.Path path = someObject.SomeFunctionThatReturnsPath();

this is in fact, the best way to do it, if you rarely access the system Path name anyway.
'using alias' is more, like, a broad convenience for when you're intending to use ambiguous names extensively in the current file.