-
-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WProject does not work on Linux #57
Comments
Hello, I have looked our handlers and found hardcoded Affected handlers:
I don't know when I'll be able to fix this because of everything in my life today // 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. |
@3F you likely only need to append |
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
<#57 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAYYT7O4X4OHPEN3QSEZVXLXOO4F5ANCNFSM6AAAAAAZZNJ4MQ>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Switching from |
I have created a pull request for this located @ #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. |
* FIXED: Fix issue with string builder removing too much raw sln data on Unix platforms. Related issue: 3F#57
* NEW: Added default skeleton for SlnWriter in an attempt to make it easier to create from scratch. Empty .Write() methods will use it by default or merge it with the actual Map. * NEW: Added asynchronous metods* for SlnWriter *Both implementations including legacy netfx4.0 target platform, and async/await for modern. * NEW: Added SMap implementation to wrap ISlnResult.Map. More control over ISection and its handler. * NEW: Added LhDataHelper as an additional way to prepare default handlers from data (ISlnWhData). ``` LhDataHelper hdata = new(); hdata.SetHeader(SlnHeader.MakeDefault()) .SetProjects(projects) .SetProjectConfigs(prjConfs) .SetSolutionConfigs(slnConf); using SlnWriter w = new(solutionFile, hdata); ``` See related issue #61 for details. * NEW: Implemented CreateProjectsIfNotExist option for SlnWriter. ``` using SlnWriter w = new(solutionFile, hdata); w.Options = SlnWriterOptions.CreateProjectsIfNotExist; // it will write according ProjectType information (both legacy or sdk-style) w.Write(); ``` Use +IProjectsToucher to override implementation. You can find complete example in #61 * NEW: New modern LineBuilder to make creating new handlers easier or control EOL. Related issue #57. * NEW: Added DefaultHandlers wrapper to prepare all default according to ISlnResult(ISlnWhData). * NEW: SlnWriter: + WriteAsString() & WriteAsStringAsync() to save the result as string instead of file. ``` using SlnWriter w = new(handlers); string data = await w.WriteAsStringAsync(sln.Result.Map); ``` * NEW: Added platform independent IObjHandler.NewLine to specify the EOL for used w\handlers. +.UpdateNewLine() extension for a collection of handlers. * NEW: New modern IXProject.AddReference(.., AddReferenceOptions) to control everything for `Reference` nodes. Old signatures has been marked as obsolete and scheduled to be removed in future versions. ``` Default = HideEmbedInteropTypes | HideSpecificVersion, DefaultResolve = Default | ResolveAssemblyName | OmitArchitecture | OmitCultureNeutral | ... Mini = Default | HidePrivate, MiniResolve = Mini | DefaultResolve | OmitCulture, ``` See related issue #61 for details. * NEW: SlnWriter now supports ISlnResult -> +ISlnWhData data to preapre default handlers itself. * NEW: Implemented overriding of GetHashCode/Equals for ImportElement, RoProperties, Projects.Item. * NEW: +IConfPlatform.IsEqualPair(IConfPlatform) * NEW: ProjectItem adds ability to generate a project name from a specified input path: slnDir\ProjectName\src.csproj -> ProjectName slnDir\ProjectName.csproj -> ProjectName ``` new ProjectItem(ProjectType.CsSdk, @$"{projName}\src.csproj", slnDir: baseDir) ``` * FIXED: Fixed bug with a disappearing `EndProject`. See related #56 * FIXED: Fixed duplicated lines when disabling some features through SlnItems. * FIXED: Fixed lines being ignored when handlers are not prepared. * FIXED: If the handler is not initialized as object, the corresponding entry is lost. * FIXED: Fixed PackageInfo == Equals for null. * CHANGED: SlnParser has been switched to UTF8 by default. * CHANGED: SlnWriter now will ignore W\handler that will return null value at IObjHandler.Extract(). * CHANGED: Removed comparing of parent project and origin item in PropertyItem.Equals. * CHANGED: SlnHeader is sealed now with new ctors and added SlnHeader.MakeDefault(). * CHANGED: ConfigPrj: new ctors +protected internal set for IncludeInBuild and IncludeInDeploy properties. * CHANGED: Projects.Item and PropertyItem: new ctors & renamed evaluatedValue, evaluatedInclude, unevaluatedValue, unevaluatedInclude Old access still is available but marked as obsolete and scheduled to be removed in future versions. * CHANGED: Updated path \ / logic between Windows and unix-like systems.
2.7 got the LineBuilder and NewLine options for handlers ...
Tested on Ubuntu 20.04 https://ci.appveyor.com/project/3Fs/mvssln-2d2c2/builds/49716014/tests |
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.
The text was updated successfully, but these errors were encountered: