I've got this solution that was one of the first couple of solutions I ever created all the way back in Ranorex 3 or 4. It's had several contributors of varying experience, but I've usually been involved in one way or another. We've got one project, we'll call it CommonMods, that we use to house most of the test modules. I'm not sure if the project was actually a Ranorex Test Suite Module Library project or if I just deleted the rxtst file so people couldn't use it as a test suite.

The idea is that we'd place all of these reusable modules there and stick the specialized modules with the projects themselves, but we wanted to maintain a single repository so all of the projects linked to the CommonMods repository. Fast forward to the long awaited addition of User Code Collections. I figured CommonMods would be an appropriate location for our User Code Collections and all was good. Up until I tried to use one of these User Code methods in one of the projects that had a link to the CommonMods repository. The error: SuchAndSuchMethod is not part of OtherProject.CommonMods. I was initially confused because SuchAndSuchMethod should be in the CommonMods.CommonMods namespace.

I took things apart and tracked the issue down to the combination of a linked repository and a User Code Collection sourced from the same project. I give all this history to illustrate the complexity of the solution as a whole. I have no idea if I started this out in Ranorex 7.2.1 if we'd be in the same place or not.

So here's my question(s).

Is there a way around what appears to be a limitation?

Is this something that could be "fixed", should I submit a user voice? suggestion?

The most obvious solution would be to just create a new project to hold the User Code Collect. Can I just copy/paste the methods or will that break all of my existing recorded modules that currently use those methods?

Last edited by Vaughan.Douglas on Mon Dec 11, 2017 3:44 pm, edited 1 time in total.

I've had an interesting development while trying to recreate the issue from scratch. First off I haven't been able to recreate it as such, but something else is happening. In the attached project I created a Module Library project and a Test Suite project. I created a module in the test suite and linked it to the repository in the Module Library. Then I added a user code collection to the module library and added a simple method that just reports some text. I added that user code method to the module that exists in the test suite. It ran without issue.

Possibly important to note that even after building the solution, I still had to manually add the reference for the module library project to the test suite project for it to show up as a user code method I could select. I don't recall 100% accurately if I added an object to the repository before or after I manually added the reference. When I did add the object it was just "add new item" in the repo window below the module.

I add a second step to the module which waits for that generic object to exist. No problems. I'm starting to get frustrated so I'm trying different things, trying to keep it at one change at a time and giving it a run. This is important because I don't recall the steps in the specific order because I was looking for a build issue, so I don't know when this second issue actually presented.

The things I tried:

Adding a module (with no steps) from The Module Library to the test suite

Change the method from a sub to a function and bind the return to a logging step

Actually adding sstep to the module from the module library

Probably something else too, but you know how it is.

At some point in this mess I decide that maybe I need to do something other than "/element" as my element path, To do this, I had the test suite module open which you'll remember is linked to the module library repository, I clicked the little edit button on the item column and used the tracking to grab the windows start button. I took out those annoying /?/?/ and applied. Then continued with the above. Relatively soon I was in the module from the shared library and noticed that the App folder path still said "/element" and not "/menubar[@class='Shell_TrayWnd']//button[@accessiblename='Start']".

So the first thing someone is going to want to know is if I'm sure I linked the repository and didn't copy it. The answer to that is unequivocally yes, that was the whole point of what I was trying to do. AND the fact that I only had to add the element once.

One last thing. During one of the executions it choked at the end. I didn't think anything of it since the problem I was looking for failed the build. I had to kill the execution.

Since I did such a terrible job remembering my steps in the last go, I figured I'd try to recreate the second issue, but managed to recreate the first issue. I suspect the issue has to do with the order that the repository is linked to the project versus the reference.

I did NOT check if there was a reference to SharedModuleLibrary in TestSuiteA prior to adding it. I expected it at the top of the list, but it appeared near the bottom.
But here is the blow by blow steps to recreate written as I performed them.

Thanks to your detailed steps, I have duplicated this issue locally. This is unique to solutions using VB as I cannot duplicate the issue in a C# solution. The issue appears to be due to the code generator adding an additional project reference after linking the repository.

I have sent this issue to our developers to be further investigated. Currently, we do not know if and when this issue will be fixed. This depends on various factors. Nevertheless, all new features, updates, and bug fixes are documented in the release notes with every new version release of Ranorex.

Thank you for your response. Unfortunately this entire test suite has been built using a shared object repository, so your fix would cause more problems than it would fix. However converting the one project (TestSuiteA) to c# it does fix the issue. My users are more comfortable with VB.Net, so I'll have to pass it by them. The converter does not convert many of the custom user code modules and methods well. This whole solution could use a good cleaning out.

I suspect the easiest course of action at this point would be to just move the user code collection out of the project containing a shared repository and into it's own module library.