oleg-shilo
commented
1 month ago Hi Thomas, I looked at various paths of implementing this feature and unfortunately, I do not see any viable opinion for that. This is rather an architectural problem.
The whole concept of preserving a script file path for script hosting scenarios is problematic.
- Sometimes the user specifies no script file at all
- Sometimes the script has other imported (secondary) scripts
- Keeping the script paths in some global dictionary means potentially uncontrolled growth of such dictionary
- Looking up script path in the global dictionary needs support for the identity of the script. Currently, it is script content hash. And it is exactly what you do not have - you are trying to discover what script text/file was used to build a specific script assembly.
- Supporting an alternative script identity - assembly, is theoretically possible. But... sometimes the assembly is not physical but in-memory only. Sometimes it is a Roslyn assembly itself (for pure dynamic Rosliyn backed scripts).
Thus the scenario you are asking for cannot be implemented in a managed way. I apologise for asking you to create this enhancement issue.
What you can do is implement it in your app. You can use this "global dictionary" approach you suggested earlier.
Or you can use .NET SymbolProvider to read the source information from the pdb file created for all scripts executed with debug symbols enabled.
rexxitall
If you work with a hosted application the error message shows up with the temporary file name which is not the real name. for debugging purposes its more handy to get the original filename. A workaround is currently to add a comment with the original filename to every code file. You can then load the temporary copy by its temporary filename and try to find this comment.
It might be a enhancement to internally add a dictionary and the functionality to avoid this workaround. So also in a hosted environment the real filename can be obtained.