You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A lesser known effect of using /embed is that in addition to embedding source files into the PDB it will also embed the target of #line directives as well. For example:
When built with <EmbedAllSources>true</EmbedAllSources> will cause both Program.cs and _example.txt to be embedded into the PDB file and have entries in the document table.
The compiler discovers the file
If it's a relative path then look relative to the file that included it.
Else read the file as specified off of disk.
This feature makes C# code less portable from machine to machine. Essentially anytime a #line directive target is a full path that code cannot be easily ported between machines as a switch to use <EmbedAllSources> will result in the compiler reading the file off of disk at that location. At that point it ceases to be simply an entry in the document table but a physical disk dependency.
This is not a case that can be fixed with /pathmap option. While the target of #line directive does respect /pathmap when writing the entry into the PDB it does not change where the compiler looks on disk for the file. For example if we take the same Program.cs above and compile with a /pathmap entry it will be reflected in the custom document table but the compiler does not look in z:\data for the file.
As more components embrace <EmbedAllSources>true</EmbedAllSources> I worry this will impact the portability of C# builds because they become more dependent on the layout of the machine.
Think there are a few options we could consider for how to resolve this:
Change the code that looks up #line directive targets to respect /pathmap. This is fairly easy to implement but it is a bit of a change to what /pathmap does. Today it only controls how paths are emitted into the PE / PDB, this would cause it to change how paths are ready.
Change the format of /additionalfiles to allow a path to be specified with a file. Example allow for /additionalfiles:example.txt=C:\Users\jarepdar\temp\console\example.txt. All targets of #line should be passed to the compiler as /additionalfiles when /embed is used as they are inputs to the compiler. So this would just be fixing up the location of it a bit.
The text was updated successfully, but these errors were encountered:
jaredpar
changed the title
The /embed option does not respect /pathmap for line directive targets
The /embed option does not allow for portable builds with line directive targets
Aug 22, 2023
This rounds out a few of the corner cases in `#line` directive support.
The one issue that remains is when the user combines `/embed` and `#line` directives with full paths the resulting compilation is not 100% portable between machines. There is simply no way to redirect where the compiler attempts to read the target off of disk hence we're stuck with the original path. Filed [a bug](dotnet/roslyn#69659) with roslyn to track fixing this.
A lesser known effect of using
/embed
is that in addition to embedding source files into the PDB it will also embed the target of#line
directives as well. For example:When built with
<EmbedAllSources>true</EmbedAllSources>
will cause both Program.cs and _example.txt to be embedded into the PDB file and have entries in the document table.The compiler discovers the file
This feature makes C# code less portable from machine to machine. Essentially anytime a
#line
directive target is a full path that code cannot be easily ported between machines as a switch to use<EmbedAllSources>
will result in the compiler reading the file off of disk at that location. At that point it ceases to be simply an entry in the document table but a physical disk dependency.This is not a case that can be fixed with
/pathmap
option. While the target of#line
directive does respect/pathmap
when writing the entry into the PDB it does not change where the compiler looks on disk for the file. For example if we take the same Program.cs above and compile with a/pathmap
entry it will be reflected in the custom document table but the compiler does not look in z:\data for the file.As more components embrace
<EmbedAllSources>true</EmbedAllSources>
I worry this will impact the portability of C# builds because they become more dependent on the layout of the machine.Think there are a few options we could consider for how to resolve this:
#line
directive targets to respect/pathmap
. This is fairly easy to implement but it is a bit of a change to what/pathmap
does. Today it only controls how paths are emitted into the PE / PDB, this would cause it to change how paths are ready./additionalfiles
to allow a path to be specified with a file. Example allow for/additionalfiles:example.txt=C:\Users\jarepdar\temp\console\example.txt
. All targets of#line
should be passed to the compiler as/additionalfiles
when/embed
is used as they are inputs to the compiler. So this would just be fixing up the location of it a bit.The text was updated successfully, but these errors were encountered: