CallerFilePath relative paths

[ZacharyPatten]

The [CallerFilePath] attribute results in absolute paths.

using System;
using System.Runtime.CompilerServices;
Console.WriteLine(filepath());
string filepath([CallerFilePath] string filePath = default!) => filePath;

// Possible Output:
// C:\Users\MYUSER\source\repos\ConsoleApp1\ConsoleApp1\Program.cs

There should be a way to configure [CallerFilePath] so that it uses relative paths rather than absolute paths.

Yes the string can be manipulated after using [CallerFilePath], but there is currently no way to prevent the absolute path from being included in the compilation, meaning it will be visible via decompilation.

Implementation?

I'm not sure what the best way to implement this feature would be, but here are some ideas without a lot of thought behind them:

Assembly property? _[Expand]

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
    <CallerFilePath>../</CallerFilePath>
  </PropertyGroup>
</Project>

Then [CallerFilePath] parameters for that assembly would be relative to the parent directory of the .csproj file.

Assembly attribute? _[Expand]

[assembly: CallerFilePathRoot("../")]

Then [CallerFilePath] parameters for that assembly would be relative to the parent directory of wherever the attribute is located.

CallerFilePath constructor overload? _[Expand]

using System;
using System.Runtime.CompilerServices;
Console.WriteLine(filepath());
string filepath([CallerFilePath(PathType: CallerFilePathType.RelativeToRepository)] string filePath = default!) => filePath;
public enum CallerFilePathType
{
  Absolute, // how CallerFilePath currently works
  RelativeToProject, // relative to ".csproj/.fsproj/.vbproj" if exists
  RelativeToSolution, // relative to ".sln" if exists
  RelativeToRepository, // relative to ".git" if exists
}

or... new attributes altogether:

• [CallerProjectFilePath]
• [CallerSolutionFilePath]
• etc...

[yaakov-h]

What's the relative file path when the function being called is in a precompiled assembly and/or reference assembly?

[ZacharyPatten]

It doesn't matter where the function is located. The constant being used in the [CallerFilePath] will be located in the dll that is calling the method, and the relative path would always come from the calling code. That is how [CallerFilePath] already works.

As for the possible implementations that I mentioned to allow relative paths...
The "CallerFilePath constructor overload?" option and additional attributes would allow the the method to determine what the path is relative to in the calling code. The other options would allow each assembly to determine it for themselves.

[PathogenDavid]

but there is currently no way to prevent the absolute path from being included in the compilation, meaning it will be visible via decompilation.

If this is your main concern, a project built with Source Link enabled and ContinuousIntegrationBuild set to true will have paths truncated to the root of the repository as a side effect of making the build deterministic.

---

If you don't want to enable Source Link (it only affects your debug symbols so there's not a lot of reason not to), you can manually specify a SourceRoot item and Roslyn will pick that up when ContinuousIntegrationBuild is enabled. For example, adding this to your csproj will remove the path to the project directory:

  <ItemGroup>
    <SourceRoot Include="$(MSBuildThisFileDirectory)" />
  </ItemGroup>

If you don't want to enable ContinuousIntegrationBuild, you can enable just DeterministicSourcePaths instead. (However I would not do this for day-to-day builds, my understanding is it can cause issues with debugging.)

---

As a final alternative, if you want a custom prefix you can specify your own PathMap manually with your own prefix:

<PropertyGroup>
    <PathMap>$(MSBuildThisFileDirectory.Replace(',', ',,').Replace('=', '=='))=/MyCoolProject/</PathMap>
</PropertyGroup>

(PathMap is internally what is getting populated by DeterministicSourcePaths and SourceRoot, you can find the MSBuild logic behind it here. The pathmap option in general is described in the Roslyn command line documentation.)

[ZacharyPatten]

Thanks. I was not aware of Source Link yet. That covers all of the options from an assembly's perspective, but that still doesn't allow the parameter the attribute is defined on to have any say in the matter. There are cases where that would be useful too.

[jnm2]

I don't think the parameter should have any say in the matter. Specifically asking for a full path goes against the principle of a deterministic, reproducible build.

[ZacharyPatten]

Agreed. So perhaps instead of the "Absolute" enum value I mentioned maybe just "Default". And maybe adjust/remove the other enum values I mentioned too, but keep a way to specify project relative paths on the attribute.

[Thaina]

I want to add my voice to support constructor overload of RelativeToProject and RelativeToSolution