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

No response

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: https://github.com/nuke-build/nuke/discussions/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: https://github.com/nuke-build/nuke/issues/1520#issuecomment-2722299049

[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?

[MPapst]

The issue is, that the Nuke Solution class offers the possibility to access raw data from the sln file, which is no longer available in the xml format: https://github.com/nuke-build/nuke/blob/da2ea1fecf4896fbd68f3c1884ea704e64b0412f/source/Nuke.SolutionModel/Solution.cs#L49-L52

The model, how it works is simply different. So either a new Solution class or throwing a NotSupportedException when accessing these properties are possible options.

[Droppers]

The issue is, that the Nuke Solution class offers the possibility to access raw data from the sln file, which is no longer available in the xml format:

nuke/source/Nuke.SolutionModel/Solution.cs

Lines 49 to 52 in da2ea1f

public string[] Header { get; set; } public IDictionary<string, string> Properties { get; set; } public IDictionary<string, string> ExtensibilityGlobals { get; set; } public IDictionary<string, string> Configurations { get; set; } The model, how it works is simply different. So either a new Solution class or throwing a NotSupportedException when accessing these properties are possible options.

It is all supported in the package, these property bags are the same as in Nuke, but are a keyvaluepair instead.

[iJinsPeter]

I also have this issue.
I tried the parameter‑based approach, but it didn’t solve it for me.

However, I have a couple of easy workarounds for your scenario:

---

✅ Option 1 – SolutionXAttribute and SolutionXSerializer

Note: This option comes with a caveat. Since most root solutions include the NukeBuild project and I couldn’t find a direct way to skip building a single project in the new .slnx format, this could lead to a circular build dependency or a self‑hosting build deadlock.

You can implement your own SolutionXAttribute that uses a custom SolutionXSerializer to serialize your .slnx‑based solution file into a Solution object. (Tip: Using Claude Sonnet 4 AI assist, you just need the right prompt.)

---

✅ Option 2 – Solution Filters - Cleaner, and Easier

Add a new solution filter (Solution.slnf) from your existing Solution.slnx.
You’ll likely need this anyway to avoid compiling NukeBuild.csproj. Solution filter files work cleanly [Solution("Solution.slnf")] with NUKE’s Solution attribute. You dont need the Attribute or Serializer

---

[iJinsPeter]

Update: Option 2 Testing Results & Complete Solution

After extensive testing, I can confirm that Option 2 doesn't fully populate the Solution object - you lose critical project enumeration and metadata that Nuke builds depend on.

What I Discovered Option 2 gaps:

Incomplete Solution object population Missing project-level details needed for build logic No solution filter (.slnf) support for avoiding circular dependencies

Complete Working Solution; Option 3

The real fix requires SolutionFilterAttribute + SolutionFilterSerializer that intelligently routes to the right parser:

.slnx files → SolutionXSerializer (custom XML parser) .slnf files → SolutionFilterSerializer (JSON + base solution routing)

Key Technical Insight

The SolutionFilterSerializer internally uses SolutionXSerializer based on what base solution format it finds. This gives you:

✅ Complete Solution object - all projects, paths, and metadata ✅ Solution filter support - eliminates circular build dependencies ✅ Format flexibility - works with any base solution type

Option 2 alone leaves you with an incomplete object. You need the full serializer chain! 🔗

[matkoch]

See https://github.com/nuke-build/nuke/discussions/1564#discussioncomment-15033327

Unsupported APIs have been removed. Note the GetModel methods for more advanced use cases.