Hi,

I'm getting a strange error using NCrunch 1.48's 'Additional files to include' configuration option. It seems that a text file is not being simply copied, but rather, somehow a Unicode BOM is being injected into the file as part of the copy. Is that feasible?

I've uploaded an example of a broken test project here; https://github.com/steve.../ncrunch-build-problem. It requires Java to run.

The odd thing here is that the tests work find in Visual Studio with the built-in testing window and the NUnit test runner, so it seems to only occur with NCrunch. And it seems somewhat intermittent, in that sometimes it builds in NCrunch, and sometimes it doesn't.

Here's the deal. I have a file, included in .csproj file like this;



This is an ANTLR grammar; ANTLR is a Java-based parser generator, so as part of the build, it kicks off a Java process which generates some C# from the '.g4' grammar file. However, by default, the '.g4' grammar file doesn't seem to get copied into NCunch's workspace automatically; I get this kind of build error;


So I add it as a file in 'Additional files to include'. At this point, the tool finds the file but fails with an error indicating that the *copied* version of the file now has a Byte-order mark on it -- the ANTLR tool now throws out this error;



which seems to indicate that the copied file now contains the UTF-8 BOM. The Java standard libraries are pretty ropey when dealing with BOMs, so it seems that this is what is happening here.

My reading is that NCrunch seems to be doing something other than a straight file copy with the files listed in 'Additional files to include'. Is that true?

Remco, thanks -- I'd never have thought about it being the document in the IDE being the problem, but that makes a lot of sense when I think about it.

A very preliminary test shows that closing the file and rebuilding the component seems to work correctly, so I think you've probably cracked it for me. It also means it won't be a problem for other developers who are running tests built off the ANTLR grammar, since they typically won't be editing the file, just running the tests.

This sorts my problems out. Thanks.

Steve

Hi Danny,

The problem encountered here is that Visual Studio doesn't provide any data about the actual encoding of the file you're working with. This makes it impossible for NCrunch to know exactly how to write the file into the workspace after it's been opened in the VS editor.

NCrunch does make some effort to infer the encoding by reading the underlying file and using this in combination with the data provided by VS .. but it is a 'best effort' scenario that unfortunately can never be completely reliable.

It's possible that you're working with a file in which the encoding can't be safely inferred, or the encoding is of a form that NCrunch simply doesn't recognise. If you're able to share a sample file with me (you can submit it via the contact form, I can take a look to see if there's any way we can make the encoding detection smarter - but it is hard to make promises with the limited data available.

Agreed. Such a mechanism currently doesn't exist. In theory, it could be possible for NCrunch to read a custom property from the build item to identify the encoding, for example:

<ItemGroup>
<None Include="MyFile.txt">
<NCrunchEncoding>UTF8</NCrunchEncoding>
</None>
</ItemGroup>

... But my preference would be to avoid this if possible. If you can provide me with a sample file that reproduces this, I will investigate and try to find a better option.

That's ... not normal. It may be related to the size, though I had thought 5mb would be OK ..

Is there any other way you can share the file with me? Can you perhaps send a dropbox link through the contact form? Sorry for the trouble.

Got it. Thanks! I'll get back to you soon.

Excellent! That fixed my issue.