I haven't been able to find anything in the official docs of the csproj, but several msbuild issues suggest the intention is to automagically handle xplat paths, and our current csproj using Unix-style directory separators works fine with one exception: the Exec clause for the nunit task runner.
On Windows, the forward slash in $(LibraryPath)/nunitlite-runner.exe seems to be interpreted as a whitespace, and fails when when the command interpreter attempts to execute $(LibraryPath) and not the nunitlite-runner.exe executable inside it.
Changing only this separator to a backslash seems to fix it on Windows, and continue to work on macOS and presumably Linux. Note that name of the output DLL in the same string is unaffected by this, only the name of the executable seems to be.
There seems no benefit in changing all separators in the file to backslashes since msbuild explicitly supports them.
I haven't been able to find anything in the official docs of the
csproj, but severalmsbuildissues suggest the intention is to automagically handle xplat paths, and our current csproj using Unix-style directory separators works fine with one exception: theExecclause for thenunittask runner.On Windows, the forward slash in
$(LibraryPath)/nunitlite-runner.exeseems to be interpreted as a whitespace, and fails when when the command interpreter attempts to execute$(LibraryPath)and not thenunitlite-runner.exeexecutable inside it.Changing only this separator to a backslash seems to fix it on Windows, and continue to work on macOS and presumably Linux. Note that name of the output DLL in the same string is unaffected by this, only the name of the executable seems to be.
There seems no benefit in changing all separators in the file to backslashes since
msbuildexplicitly supports them.