[Feature Request]: Expose the getters of the `SolutionFile.FullName` and `SolutionFile.SolutionFileDirectory` properties

Summary

In the SolutionFile class, the FullName and SolutionFileDirectory properties – which I can see in ILDASM/ILSpy for the Microsoft.Build NuGet package – are marked internal. Nor are they documented on Microsoft Learn. I do not think this is a good thing.

Typically, my experience has been in the past, that when you write a class that parses a file and then exposes the data model of the file, callers of the class should be able to have access to a property(ies) that reveal the fully-qualified pathname on the disk of the file that was parsed to give that object.

When I am working with the SolutionFile class, I would like to be able to read these properties as get-only – obviously, it would not make sense to write to them.

My point is, to make production-ready code, as I am passing a SolutionFile instance around, I want to ensure every so often that the .sln file still exists on the disk, since, in principle, to write bulletproof code, I cannot continue to make that assumption as I proceed with my program.

Thank you for your consideration.

Background and Motivation

I am tasked with writing production-ready software. A best practice is “never assume files on disk always exist in the same spot.” In my code, as I utilize the SolutionFile instance, I would like to be able to implement a check for the existence of the .sln or .slnf file that was parsed to yield the instance in the first place, to ensure that I am not working with the data of a file on the disk that no longer exists.

Proposed Feature

Instead of

public sealed class SolutionFile
{
  /* ... */
  
  internal string FullPath
  {
    get
    {
      return _solutionFile;
    }
    set
    {
      ErrorUtilities.VerifyThrowInternalRooted(value);
      if (value.EndsWith(".slnf", StringComparison.OrdinalIgnoreCase))
      {
        ParseSolutionFilter(value);
        return;
      }
      _solutionFile = value;
      _solutionFilter = null;
      SolutionFileDirectory = Path.GetDirectoryName(_solutionFile);
    }
  }
  
  internal string SolutionFileDirectory { get; set; }

  /* ... */
}

Make the FullName and SolutionFileDirectory properties of the SolutionFile class public, with their setters made internal.

Alternative Designs

Make the FullName and SolutionFileDirectory properties of the SolutionFile class public, with their setters made internal.

[astrohart]

@rainersigwald @danmoseley what about my original PR? #8965 I respectfully request it be merged. As I have stated on its discussion thread, it is my assessment that it would add value to the SolutionFile class for those who consume it in their own projects. A use case for which I have found it useful is opening up LINQPad and using it to manipulate my really large software projects without having to resort to always loading Visual Studio and waiting for umpteen projects to be loaded, but instead just writing a script. For example, let’s suppose I am writing an algorithm to traverse a directory tree that is full of .sln files. Then i can use SolutionFile in my loop – but the catch is, I have to have visibility on which SolutionFile instance corresponds to which .sln file.

I am also working on a Visual Studio extension project called the MultiProjectTemplateWizard the first step of which is displayed below: Figure 1. The Project Selection dialog box of my MultiProjectTemplateWizard extension in development.

This is for those .vstemplate based project templates that, themselves, generate not one but a whole bunch of projects? I came up with this tool to selectively turn off and on, the generation of individual sub-projects. When you use this multiple times in a software system, via the Add New Project wizard in Visual Studio, in a Solution with say, 1600 projects, using DTE to iterate the Solution is more of a performance hit than using this SolutionFile class. It’s about making the extension more scalable.

I am not sure whether there is a need for much banter about a separate, full-fledged Solution parser or about making the same request for 20 years. As I see it, SolutionFile has a very small dependency footprint within the Microsoft.Build NuGet package — I think the SolutionFile class (and friends) is a great jumping off point of what could become a highly useful .sln file parser…so i am advocating strongly for the creation of a Microsoft.Build.Construction NuGet package that basically just takes the src\Build\Construction folder in this project and puts all that code in its own NuGet package – it’s a copy-paste for the MS team. Or there could be much more talk about why it wouldn’t work and why either Microsoft will never do it or what have you – not to make a fine point of it, but we can talk talk talk, or we can do as I suggest, rip the src\Build\Construction folder tree out of this project, do a quick git init, dump into a Microsoft.Build.Construction.nuproj file, and then publish the mofo to the NuGet Gallery! I could do it as a ‘private citizen’ sure, but I think it would behoove MS to do it since you guys are the source.

Then we have a slimmed down NuGet package to use in our VSIX projects and LINQPad scripts instead of DTE.

[jrdodds]

@danmoseley If there is an initiative to build out a common solution parser, I would be interested in contributing.