Bizarre Error in Visual Studio 2015! Tell me what it means.

[jumper77]

"The line endings in the following file are inconsistent. Do you want to normalize the line endings?" And there's a combo box below that allows you to select the line ending format you want. I left it at the default and keep getting the error whenever I try to edit the file that gets the error.

Never seen this before. Any ideas?

[kaliman79912]

Are you importing your solution from a previous version?

[kaliman79912]

The message is clear, your lines of code have inconsistent line endings, like CrLf combo or \n or \r depending on where your source originated. Maybe you copied it from a Web page? either way it is just a warning and it will not affect your code as long as it stays in VS. The correct solution is fix all the line endings to the Microsoft standard (unless you are moving this project to Linux or Mac). But you could just leave them and turn off the warning.

[jumper77]

No... I've been using this project for about a month and it's just now happening. Now it's NOT happening. I was going to see if changing the end of line character fixed it. If it happens again, I will do that.

VS did that for about 6 times in a row.

edit: I'm been using version 2015 for a long time.

[Sitten Spynne]

You opened a text file I attached to a post. I'm using a Mac Mini running Mac OS X Yosemite.

Decades ago, when the ancestors of modern operating systems were first being invented, the designers had to decide what the line ending characters would be. Teletype machines connected to telegraphs, and certain kinds of printers, used two characters: Carriage Return (CR) told the machine to move the type head all the way back to the first position. Line Feed (LF) told the print mechanism to advance the paper by one line. This was an age where monitors didn't exist, so having printer-mechanics-oriented characters made a lot of sense.

The UNIX designers, and several other OS maintainers, were designing computers that would always have monitors. On a monitor, there's no concept of a "print head". And their OSes spoke with printers via drivers, which could easily send CR if it was needed or omit it if it wasn't. In this age, memory and disk space were very expensive. So they decided in this new OS, they would use only LF as the line ending character in text files, and stop using CR + LF to indicate a new line. This meant, in a 100-line file, 100 whole bytes would be saved.

The MS-DOS designers apparently decided that monitors were a fad, and no one would ever use a machine without a teletype attached. So they stuck with CR + LF for compatibility reasons. And when they developed Windows, an operating system that only operated on monitors, they decided to maintain this in case monitors fell out of style. And here we are, nearly 30 years later, in a world where some people have never even seen a teletype machine, and new versions of Windows still maintain CR + LF as the line ending for the same reason a lot of terrible UNIX mechanisms remain: "For historical reasons."

So when I saved my file, each line ended with LF. If you open it on a Windows machine, Windows expects to find CR + LF. It doesn't, and it's common enough this can display. But depending on your VS settings, while you edit, it might add CR + LF at the end of your lines. Then, when you open the file, VS will notice and ask you if you want to convert to one or the other.

It's not really an error. It's a hint that you might inadvertently cause problems if someone tries to open the file with a text editor so primitive it can't handle both LF and CR + LF as a line ending. I actually use one sort of like that, if it sees mixed line endings it puts special characters at the end of the 'offending' lines so I know it's mixed. It can cause annoyances in source control systems and a few other edge cases. But it's pretty harmless, in the grand scheme of things.

I don't know what options you have in VS, but it'll go away if you pick one that tells it to "convert to Windows' stupid line endings". If you keep it as-is, you'll keep getting the message until you either do that, or dig in the VS options to tell it to use LF instead. But that'll cause every OTHER text editor on your system to whine about the line endings.

But man, when teletype comes back, we'll be ready. Windows 10 is cutting-edge when it comes to supporting 60-year-old communications devices that use interfaces and cables no modern computer has. Every other OS on the planet, that 99% of them, they're all going to be sorry when print-only computers come back.

(Wow, I sure am generating a lot of posts lately about how difficult life is because MS made practically every OS design decision based on "do the opposite of UNIX". I guess I need to retire to Slashdot.)

[kaliman79912]

Until it fixed all the inconsistencies. Do not worry about the issue, but it would be good if you knew why that happened. Most times it is after a copy-paste combo that involves some external application as word, excel, eclipse or any other.

[jumper77]

Thanks S and kaliman, I didn't know you were working on another OS. The file that it complained about was not one of yours, but I did open and use one of yours and that's just a short while before getting the error. And before I forget, is it possible that causes me not to be able to make an instance of the Compare class?

And yea, I know about the different line endings. That has been around for a LONG time.

And about the printer... the first printer I saw was called a "Line Printer" That's what was used for debugging a long time ago. When I first started programming, I was told that people used to work with "punch cards" to program. And I said, if that were the case now, I would never had tried programming

Thank you both for the info. Really appreciate it.

edit: S, you can send me a PM about getting an instance. No need to add anymore to this thread.

[Sitten Spynne]

I uh, don't understand the question? What is "getting an instance"? And what relation to this thread did it have? I'd much rather talk in public.

[jumper77]

Whoa! I just remembered something... For a long time now, I've been getting an error saying that the file was modified externally and do I want to reload it. Could that be a part of the same thing?

[jumper77]

Public is fine... I don't know if the "Compare" class is a special thing or not, so I've been trying to do:
dim cmpr as Compare = new Compare , and it doesn't work. That's why I asked.

[jumper77]

extra: I made a new class with all the methods in the Compare class and I can make an instance just fine. That's why I thought "Compare" might be a special case (like ICompare or something).

[jumper77]

Well, my question is answered. I opened up ever .vb file in the project directory with notepad++, and after THAT, I was able to declare an instance (dim cmpr as new Compare)

Works like a charm now. This is really weird.

[Sitten Spynne]

I feel like you forgot you're in a different thread.

[jumper77]

No! I'm at that point where you said to type things over and over until I could do it in my sleep. Starting with the "LessThan" code.

[passel]

You opened a text file I attached to a post. I'm using a Mac Mini running Mac OS X Yosemite.
...
So when I saved my file, each line ended with LF.
...

When did Mac OS switch to using LF as the Line Ending Character. They had been using a single CR as their line ending character for most of the years I've dealt with Apple.
Never mind, looked it up. they switched to using LF when they went from OS 9 to OS 10 (OS X), as part of being POSIX-compliant.

I bought a Mac mini a number of years ago, but unfortunately was just before they switched to Intel Processors from Power PCs.
I think it is OS 9, but haven't even had it plugged in for quite a while now.
Out of curiosity just checked and also noted that the last Mac OSX to support PowerPC was 10.5 Leopard. Perhaps I should at least try to get the last supported OS on the PowerPc Mac mini while I can (if I can).

p.s. Someone else says that Snow Leopard was the last, so maybe OS X 10.6 will work. Will have to check it out.l

[jumper77]

Hi passel, good to hear from you. The only time I ever used a Mac was many years ago in school. I was a Dos guy. I worked at the computer lab, helping people with their computer assignments. And I had one thing to do on the ONLY Mac in the lab. The staff were the only ones who could use it.... for reasons I can't remember.

My task on the Mac was to print the weekly times the comp lab was going to be open. One day I couldn't bring the file up and it returned (Dos error #2) File not found. I tried working with the GUI for a while and could not find the file. I finally as someone else who had worked there permanently How could I get to a Dos prompt, because I knew I could find it that way.

After he got through laughing, he told me there was no such thing. I looked at him in disbelief. No Dos prompt???

That was the first major thing I learned about a Mac. Also, the reason that I hated it after that (I was pretty dumb back then).

[Sitten Spynne]

Now OS X has a bash shell. It was released in 1989 and, in combination with the GNU tools, beats the everliving stuffing out of an MS Command Prompt.

It's so much better, Win10's about to get a bash shell of its own. That's capable of running Ubuntu executables. FINALLY I can get something done in a Windows shell... 2 years after I quit using Windows machines. Whoops.

[FunkyDexter]

We used to see that error all the time at one of the shops I worked at. We never managed to fully nail it down but it was something to do with different devs opening visual studio on different machines. We were all using the same OS (Win 7 if memory serves) as well so we figured it was some user setting somewhere. It never actually caused a problem so we quietly swept it under the carpet.

[jumper77]

Hi dex, thanks for the post about this issue. I'm glad to here that it has happened to other people because it has made me think about it. As I said, I've never seen this before. The only thing I can think of that has changed is: Up until I came here, I never had a reason to have two different projects loaded at the same time. But now I do it every day.

Actually, there is one more change to note. Many times I will open a logfile to see some output. But the issue still occurred when I didn't do it at all. So, I don't really know what causes this to happen. But for now, it's not doing it anymore. Which makes it tough to troubleshoot.

So....... I give.