Well, it is not a matter of Unity. In fact, Unity sends the file to the Visual Studio and it is Visual Studio that re-sends it into a NotePad.
Reason
The reason behind is that VS does not open all the files. The file I was trying to open is legacy source code that, for some reason, did contain the ASCII ETX
character (0x03
) in it.
Visual Studio seems to reject non-perfectly-formatted files.
How to repeat
In fact, the error can be repeted without unity at all and playing only with the filesystem and the Visual Studio.
I just started by making a drag-and-drop from the Explorer into the VS, like this:
Visual Studio finds the file as "invalid" and does not want to open it. So it launches Notepad:
You can see it directly starts with the text using
. This is what the file looked like (dumped with OctalDump dumping "hexa" in one line and "ascii" in the other, in a Linux machine):
You can see it really starts with the text using
at byte 0. You can see the rare character there (0x03
, ETX
).
I then opened the file into Sublime Text. You can see the ETX
there in the middle:
Solution
What then I did is to tell Sublime to add the UTF-8 BOM header into the file, so it should be, at least, "more compatible" than finding weird characters without telling anything.
This is what the file looks like now in a hex dump:
So you can there see first the BOM header at bytes 0, 1 and 2, then the using
word starting at byte number 3. Still you can see the ETX
invalid char there inside.
Now, you drag-n-drop the file into Visual Studio, and it opens it:
Finally, and for the sake of testing, I just duble-click within Unity and yes, it opens within Visual Studio:
Note 1:
If I remove ALL invalid characters from a file, then, even if the file does not have a BOM header, VS properly opens the file. But as this is legacy code and I don't know why another coder put the ETX
there, I can't just remove it and let it go... I need to keep the source as untouched. So adding the BOM was the solving solution.
Note 2:
It happened to me with the ETX
invalid char, but I guess this is extensible to any non-printable basic-ascii127 character.