Feature Request: New Language Keyword 'staticfile' or 'projfile'

[Huntk23]

This request is mostly for convenience, maybe not as convenient and helpful as nameof.

Has a keyword ever been proposed to return a project files relative or absolute path? I would like to see a new keyword added maybe named staticfile() or projfile() and would be used in the below case:

Console.WriteLine(staticfile(appsettings.json));
// Output: ..\Folder\Data\appsettings.json

This would avoid:

string path = Path.Combine(Environment.CurrentDirectory, "Data\", "appsettings.json");
// Output: <Drive>:\users\username\Folder\Data\appsettings.json

This avoids manipulating strings and possibly renamed files. So if a file get renamed within the IDE, it can recursively update files that had the staticfile keyword wrapped on the old named file.

Thoughts?

[HaloFour]

I don't think that this really belongs as a part of the language specification. The compiler knows nothing about the project structure and certainly nothing about non-C# files intended to support the project.

For this I might prefer a tool that can run as a part of the build that would output an internal class containing properties that represent the project structure and other properties.

[MgSam]

You could easily do this with a T4 file and Visual Studio macros. Of course, if you're not using Visual Studio you'd have to find another solution that involves the build agent.

[Huntk23]

@HaloFour How does the compiler not know about project files? I thought you can specify which files are embedded resources, files to include for compile, etc. Perhaps I misunderstood that feature? I thought that those files become visible for the compiler.

Though I also agree that it would be interesting to see a tool that can output an internal class containing helpful project properties.

[tannergooding]

The compiler has no knowledge of the project system that manages the files (it doesn't know what a sln or csproj is). The compiler only knows what is passed into it.

For some files, such as resx, the compiler doesn't get the file itself and instead gets a *.resources file that is produced by passing the resx into a separate tool (which is handled by the build manager, generally msbuild).

[tannergooding]

Also, returning absolute paths would likely be a non-starter. This would prevent a compiled-app from being portable (couldn't ever use the keyword in a program where you could potentially run on Linux/Mac, if it was compiled on Windows).

Returning relative paths also has issues. It could potentially break in certain cross-platform scenarios (where the path-separator character was different) or even break when used with network paths.

[Huntk23]

@tannergooding Thanks for more clarification of the compilers visibility.

I figured it would be a cross platform concern but also figured that something could be done to handle those situations.

Well I think I have enough information to understand that this is out of scope for language specification.

[tannergooding]

I could imagine writing a simple helper method in the form of string staticfile(string) that does the Path.Combine logic and additionally writing a simple analyzer that validates the input to the helper method exists on disk.

You could also do something like @HaloFour suggested and dynamically generate a source file that exposes the project system structure as properties/etc (this could be done as an MSBuild task).

[henriksen]

I'd make an extension method on string:
"appsettings.json".StaticFile() that returns a runtime and cross-platform compatible absolute path.

[Huntk23]

@HaloFour suggestion is, in my opinion, the preferred route.

The problem with an extension method or string staticfile(string). It will tell me the files do not exist at run time.

I was proposing more of a solution that the compilation could potentially break and throw an error because the file no longer existed within the project or known build context.