Hi, thanks for posting!
When NCrunch works with files that are open in Visual Studio, it extracts their content from the IDE in unicode and transfer them to the workspace, writing them back in unicode with the byte order marks. Where the file uses a different encoding, NCrunch will detect the encoding and use it when writing the file back with the IDE content.
However, I can see how this could cause problems if you were storing content in a resource file that has a specific encoding but does not make use of byte order marks to declare this encoding. It's theoretically possible for such a file to be written to the workspace in a different state to how it was supplied in your original solution.
Although the behaviour is technically in error, there isn't really anything that can be done in the side of NCrunch to fix this. NCrunch has no firm knowledge of how the file is encoded, so when it goes to reproduce the file using data supplied only from the IDE, it can only guess how the file should be structured on disk.
As you're working with the file in binary, I think this raises the key question of whether you consider the file to be a binary file or a text file.
If the file is considered binary, then it shouldn't be opened in the IDE while using NCrunch as the text editor will cause the data stored in the file to be sourced by the text extracted from the IDE. I would perhaps suggest using a file extension that identifies a binary file, so that it is clear that the file is being interpreted by code that expects a strict binary form.
If the file is considered text, I suggest making an allowance for the byte order marks in your code. You may be able to use a different method of converting from binary to string that takes the order marks into consideration. This will then also make your code more resilient to sudden changes in the resource file caused by text editors that may presume to add these marks where your code otherwise wouldn't expect them.
I hope this makes sense!
Cheers,
Remco
