Absolute symbols path in PEHeaders #967

New issue

Open

opened 2025-03-12 10:13:26 -05:00 by simonferquel · 0 comments

simonferquel commented

2025-03-12 10:13:26 -05:00

(Migrated from github.com)

Consider the following code:

assemblyDefinition.Write(outputAssemblyPath, new WriterParameters
{
  WriteSymbols = true,
  SymbolWriterProvider = new PortablePdbWriterProvider(),
}

If outputAssemblyPath is an absolute path, the symbol path written in the dll PE Headers will be absolute as well.
This can lead to confusion of the debugger if somehow the assembly is loaded from a different path.
Also, if the assembly is loaded with AssemblyLoadContext.LoadFromStream to prevent the runtime to lock the assembly file, an attached debugger will likely lock the pdb file as it will still be able to find it (as the PE Header has the full path information) - while the expected behavior would have been for the debugger to pick the symbols information from the symbols stream passed to the AssemblyLoadContext.

In Unity CoreCLR editor context we worked around that by writing the assembly to a custom stream, but it would be nicer if the PE header would be filled with a path relative to the assembly output directory - the same way csc seems to behave.

Consider the following code: ``` assemblyDefinition.Write(outputAssemblyPath, new WriterParameters { WriteSymbols = true, SymbolWriterProvider = new PortablePdbWriterProvider(), } ``` If `outputAssemblyPath` is an absolute path, the symbol path written in the dll PE Headers will be absolute as well. This can lead to confusion of the debugger if somehow the assembly is loaded from a different path. Also, if the assembly is loaded with `AssemblyLoadContext.LoadFromStream` to prevent the runtime to lock the assembly file, an attached debugger will likely lock the pdb file as it will still be able to find it (as the PE Header has the full path information) - while the expected behavior would have been for the debugger to pick the symbols information from the symbols stream passed to the AssemblyLoadContext. In Unity CoreCLR editor context we worked around that by writing the assembly to a custom stream, but it would be nicer if the PE header would be filled with a path relative to the assembly output directory - the same way csc seems to behave.