Skip to content

.slnx solution files still cause "No file format header found" in v10.0.1 #1271

Description

@hkuzbyt-fast

CodeConverter Version: 10.0.1
OS: Windows

Error

Microsoft.Build.Exceptions.InvalidProjectFileException: No file format header found.
at Microsoft.Build.Construction.SolutionFile.ParseFileHeader()
at Microsoft.Build.Construction.SolutionFile.ParseSolution()
at Microsoft.Build.Construction.SolutionFile.ParseSolutionFile()
at Microsoft.Build.Construction.SolutionFile.Parse(String solutionFile)
at Microsoft.CodeAnalysis.MSBuild.MSBuildProjectLoader.LoadSolutionInfoAsync(...)
at Microsoft.CodeAnalysis.MSBuild.MSBuildWorkspace.OpenSolutionAsync(...)
at ICSharpCode.CodeConverter.CommandLine.MsBuildWorkspaceConverter.SolutionLoader.AnalyzeSolutionAsync(...) in MsBuildWorkspaceConverter.cs:line 87

Description

Despite issue #1195 being listed as fixed in v10.0.1, converting a VB project using a .slnx
solution file still fails with the above error. The bundled
Microsoft.CodeAnalysis.Workspaces.MSBuild.dll is version 4.14.0 (file version
4.1400.25.26210). MSBuildWorkspace in 4.x tries to parse .slnx as a traditional .sln file
and fails at the file header check — .slnx is XML-based and has no such header.

Root Cause

.slnx support in MSBuildWorkspace.OpenSolutionAsync requires
Microsoft.CodeAnalysis.Workspaces.MSBuild 5.x. The latest stable is 5.3.0.

Proposed Fix

Update CodeConv/CodeConv.csproj (and CodeConverter/CodeConverter.csproj):

  • Microsoft.CodeAnalysis.Workspaces.MSBuild 4.14.0 → 5.3.0
  • Microsoft.CodeAnalysis.CSharp.Workspaces 4.14.0 → 5.3.0
  • Microsoft.CodeAnalysis.VisualBasic.Workspaces 4.14.0 → 5.3.0
  • Microsoft.CodeAnalysis.CSharp.Features 4.14.0 → 5.3.0

References

Activity

  1. GrahamTheCoder commented on Aug 20, 2026

    @GrahamTheCoder
    Member

    Ah, good point. In the visual studio extension (where I presumably tested #1195) the Visual Studio's dll gets used, but in the command line we should use the latest. So just updating the versions in CodeConv.csproj should be sufficient, and allow older versions of Visual Studio (which tend to be useful for people converting legacy vb projects) to continue working for a while.
    But if that's causing any issues then we should just update all to 5.3.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions