Compatability with .slnx format

[MPapst]

Description

Parse and map the newly supported slnx file format for solution files.

Previously mentioned in #1375, but with .NET SDK 9.0.2x now officially supported.

Usage Example

• Should work in the same way as the current solution file parsing.
• Should be completely transparent for the developer

Alternative

Use

[Parameter] readonly string Solution;

instead of a parsed solution-object.

Could you help with a pull-request?

Yes

[Droppers]

This library provided by Microsoft could be used for that:

https://github.com/microsoft/vs-solutionpersistence

[MPapst]

I would like to add an parser.

Would you prefer manual parsing or adding the MS parser?
An additional package (if that is even possible, haven't looked up the architecture) or inline?

[MTuel]

Do we have any updates on this? It looks like with .NET 10 Microsoft is moving toward making the slnx format the default.

https://learn.microsoft.com/en-us/dotnet/core/compatibility/sdk/10.0/dotnet-new-sln-slnx-default

[MPapst]

To be honest - I haven't started and do not plan to start without an answer with a preference from @matkoch .

[AlexejLiebenthal]

FYI, if you don't rely on the parsing, you can simply switch from this:

[Solution] readonly Solution Solution;

to this:

[Parameter] readonly string Solution;

@MPapst maybe you could add this as an Alternative to your issue description.

[Droppers]

I really understand that maintaining an open source project next to your main job can be exhausting. But for us there are several issues, because we have 100+ Nuke pipelines:

• SLNX files are becoming the standard, they are easier to maintain and the only reason we cannot move to them is because Nuke is missing support.
• Tools are heavily outdated or are missing, for example Yarn, of which we created a pull request a long time ago. Docker tasks, Kubernetes tasks, etc...
• Major or minor breaking changes are not discussed with the community, some examples we ran into that resulted in a quite a lot of work:
  • Removal of (in our opinion) the better Arguments class.
  • Changes in tool resolving logic.

We see the following options:

• Allow additional maintainers and encourage pull requests and discussions about new features (best option, this would offload a lot of work for you, and make this project more active). Based on the the reactions on this issues there a quite a bit of people interested in the future of Nuke.
• Fork the repository. This is something we are considering, by making an internal fork and adjusting Nuke to our likings.

[MTuel]

I really understand that maintaining an open source project next to your main job can be exhausting. But for us there are several issues, because we have 100+ Nuke pipelines:

• SLNX files are becoming the standard, they are easier to maintain and the only reason we cannot move to them is because Nuke is missing support.

• Tools are heavily outdated or are missing, for example Yarn, of which we created a pull request a long time ago. Docker tasks, Kubernetes tasks, etc...

• Major or minor breaking changes are not discussed with the community, some examples we ran into that resulted in a quite a lot of work:

  • Removal of (in our opinion) the better Arguments class.
  • Changes in tool resolving logic.

We see the following options:

• Allow additional maintainers and encourage pull requests and discussions about new features (best option, this would offload a lot of work for you, and make this project more active). Based on the the reactions on this issues there a quite a bit of people interested in the future of Nuke.
• Fork the repository. This is something we are considering, by making an internal fork and adjusting Nuke to our likings.

This is where I'm at as well. At least some discussion on what the path forward looks like would be appreciated.

[jwfx]

@Droppers
Very well written. We face pretty much the same issues than you guys do.

Since this might potentially be a bigger discussion and probably will go too much out of scope for this slnx issue, would you mind reposting it in the Dicussions section?

[Droppers]

@jwfx good point, I have reposted it as a discussion: #1564

[MPapst]

Using your comments to get back to the original topic:

slnx format will definitely include breaking changes, as the format works completely different. There is no thing such as the Header property or Project Type Guids.

Therefore it is not a straight forward implementation and needs some discussion beforehand.

[ImoutoChan]

Maybe we can introduce a separate SolutionX class

[MPapst]

Thats the discussion I tried to start with this comment: #1520 (comment)

[Droppers]

Using your comments to get back to the original topic:

slnx format will definitely include breaking changes, as the format works completely different. There is no thing such as the Header property or Project Type Guids.

Therefore it is not a straight forward implementation and needs some discussion beforehand.

I am pretty sure the package Microsoft provides supports everything that Nuke also supports, since that package is made to work both with SLN and SLNX files, using the same models. For SLNX projects it generates predictive guids, I guess using the project path?