Ranorex Forum

Hello,

I created a custom DLL and I placed it into the C:\Windows\System32 folder using full administrative rights.

When I attempted to add the reference to my project (using References > Add Reference > .NET Assembly Browser > Browse...) it does not exist in the "Open" browser window, and if I manually type in the file name and click "Open", I get a file not found popup box.

The SharedMethods.dll is still viewable in regular Windows Explorer, as well as from Notepad > Open browser window, but just not Ranorex .NET assembly browser file browse window.

FYI - Ranorex IS able to find the .dll if it's in its project folder, just not System32.

Any idea what could be causing this? Thanks in advance!

You can't just copy a DLL into system32 and have it start working. You need to register it with Windows.

If this is just going to be for Ranorex tests, then putting it in the project folder and setting it to "Always Copy" to the output folder when you build is the best way to do this. Otherwise you will have to register this one DLL on every Windows system you will be using it on.

Thanks for the feedback, krstcs! I see what you mean. I was hoping to have one easy access folder where each test machine could reference the one file, that way if it were to be updated each machine would only have that one file to change out since all tests reference it. With the method you provided, is that still an option, or would it have to be changed out of every project that references that .dll in its own project folder?

If you included the DLL in every project, as I mentioned, then it would be deployed with each project, so yes, they would all be independent and you would need to update each one.

However, what I do is, I have one BIG solution that has all my related/dependent projects in it. That way when I update one, the re-build knows what it needs to do for each one.

My solution looks like this:

-MyBigSolutionToLifesProblems
--ProblemProjectCOMMON - DLL (I use a suite here for internal test module testing so mine is an EXE, but you can just have a test library for the DLL as well...)
--ProblemProject1 - EXE Suite
--ProblemProject2 - EXE Suite
---etc.

Once you use a module from COMMON in project 1 (for example), Ranorex will set the dependency and keep project 1 updated if you change COMMON.

It still doesn't change the fact that each project is built separately, but it is a bit easier to manage. You just need to deploy the built test from the output directory of the desired project and all dependencies are included.

The only other way I could think to do this would be to involve a true build system that would update your test systems when the DLL was built. However, that is a lot of work for something that is relatively small like a Ranorex test solution. If you already have a build management system and could integrate the tests into it, that might be a good way to go though.

Honestly, I haven't gotten all the way through the full process where I am now because we are just starting the automation framework and the continuous integration system is not fully realized yet. There may be changes later that help/hurt my line of reasoning...

That's actually a really good idea! Initially I had a similar setup where my project containing the DLL with shared methods existed as kind of a parent project with the other projects as dependents, that way any changes to the DLL project would automatically update the other projects as well. But since we have quite a few tests, the test suite got to be pretty cumbersome. Still, I think it's a good model to build from!