PerfView cannot load symbols with a path > 250 chars

This is a long standing issue and I would have thought that this is already solved.
When trying to make it work I did find that commit 5f738b85d44f43240ec00e45a81a1a1576224fa5 made matters worse where
long path handling is explicitely disabled via dirty reflection hacks.
The container symbol resolution is a corner case I think where there are other ways to detect if you are running inside a container.
The general approach should be to allow long path names.
To make it work PerfView needs

• Since it is targetting .NET 4.0 an extra appsetting

<runtime>   
      <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false;Switch.System.IO.BlockLongPaths=false" /> 
</runtime>

• An application manifest to enable native long path support

<?xml version="1.0" encoding="utf-8"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
  <assemblyIdentity version="1.0.0.0" name="MyApplication.app"/>
  <application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
      **<longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>**
    </windowsSettings>
  </application>

• On the machine where it runs long path names must be enabled

See blog post https://docs.microsoft.com/en-us/archive/blogs/jeremykuhne/net-4-6-2-and-long-paths-on-windows-10 for the full details.

Is this on the list or am I the only one loading symbols with long path names?

Start with PerfView's application configuration and manifest, then compare the requested .NET 4.0 AppContext switches and Windows long-path support with the current setup. Done means symbol paths over 250 characters load on supported machines, while the container scenario remains handled; use the linked long-path guidance for validation.