KSPCommon.Props: Don't depend on $(SolutionDir) and $(SolutionName) for default property values (they don't exist if you don't have a sln file)

[JonnyOThan]

we use these to set default values for a few things, but we should probably find alternatives for someone who might not be using VS.

Proposal:

Use $(SolutionDir) if it exists, but if not then fall back to the current file location.

[xavier2910]

When this gets fixed, the linux setup wiki page will need to be updated accordingly.

It also contains a simple workaround (setting $(RepoRoot) and $(BinariesOutputRelativePath) manually).

[Twinki14]

Where specifically is this an issue? VSCode users?

$(SolutionDir) is a MSBuild macro, it shouldn't be something Visual Studio only provides, at least MSBuild documentation seems to indicate that. I can certainly confirm I don't see that behavior in Rider.

I'll also ask, do we really need to use SolutionDir?

Just going over how I see it being used,

• https://github.com/KSPModdingLibs/KSPBuildTools/blob/2a132490acdebe5f22a9cdc246109afe96e632ff/KSPCommon.props#L45C1-L50C118 Wouldn't it be better if this was handled by the plugins csproj instead? I don't think we should be trying to automatically import props, that should be pretty hands off in my opinion to give the developer using KSBuildingTools .props and .targets the most control.

• KSPBuildTools/KSPCommon.props

  Line 65 in 2a13249

  <KSPRootCandidate Include="$(SolutionDir)KSP" source="solution directory"/>

  This looks to be used for looking for a KSP install, which could be simply not supported in places where the SolutionDir macro can't find relevant metadata

[xavier2910]

It's an issue for anyone who doesn't have a .sln file. But doing a little poking around, it looks like VSCode can actually produce a .sln file with the right extensions (namely, the C# Dev Kit). So this may be less of a problem. The thing is, the C# Dev Kit (understandably) requires .NET to be installed; KSP is using an old version of .NET that does not work on non-Windows systems (you can run it via mono, but the C# Dev Kit doesn't recognize the mono stuff, even tho it builds fine). I'll have to try and see if a newer, cross-platform version of .NET could work just for creating the .sln file, or if the extension can do it without .NET explicitly installed.

[Twinki14]

Just use the dotnet cli directly.

dotnet new sln --name MySolution
dotnet sln add plugin.csproj

[xavier2910]

Ok, tried that out and it worked. These two msbuild variables are indeed set now that I have a .sln file (when running dotnet build rather than explicitly invoking msbuild as I had been doing before).

[JonnyOThan]

Still, we'd get greater flexibility if we didn't depend on these properties and we don't really need them. We can still use them as part of building up defaults when nothing is specified.

[drewcassidy]

What is the purpose of $(SolutionDir)$(SolutionName).props, anyways? is that still used? Figured it out, looked at KerbalVR, its for setting properties for a whole solution. fd3c5f0 adds a check that SolutionDir is set before trying to import it, but leaves it in place

[JonnyOThan]

I think maybe I wasn't aware of Directory.build.props when I set that up - is that a better option?