SLaks/VSEmbed

ReflectionTypeLoadException

xen2 opened this issue · 3 comments

xen2 commented

When trying the demo app, I had a ReflectionTypeLoadException.

Its inner exceptions are:

+       [0] {"Method 'GetProcessor' in type 'VSEmbed.Roslyn.Dev14KeyProcessorProvider' from assembly 'VSEmbed.Roslyn, Version=1.6.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.":"VSEmbed.Roslyn.Dev14KeyProcessorProvider"}  System.Exception {System.TypeLoadException}
+       [1] {"Method 'GetProcessor' in type 'VSEmbed.Roslyn.RoslynKeyProcessorProvider' from assembly 'VSEmbed.Roslyn, Version=1.6.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.":"VSEmbed.Roslyn.RoslynKeyProcessorProvider"}    System.Exception {System.TypeLoadException}

It seems to be due to GetProcessor having a IWpfTextView parameter, and since VSEmbed assembly uses Microsoft.VisualStudio.Text.UI.Wpf from VS11 while VSEmbed.Roslyn assembly uses Microsoft.VisualStudio.Text.UI.Wpf from VS14.

I can work around it by replacing all VS references in VSEmbed and VSEmbed.DemoApp to VS14 one.
It happened on two different PC having both VS11 and VS14 installed.

niwrA commented

Same issue here.

niwrA commented

@xen2, could you perhaps detail your fixes? I'm having trouble getting the references right ...

SLaks commented

Yes; this is not a simple problem.

The problem is that if the GAC has an assembly that exactly matches the one it tries to load (the one that VsEmbed itself is built against), .Net will completely bypass AssemblyResolve, leaving me no way to hook it and force the right assembly.

I think you can fix this by adding an App.exe.config (to your executable project) that redirects v11 of all of these assemblies to v14. However, that will still cause issues if you try to run against v15.

I've fixed a similar issue in the past by rewriting reference assemblies (the ones that VsEmbed itself builds against) to have a non-existent version number, so that they can never appear in the GAC.