WProject does not work on Linux
See original GitHub issueWhen writing solution file using the WProject
handler the file is not correctly written on Linux systems.
WVisualStudioVersion
seems to have the same problem.
This is probably because on Linux the AppendLine
does add only LF instead of CR + LF.
WProject simply cuts off two characters.
Issue Analytics
- State:
- Created 3 months ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
C# project not running on a Linux System
I developed a C# project in Microsoft Visual Studio 2017 in .Net Core Environment. I works properly on my Windows 7 system. I...
Read more >Exported Web Project does not work on Linux with Mesa ...
EDIT: As I said earlier, It feels like the web export stopped working roughly 2 weeks ago. I have taken a look at...
Read more >Why can't Linux just work?
The problem is that instructions from a project's website are often intended for the project's developers or for testing pre-release versions.
Read more >Unity Hub not opening Projects On Linux [SOLVED]
Essentially the problem was that Unity Hub 2.1.2 on Ubuntu 18.04 was not able to create new projects or open existing ones.
Read more >Microsoft Project is not working - Linux - Desktop
Hi I'm new to Linux and i installed Ubuntu 9.04, and install the Wine 1.1.29 and when i install the Project 2007 it...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I have created a pull request for this located @ https://github.com/3F/MvsSln/pull/58. It is a fairly naive fix as it does not address the potential concerns about the official sln format, sln files being generated on Unix platforms then used on Windows etc. however, implementing this fix ensures functionality remains exactly the same when used on Windows platforms, and at least prevents the output sln from being corrupted when being used on Unix platforms.
Switching from
AppendLine
toAppend(..."\r\n")
or even something with a configurable line-break should solve this issue. Not sure, if there is an easy way to test how old NET Framework or Mono versions work - but if you can configure it, there shouldn’t ever be an unsolvable issue. We could then set that property toEnvironment.NewLine
by default