WProject does not work on Linux

[prochnowc]

When 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.

[3F]

Hello,

I have looked our handlers and found hardcoded minus 2 (sln format is CRLF regardless of platform while internal AppendLine() yes, dependent and hardcoded for specific platform. This is obviously a bug. Thanks for the report!

Affected handlers:

• WProject
• WProjectSolutionItems
• WVisualStudioVersion

I don't know when I'll be able to fix this because of everything in my life today But you can temporarily patch usage in your projects:

// add new wrapper-handler like ~
sealed class WhFix: WAbstract
{
    private readonly IObjHandler o;
    private readonly bool hasBug57
        = MvsSlnVersion.number <= new Version(2, 6, 1, 0) && Environment.NewLine.Length < 2;

    public override string Extract(object data)
        => o.Extract(data) + (hasBug57 && o is not WVisualStudioVersion ? "ct" : "");

    public WhFix(IEnumerable<ProjectItem> p, ISlnProjectDependencies d) => o = new WProject(p, d);
    public WhFix(IEnumerable<SolutionFolder> f) => o = new WProjectSolutionItems(f);
    public WhFix(SlnHeader h)
    {
        if(hasBug57) h.SetMinimumVersion($"{h.MinimumVisualStudioVersion?.ToString() ?? "10.0.40219.1"}00");
        o = new WVisualStudioVersion(h);
    }
}

After, the same usage but through WhFix ~

[typeof(LProject)] = new(new WhFix(projects, dependencies)),
[typeof(LProjectSolutionItems)] = new(new WhFix(folders)),
[typeof(LVisualStudioVersion)] = new(new WhFix(header)),

Or anybody please open PR with tests for both platforms I'll try to review and release it asap.

Sorry for the inconvenience. AppendLine() logic must be abstracted to be platform independent. Or correct me what the result with apps and no CR .sln on linux systems

[TheConstructor]

@3F you likely only need to append "t" and not "ct" as Environment.NewLine.Length == 1 on Linux, not 0

[3F]

Right, Thanks! thoughts were about the Project and minus 2. For NewLine.Length < 2 it doesn't matter because this meant != 2 but with upper restrict which is my habit i.e. just less than the specified number.

So let's check it again because I haven't been able, yet, Do the apps EXPECT crlf in .SLN FORMAT or they rely on the used system?

The official SLN (VS part; not msbuild) is too closed and hardcoded so I'm not sure here until I test it in specified environment. Moreover, I'm also thinking of a case where a linux apps will try to generate a SLN for a windows environment (n. win VS fails if no CR)

I think we need some option to set expected terminating characters at least in all Whandlers to be able to generate it for different target platforms in the same environment at runtime. What do you guys think about it?

On 04.07.2023 9:49, Matthias Vill wrote:

@3F https://github.com/3F you likely only need to append |"t"` and not |"ct"|as|Environment.NewLine.Length == 1|on Linux, not|0

— Reply to this email directly, view it on GitHub https://github.com/3F/MvsSln/issues/57#issuecomment-1619614820, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYYT7O4X4OHPEN3QSEZVXLXOO4F5ANCNFSM6AAAAAAZZNJ4MQ. You are receiving this because you were mentioned.Message ID: @.***>

[TheConstructor]

Switching from AppendLine to Append(..."\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 to Environment.NewLine by default

[teekayarezee]

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.

[3F]

2.7 got the LineBuilder and NewLine options for handlers ...

• NEW: New modern LineBuilder to make creating new handlers easier or control EOL. Related issue #57.

• NEW: Added platform independent IObjHandler.NewLine to specify the EOL for used w\handlers. +.UpdateNewLine() extension for a collection of handlers.

Tested on Ubuntu 20.04 https://ci.appveyor.com/project/3Fs/mvssln-2d2c2/builds/49716014/tests