6.1.0 Naming a module "Delay" interferes with Ranorex.Delay

Bug reports.
jbeeson
Posts: 14
Joined: Wed May 18, 2016 1:40 am

6.1.0 Naming a module "Delay" interferes with Ranorex.Delay

Post by jbeeson » Fri Sep 16, 2016 4:36 pm

Ranorex should stop you from naming modules that interfere with a class. Naming a module "Delay" causes build errors from all the Delay class items being used.

krstcs
Ranorex Guru
Posts: 2683
Joined: Tue Feb 07, 2012 4:14 pm
Location: Austin, Texas, USA

Re: 6.1.0 Naming a module "Delay" interferes with Ranorex.Delay

Post by krstcs » Fri Sep 16, 2016 6:18 pm

Without more information about exactly what you were doing, perhaps a copy of the project, it will be hard to know if this is really a Ranorex issue. However, at this point, from what you have said, I would have to say that it is probably user error due to misunderstanding object oriented coding standards and how the .NET build process works.

Generally it is considered bad practice to name any class (Recording and User-Code modules) the same as any other class from any library (Ranorex) you are using because of this.

Ranorex Recording and User-Code modules are classes, so if you name your module the same as a built-in class you get compiler errors because MSBuild doesn't know which one to use.

From what you say, Ranorex responded as intended by throwing the build error (which is actually MSBuild throwing the error because it found an ambiguous reference).

Build errors are specifically intended to let you know when you have created problematic issues like this by not following the expected coding convention. There is no need for Ranorex to take action when MSBuild will already tell you about the issue.

Note that if you did the same thing in Visual Studio or SharpDevelop (upon which Ranorex is built) you would likely get the same build error, so this isn't strictly an issue with Ranorex.

And, there's only so much that the tool can do to keep a developer out of trouble. There is a certain level of knowledge and understanding expected of the developer, and if the developer does something that they should not, the tool can't necessarily stop them, but it can tell them it won't work when they try to compile.
Shortcuts usually aren't...