Roslyn: Internal error in C# compiler when using Assembly.LoadFrom in IIS and debugging

[cphillips83]

I'm not sure if this belongs here as it seems to be related to ASP.NET (only when debugging).

Version Used:
.NET 4.6.1 + (VS2015 or VS2017) + (IIS OR IISExpress)

Steps to Reproduce:
Just a note this would be consider a standard plugin manager design. One project holds the interfaces to a IPlugin, another implements those interfaces and a 3rd (ASP.NET project) consumes and loads the implemented plugins via Assembly.LoadFrom

1. Create a DLL project for 4.6.1 and add a simple IPlugin interface
2. Create an ASP.NET 4.6.1 web application and reference the first DLL project
3. Create a DLL project that references the first DLL project and implements the IPlugin interface
4. In the Global.asax use Assembly.LoadFrom to load the 2nd DLL project and to create and instance of the IPlugin interface.

Expected Behavior:
The debugger/autos/immediate window should all be able to correctly display the type information and interact with the interface.

Actual Behavior:
You'll get a few different errors depending on what you do, if you simply try to dump the value in immediate window you'll usually get a Internal error in the C# compiler. You might also get

'q' threw an exception of type 'System.IO.FileNotFoundException'
    Data: {System.Collections.ListDictionaryInternal}
    FileName: null
    FusionLog: null
    HResult: -2147024894
    HelpLink: null
    InnerException: null
    Message: "Cannot load assembly 'C:\\Windows\\Microsoft.NET\\Framework64\\v4.0.30319\\Temporary ASP.NET Files\\root\\eb172f74\\782fb1a7\\assembly\\dl3\\cd583d72\\0d6f0d66_e1c4d201\\XYZ.dll'."
    Source: null
    StackTrace: null
    TargetSite: null

Also this is in the output window

'w3wp.exe' (CLR v4.0.30319: /LM/W3SVC/2/ROOT-1-131383879021625672): Loaded 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\eb172f74\782fb1a7\assembly\dl3\b900e8c4\0d6f0d66_e1c4d201\XYZ.dll'. Symbols loaded.

Notes
This works correctly if you instead use a console project rather than IIS or IISExpress.

Enabling Use Managed Compatibility Mode from the link below resolves the issues, but disables other features.
http://stackoverflow.com/questions/34545354/internal-error-in-the-expression-evaluator

[GerjanOnline]

I just had the exact same problem. Enabling Use Managed Compatibility Mode and Use the legacy C# and VB expression evaluators "fixed" it

[aplocher]

It's unfortunate that this was reported over a year ago and nothing has been done to fix it. My team and I are now running into this issue and I guess the only option is for me to inform each and every one of them that they need to check this checkbox in the settings and undoubtedly lose functionality in VS (like the ability to use certain third party visualizers, as I just discovered tonight)?

[jhudler]

Any updates on this?

Additional / reinforcement info: For me this happens anytime I need to attach to a running process or when the working directory is not the same from where the binaries/pdb are located. PS: I develop desktop/winforms applications.

[brinkdinges]

I have this issue after I call Assembly.LoadFile on a copy (of an already loaded assembly) in another directory. I develop desktop WPF apps in VS2019. After turning on Use Managed Compatibility Mode and Use the legacy C# and VB expression evaluators (which has been removed in VS2019, but you can turn it on in the settings file) it doesn't hit my breakpoints anymore.

[JL-Manning]

I used GerjanOnline's solution and it worked for me also!!! Not sure, but I think my VS2019 just updated itself in the last day or two. These links can help:
Link #1: https://docs.microsoft.com/en-us/visualstudio/debugger/general-debugging-options-dialog-box?view=vs-2019
Link #2: https://stackoverflow.com/questions/62104151/legacy-c-sharp-and-vb-expression-evaluators-in-visual-studio-2019-16-5