When I deploy my SharePoint project I receive the following error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SharePointTools\Microsoft.VisualStudio.SharePoint.targets(375,5): error : '.', hexadecimal value 0x00, is an invalid character. Line 1, position 1.
The line number relates to the following in the build XML:
<CreateSharePointProjectService Configuration="$(Configuration)"
Platform="$(Platform)"
ProjectFile="$(MSBuildProjectFile)"
ProjectReferences="#(SharePointProjectReference)"
OutDir="$(TargetDir)">
<Output PropertyName="ProjectService" TaskParameter="ProjectService" />
</CreateSharePointProjectService>
Furthermore I've managed to whittle down the problem (or at least seemingly) to the following property:
ProjectFile="$(MSBuildProjectFile)"
i.e. if I remove this property then I no longer get the same error message (but I get others as a consequence).
I'm not sure what's going on here as I know nothing about MSBuild. Obviously this always used to work before so I don't know what's changed to cause it to no longer work. Any suggestions will be greatly appreciated as I've wasted a lot of time on this already. BTW, this problem occurs in both Visual Studio 2010 and 2012.
Thanks
OK, problem sorted. It turns out that the error message actually referred to an XML file referenced by the solution (containing some deployment files). This XML had somehow become corrupted which does fit the message '.', hexadecimal value 0x00. After removing this feature (which didn't need deploying anyway) the problem disappeared so the world can go on being a happy place again (or at least my manager is!)
I just ran into this after downloading an msbuild file from the internet. Opening the newly downloaded file in a hex editor showed me what the problem was pretty quickly. The file was downloaded with 2 byte characters, and every other byte was a 0. I think Notepad++ said the encoding was UCS-2. In any case, the fix was pretty simple. Notepad++ has an Encoding menu option that I used to rewrite the file as UTF-8. Changing the file back to UTF-8 immediately fixed the problem.
Hope this helps people in the future.
--Addendum - I might have tried to muck with the file using PowerShell before its encoding changed.
Related
I used the instructions on the BeyondCompare website (also referenced in this SO question) to configure VS2010 (TFS) to compare source control using Beyond Compare. This approach appears to be broken. The file in the left-hand view (from the server) does not appear at all in BC3, and a Conversion Error is reported.
Upon further inspection, I noticed that the filename generated by Visual Studio when serving up the file from the source control (i.e., the previous revision) looks like this: filename.xml;C1956. There is a semicolon in the filename, as a delimiter between the original filename and the rev number. This is confusing BC3. To confirm this, I took the served-up version of the file (which gets stored temporarily in \AppData\Local\Temp\TFSTemp\), and renamed it, removing the semicolon. BC3 loaded it just fine. But when I put the semicolon back in, the Conversion Error returned.
UPDATE: Upon further testing, I realize this is only an issue with XML files. If I rename the file with a different extension, BC3 loads it just fine.
Has anybody discovered a workaround for this?
Turns out (after contacting the very efficient ScooterSoftware support desk) the problem was with the XML formatting plugins. In BC3, under Tools -> File Formats, I disabled (unchecked) the following formatters:
* XML Tidied
* XML Tidied with Attributes Sorted
The semicolon-file then displayed just fine. These formatters use the freeware converter, HtmlTidy, from http://tidy.sourceforge.net. I haven't determined whether a newer version of this plugin might help. For now I've just turned them off (which works for this situation because the visual studio xml is already "tidy".)
Using Visual Studio 2010. I have a resource.h file which TortoiseHg thinks is binary so it won't display a diff for it in the commit window. I can easily open the file in a text editor and see that it is plain text.
I saw a related question (Why does Mercurial think my SQL files are binary?) which suggests it has to do with file encoding. Indeed opening the file in Notepad++ says the file is in "UCS-2 Little Endian". How can I fix this? I, obviously, don't want to break some Visual Studio expectation.
For display purposes only, Mercurial treats all files containing NUL bytes as binary due to long-standing UNIX convention. This is just about always right.. except for UTF-16 (formerly known as UCS-2).. where half your file is NUL bytes!
Internally, Mercurial treats all files as binary all the time, so this issue is only relevant for things like whether or not we try to display diffs.
So you have two options:
ignore it, Mercurial will work just fine
use an encoding other than UTF-16
Some web searched for "resource.h utf-16" suggest that VS2010 will be just fine if you save this file in UTF-8 or ASCII, which should be perfectly fine choices for C source code.
http://social.msdn.microsoft.com/Forums/en/vssetup/thread/aff0f96d-16e3-4801-a7a2-5032803c8d83
Try explicitly converting / changing the encoding to UTF-8 / ASCII and see. You can do that from Notepad++'s Encoding menu ( choose Encode in UTF-8)
Visual Studio will work with the UTF-8 file just fine.
I get the message "File or diffs not displayed: File is binary."
Why is mercurial (hg) treating my visual studio solutions (.sln) as binary?
And how do I stop it?
Thanks
I tried this out on one of my projects and the sln file was treated as a text file. Check if your sln file is in a different encoding like UTF-16. Otherwise, Hg should not be treating it as binary. Try explicitly converting / changing the encoding to UTF-8 / ASCII and see.
For actual storage Mercurial treats all files as binary. It never does line conversions or anything else that requires considering things as text or knowing the file's encoding.
However, at the UI level (separate from the storage level) it will try to avoid filling your screen with binary gookus, and to do that it uses a simple test -- a file won't be displayed in diffs if it has one or more NUL (0x00) characters in it.
So your .sln file must have a 0x00 somewhere in it. The most common cause is misbehaving editors putting a Byte Order Mark (BOM) at the front of the file.
If you can remove the NUL Mercurial will display the file contents, and if you can't I think you're out of luck.
I have problems with files encoding in Visual Studio 2008. While compiling I'm getting such errors:
When I'm trying to open file where particular error occures, encoding window appears:
By defualt auto-detect is set. When I change encoding option to UTF-8, everything works. If I open each problematic file in my project using UTF-8 encoding, project starts to compile. The problem is I have too many files and there is ridiculous to open each file and set encoding to UTF-8. Is there any way to make this in a quick way ?
My VS settings are:
I'm using Windows Server 2008 R2.
UPDATE:
For Hans Passant and Noah Richards. Thanks for interaction. I recently changed my operating system so everything is fresh. I've also downloaded fresh solution from source control.
In OS regional settings I've changed system locale to Polish(Poland):
In VS I've changed international settings to the same as windows:
The problem is still not solved.
When I open some .cs files using auto-detection for encoding, and then check Files -> Advanced Save Options..., some of this .cs files have codepage 1250:
but internally looks following:
It is wired, because when I check properties of such particular files in source control, they seems to have UTF-8 encoding set:
I don't understand this mismatch.
All other files have UTF-8 encoding:
and opens correctly. I have basically no idea what is going wrong because as far as I know my friend has the same options set as me, and the same project compiles for him correctly. But so far he happily hasn't encountered encoding issues.
That uppercase A with circumflex tells me that the file is UTF-8 (if you look with a hex editor you will probably see that the bytes are C2 A0). That is a non-breaking space in UTF-8.
Visual Studio does not detect the encoding because (most likely) there are not enough high-ASCII characters in the file to help with a reliable detection.
Also, there is no BOM (Byte Order Mark). That would help with the detection (this is the "signature" in the "UTF-8 with signature" description).
What you can do: add BOM to all the files that don't have one.
How to add? Make a file with a BOM only (empty file in Notepad, Save As, select UTF-8 as encoding). It will be 3 bytes long (EF BB BF).
You can copy that at the beginning of each file that is missing the BOM:
copy /b/v BOM.txt + YourFile.cs YourFile_Ok.cs
ren YourFile.cs YourFile_Org.cs
ren YourFile_Ok.cs YourFile.cs
Make sure there is a + between the name of the BOM file and the one of the original file.
Try it on one or two files, and if it works you can create some batch file to do that.
Or a small C# application (since you are a C# programmer), that can detect if the file already has a BOM or not, so that you don't add it twice. Of course, you can do this in almost anything, from Perl to PowerShell to C++ :-)
Once you've opened the files in UTF-8 mode, can you try changing the Advanced Save Options for the file and saving it (as UTF-8 with signature, if you think these files should be UTF-8)?
The auto-detect encoding detection is best-effort, so it's likely that something in the file is causing it to be detected as something other than UTF-8, such as having only ASCII characters in the first kilobyte of the file, or having a BOM that indicates the file is something other than UTF-8. Re-saving the file as UTF-8 with signature should (hopefully) correct that.
If it continues happening after that, let me know, and we can try to track down what is causing them to be created/saved like that in the first place.
I recently got asked to review a Visual Studio solution. One of the first things I did was run SourceMonitor on it. But when I tried to analyze it, I got an error that said SourceMonitor could not parse Unicode or UTF-encoded files. Is there a quick was to convert all of the .cs file in a solution to ASCII encoding?
No need to convert anything:
From the SourceMonitor page:
An option has been added to the
Options | General dialog to allow
parsing of source code files with
UTF-8 encoding. These files will parse
correctly as long as all characters in
the file are represented by 8 bit
codes.