Ranorex Forum

I use TortoiseSVN integration with Ranorex Studio, and while most aspects work perfectly well, I've often noticed that certain files are marked as modified (the ranorex xml test files, like .rxrep and .rxrec) with the only change being the addition / subtraction of the UTF-8 BOM to the beginning of the file.

I'd like to commit either having or not having the UTF-8 BOM (EF BB BF or "" in ASCII), but it seems that different parts of Ranorex Studio either prefer to add or remove the BOM.

Are other version control users having this problem as well? It's hard to make clean commits when so many files are marked as "modified" simply for having the BOM added/removed)

I could reproduce that issue with recording files (*.rxrec) only. We will look into that issue and try to fix it for the next release.

Regards,
Alex
Ranorex Team

I saw that there was a mention of a fix for this in v3.0.5, so first off, thanks.

I do still encounter this problem with .rxrep files on occasion.

Here's my version control setup:
Using TortoiseSVN, whenever I add new .rx* files to the SVN repo, I only add the xml file itself and not the auto-generated .cs file. For a Recording with a UserCode partial class, I'll add this UserCode file but not the main, auto-generated .cs file.

Every so often, when I update my solution, certain .rxrep files change to either adding or removing the UTF-8 BOM. I haven't been able to notice a pattern.

Any ideas?

Hi,

We currently tried a tons of combinations, but we were not able to reproduce such an issue again. Would it be possible to post us a step by step description to reproduce the issue? We need such a description because as I said we are currently not able to reproduce it.

You said that you always notice that issue on updating your solution - is someone else on your team maybe using an older Ranorex version? Or do you read and save the files with other editors (not Ranorex Studio), too?

Regards,
Peter
Ranorex Team

Sorry, I know it's a tricky thing to consistently reproduce. I'll try to continue looking into what patterns I use to consistently create the error.

The other members of my team use the same Ranorex Studio version (v3.0.5), and I'd be able to notice if they were using a different version when committing to these files, because the Ranorex Studio version number is stored in the XML file, and the only thing changing in these .rx* files is the addition/substraction of the BOM.

I don't modify these files outside of Ranorex Studio, and would only open these files in another program (Notepad++) to see how they differed, because it's quite confusing to see TortoiseSVN diff show that 2 lines are different when all the text in both lines are identical. I've had this issue since I've been using Tortoise and Ranorex, but I didn't nail down that it was an issue with the BOM until recently.

Can you tell me which way Ranorex Studio should be storing these files? With or without the BOM? That way, I can at least make sure to commit the proper version of these files to the repo, and note when the incorrect version appears.

mrusso wrote:Can you tell me which way Ranorex Studio should be storing these files? With or without the BOM?

All Ranorex files (*.rx*) should be stored with the UTF8 BOM, both when generated by the standalone tools and by Ranorex Studio.

If you find a way to reproduce the problem, please, send us a step-by-step instruction and if necessary, the project to reproduce the issue with. Thank you!

Regards,
Alex
Ranorex Team

Code generated from the Spy and the Recorder is always preceded by , I'm in Ranorex 3.0.5 on Windows XP.
Might this be related to the encoding of the resultant .cs file?
This is really annoying cause I have to remove it manually each time I generate it
Any workaround?

Ok, I got it. It seems that this fails if you have the file open in VS, cause it keeps using the old encoding (I had ANSI).
The workaround is to close the file in Visual Studio, replace it with the generated file, and reopen it (it is not necessary to remove it from the project, just close the tab)

I encounter the problem as well.
Any better workaround for this issue?

Regards,
Jazz Huang

Hi,

We found an issue with the BOM which could be related to your problem, this should be fixed with the new Ranorex version (4.0).

Thanks,
Markus