285

Visual Studio occasionally tells me:

The line endings in the following files are not consistent. Do you want to normalize the line endings?

It then gives me a drop down with different standards or something, such as Windows, Mac, Unix, and a couple of Unicode ones.

What does this mean and what is going to happen if I click Yes?

Nathan Baulch
  • 20,233
  • 5
  • 52
  • 56
MetaGuru
  • 42,847
  • 67
  • 188
  • 294
  • Visual Studio shows me this same message, but the "file" it refers to is in fact a folder! What does that mean?! – Colonel Panic Oct 05 '12 at 08:28
  • I made a little utility to do this to an entire directory or recursively through a set of directories for all files of a particular extension (like *.c or *.h), although I use Delphi, the utility works for any Windows source code files. Source code included plus binary (exe). It will report which lines have extra linefeeds (ie missing carriage returns) or extra carriage returns (ie missing linefeeds). https://docs.google.com/file/d/0B07SrKpE8ErmbHZ1SWkxT3RLczA/edit?usp=sharing – Warren P Apr 25 '13 at 18:55
  • 2
    Can be caused by `git`. See also : http://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git – Jess Jan 18 '16 at 18:32
  • 4
    They ought to have an option in the drop-down that says 'favor most common line ending type from the rest of the file/project'. – MetaGuru Jan 22 '16 at 23:18

12 Answers12

247

What that usually means is that you have lines ending with something other than a carriage return/line feed pair. It often happens when you copy and paste from a web page into the code editor.

Normalizing the line endings is just making sure that all of the line ending characters are consistent. It prevents one line from ending in \r\n and another ending with \r or \n; the first is the Windows line end pair, while the others are typically used for Mac or Linux files.

Since you're developing in Visual Studio, you'll obviously want to choose "Windows" from the drop down. :-)

Ken White
  • 123,280
  • 14
  • 225
  • 444
  • 2
    how does the line end without a carriage return... ? – MetaGuru Feb 16 '09 at 15:03
  • 28
    So why the flip does visual studio care how the lines end, it apparently recognizes all the different types, it should just be happy and shut up. – MetaGuru Feb 16 '09 at 16:10
  • 59
    Ah, but what if you're just using VS to fix something that isn't for Windows? Quick fix on a Linux utility or something that's straight C/C++, and you don't want CRLFs added? Wait-now you want MS to read your mind and know which to use? The VS team is wrong either way, aren't they? Sheesh! – Ken White Feb 21 '09 at 13:53
  • 27
    The problem isn't that VS can't cope with Unix line endings -- it can. The warning is telling you that the line endings are _inconsistent_ - ie some lines in the file are CRLF and some are LF. VS will cope with that but other applications in your tool chain may not, hence it warns you. If you don't care about this then turn the warning off: Options -> Environment -> Documents -> 'Check for consistent line endings on load'. This warning can be very useful if you are working on products across multiple platforms. – the_mandrill Aug 24 '15 at 10:49
  • I've read all the above comments, but which one to choose for the sake of cross-platform capability for a peace of mind? I'm using VS to maintain my Apps Script code by the way, but could be something else in the future. – Antonio Ooi Oct 11 '16 at 05:47
  • 2
    @AntonioOoi: There is no cross-platform line ending, I'm afraid, as long as Windows is in the mix. Windows/DOS always uses CR/LF, while every other OS I'm aware of uses just LF. The point here is that normalizing line endings will make sure that they're all the same no matter which one you're using, which makes switching much easier if the need arises. If most of what you're doing is non-Windows, use the *nix style LF only; if most of it is Windows, use the CR/LF pair. – Ken White Oct 11 '16 at 14:01
  • If I keep getting this message, could that mean that either my git settings or the git settings of someone else should be changed? I'm sure I have my git set to commit Unix style and to checkout Windows style. How am I still getting this message every time for some files? – Martijn Jan 25 '21 at 07:04
  • 1
    @Martijn: I'm afraid I can't answer that without being able to look at your files and git settings. I'd suspect that it's something to do with your git configuration - at least that's where I'd start looking to try to figure it out. – Ken White Jan 26 '21 at 00:22
  • Visual Studio itself apparently messes up line endings. We have had small files that are 100% coded by typing in Visual Studio and then had VS complain about the line endings in those files at a later date. It has been a known issue for years. – LoneSpawn Feb 24 '22 at 00:04
  • "Since you're developing in Visual Studio, you'll obviously want to choose "Windows" that's kind of incorrect assumption. Line ending depend on the target environment. – Swift - Friday Pie Sep 02 '23 at 10:51
  • @LoneSpawn If they were coded purely manually, that's weird. but even in newest VS all Microsoft code generators in Studio assume Windows line endings, but may break on edges of generated snippet even in Windows-style file (they accidently insert between `\r` and `\n`). `.editorconfig` file is being simply ignored by half of tools, then picked up by other submodules, which creates mess. Copying from file that is opened in VS but located outside of project's folder copies original endings. Copying from other editor does too. – Swift - Friday Pie Sep 02 '23 at 10:55
82

Some lines end with \n.

Some other lines end with \r\n.

Visual Studio suggests you to make all lines end the same.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Alex Reitbort
  • 13,504
  • 1
  • 40
  • 61
43

If you are using Visual Studio 2012:

Go to menu File → Advanced Save Options → select Line endings type as Windows (CR LF).

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
pankaj
  • 431
  • 4
  • 2
  • 1
    That option does not appear on my File menu for my Visual Studio 2010 Ultimate Version 10.0.40219.1 SP1Rel. – DOK Jul 11 '12 at 12:56
  • 1
    @DOK, on my File menu at Visual Studio 2010 Premium version it does!! – Peter Jul 20 '12 at 07:47
  • 4
    If you can't see the option you can customise your file menu by going to Tools->Customise, going to the commands tab and adding a command. – Rob Apr 24 '13 at 09:00
  • 1
    Is there a general setting which affects all files together? Its a pain to do this for all sources under a solution. – Klaus Jul 28 '16 at 07:32
26

To turn the option ON/OFF, follow the steps below from menu bar:

Tools → Options → Environment → Documents → Check for consistent line endings on load

CodingYoshi
  • 25,467
  • 4
  • 62
  • 64
9

The file you are editing has been edited with some other editor that does not use the same line endings, resulting in a file with mixed line endings.

The ASCII characters in use for line endings are:

CR, Carriage Return
LF, Line Feed

Windows = CRLF
Mac OS 9 or earlier = CR
Unix = LF

monowerker
  • 2,951
  • 1
  • 25
  • 23
7

The Wikipedia newline article might help you out. Here is an excerpt:

The different newline conventions often cause text files that have been transferred between systems of different types to be displayed incorrectly. For example, files originating on Unix or Apple Macintosh systems may appear as a single long line on some programs running on Microsoft Windows. Conversely, when viewing a file originating from a Windows computer on a Unix system, the extra CR may be displayed as ^M or at the end of each line or as a second line break.

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
Richard Ev
  • 52,939
  • 59
  • 191
  • 278
7

Line endings also called newline, end of line (EOL) or line break is a control character or sequence of control characters in a character encoding specification (e.g. ASCII or EBCDIC) that is used to signify the end of a line of text and the start of a new one. Some text editors set/implement this special character when you press the Enter key.

The Carriage Return, Line Feed characters are ASCII representations for the end of a line (EOL). They will end the current line of a string, and start a new one.

However, at the operating system level, they are treated differently:

  • The Carriage Return ("CR") character (ASCII 13\0x0D, \r): Moves the cursor to the beginning of the line without advancing to the next line. This character is used as the new line character in Commodore and Early Macintosh operating systems (Mac OS 9 and earlier).

  • The Line Feed ("LF") character (ASCII 10\0x0A, \n): Moves the cursor down to the next line without returning to the beginning of the line. This character is used as the new line character in Unix based systems (Linux, macOS X, Android, etc).

  • The Carriage Return Line Feed ("CRLF") character (0x0D0A, \r\n): This is actually two ASCII characters and is a combination of the CR and LF characters. It moves the cursor both down to the next line and to the beginning of that line. This character is used as the new line character in most other non-Unix operating systems, including Microsoft Windows and Symbian OS.

Normalizing inconsistent line endings in Visual Studio means selecting one character type to be used for all your files. It could be:

  • The Carriage Return Line Feed ("CRLF") character
  • The Line Feed ("LF") character
  • The Carriage Return ("CR") character

However, you can set this in a better way using .gitattributes file in your root directory to avoid conflicts when you move your files from one Operating system to the other.

Simply create a new file called .gitattributes in the root directory of your application:

touch .gitattributes

And add the following in it:

# Enforce Unix newlines
* text=auto eol=lf

This enforces the Unix line feed line ending character.

Note: If this is an already existing project, simply run this command to update the files for the application using the newly defined line ending as specified in the .gitattributes.

git rm --cached -r .
git reset --hard

That's all.

I hope this helps

Promise Preston
  • 24,334
  • 12
  • 145
  • 143
5

When you copy paste something from web, you might get the inconsistent line endings.
In order to fix this, you can use Visual studio extension "Line Endings Unifier" which can make line ending consistent automatically while saving file.

enter image description here

Jay Shah
  • 3,553
  • 1
  • 27
  • 26
5

It means that, for example, some of your lines of text with a <Carriage Return><Linefeed> (the Windows standard), and some end with just a <Linefeed> (the Unix standard).

If you click 'yes' these the end-of-lines in your source file will be converted to have all the same format.

This won't make any difference to the compiler (because end-of-lines count as mere whitespace), but it might make some difference to other tools (e.g. the 'diff' on your version control system).

ChrisW
  • 54,973
  • 13
  • 116
  • 224
4

It's not just Visual Studio... It'd be any tools that read the files, compilers, linkers, etc. that would have to be able to handle it.

In general (for software development) we accept the multiplatform line ending issue, but let the version control software deal with it.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Peter Y
  • 220
  • 2
  • 3
  • 1
    I agree. Best to let your SCM system do it. If you are using svn, see also http://stackoverflow.com/questions/15687/how-can-i-convert-all-line-endings-to-crlf-lf-or-cr-during-svn-operations – kgriffs Oct 05 '10 at 15:42
  • Totally agree. What happens if I'm working on a project and I'm on Windows and my team mate is using Mac. We will constantly be changing CR to CRLF and back again. Best to let the SCM abstract that away. Most of the answers just assume that people are working on their own or everyone working on the code is using Windows. – bytedev Oct 06 '16 at 10:49
2

There'a an add-in for Visual Studio 2008 that converts the end of line format when a file is saved. You can download it here: http://grebulon.com/software/stripem.php

0

I had this problem in VS 2019 and solved it by setting the LineBreak configuration for Windows, before it was set for Unix.

Tools > Options > Format on Save > Settings > LineBreak: Windows

Marcio Antônio
  • 1