Reordering files in F# Solution Explorer causes items in <ItemGroup> to be listed horizontally

[GarryPatchett]

Describe the bug

When using F# Solution Explorer and using the "Move file up" and Move file down" arrows, no evidence can be seen until the buttons are pressed twice and, in the meantime, the ordering of the files in the fsproj file becomes 'horizontal' rather than 'vertical'.

Steps to reproduce

1. Create new project with: dotnet new classlib -lang f# -o TestLib
2. Launch VS Code and open the TestLib folder;
3. Go to the F# Solution Explorer;
4. Add a file called Test1.fs below Library.fs;
5. Add a file called Test2.fs above Library.fs;
6. Go to the VS Code Explorer and open the fsproj file.

And it all looks okay – a vertical listing of fs files at this point.

However, when I go back to F# Solution Explorer and press the “up-arrow” icon to the right of Test1.fs no change can be seen.

If I then go to the VS Code Explorer and open the fsproj file I see:

 <ItemGroup>
   <Compile Include="Test2.fs" />
   <Compile Include="Library.fs" /><Compile Include="Test1.fs" />
 
 </ItemGroup>

If I then go back to F# Solution Explorer and press the “up-arrow” icon to the right of Test1.fs again then Test1.fs moves above Library.fs but I now have, in the fsproj file:

 <ItemGroup>
   <Compile Include="Test2.fs" />
   <Compile Include="Test1.fs" /><Compile Include="Library.fs" />
 
 </ItemGroup>

Then, moving Test2.fs down once gives me:

 <ItemGroup>
 
   <Compile Include="Test2.fs" /><Compile Include="Test1.fs" /><Compile Include="Library.fs" />
 
 </ItemGroup>

Expected behaviour

I would expect to see the file move on the first press of the buttons and that the files would remain listed 'vertically'.

Machine infos

• OS: Windows 10.0.19045
• .NET SDK version: 9.0.311
• Ionide version: 7.31.1

Additional context

I looked at the line endings of the fsproj file (in Notepad++) and they are all CRLF (except for the final line which is at the end of the file anyway).

[github-actions]

🤖 This is an automated response from Repo Assist.

Thanks for the detailed report with reproduction steps, @GarryPatchett! There are actually two separate bugs at play here:

Bug 1: Horizontal formatting of (Compile) elements

When the file order is modified, the FSAC language server rewrites the .fsproj file's XML. The XML serialization doesn't preserve the whitespace-only text nodes between elements, so elements that were on separate lines end up on one line. This is an upstream issue in FsAutoComplete — specifically in the code that manipulates (ItemGroup) elements. It would be worth filing there as well if one doesn't already exist.

Bug 2: First button press makes no visible change in Solution Explorer

After calling FSAC to move the file, the Solution Explorer refreshes when Project.workspaceChanged fires (which happens when FSAC reloads the modified .fsproj). The delay you're seeing — where the first press appears to do nothing — is likely because the FSAC-driven project reload takes a moment to complete, and the notification hasn't arrived yet when you look at the Explorer. The second press triggers another modification which then causes the accumulated changes to become visible.

Both issues are ultimately rooted in FSAC's project manipulation code. For now, you can work around the formatting issue by closing and reopening the .fsproj file after reordering, or reformatting the XML manually. The reordering itself is functionally correct — only the presentation is affected.

Generated by Repo Assist · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@346204513ecfa08b81566450d7d599556807389f

[TheAngryByrd]

/repo-assist create a PR to fix this. Make sure to add tests.

[github-actions]

Pull request created: #1499

Generated by Repo Assist

[github-actions]

🤖 This is an automated response from Repo Assist.

I've created a PR to fix both bugs described in this issue: [Repo Assist] Fix moveFileUp/Down: preserve vertical formatting and fix first-press no-op.

Root cause: FsProjEditor.moveFileUp/moveFileDown called node.PreviousSibling/NextSibling to find the adjacent (Compile) element. With PreserveWhitespace = true, whitespace-only text nodes sit between XML elements, so those calls returned the whitespace text node, not the next (Compile). This caused:

• First press no-op: InsertBefore(node, whitespaceNode) left the compile order unchanged.
• Horizontal formatting: The second press moved the element, but with no preceding whitespace node, so adjacent elements ended up on the same line ((Compile A /)(Compile B /)).

Fix: Added previousSiblingElement/nextSiblingElement helpers that skip text nodes, plus a clone-and-swap strategy that leaves whitespace text nodes (indentation) untouched when reordering elements.

Tests: 16 new unit tests in FsProjEditorTests.fs covering order correctness, boundary conditions, the single-press regression, and vertical-formatting preservation for both LF and CRLF line endings.

Generated by Repo Assist for issue #1498 · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@346204513ecfa08b81566450d7d599556807389f