0
votes

There are many questions about "Mixed mode assembly is built against version .. of the runtime and cannot be loaded in the 4.0 runtime",

E.g. Mixed mode assembly is built against version 'v1.1.4322'

but I don't see any discussion of how to find out WHICH referenced dll is the mixed mode assembly that is causing the problem.

This is happening in an upgrade of an old .NET 3.5 WinForms + XNA desktop app with MANY source files, that references a variety of 3rd-party dlls. I can't just remove them one at a time, because then the app won't build at all.

NOTE: the project that gives the "Mixed mode .." error during build is a class library, written in VB.

(Upgrading to .NET 4.5.2, as a step towards moving from 32-bit to 64-bit.)

I haven't successfully gotten rid of the error message, even after adding useLegacyV2RuntimeActivationPolicy="true", but rather than expend more time figuring out why that doesn't work, I'd like to know which dll it is - I suspect I will want to replace the offending library with some newer solution.

2

2 Answers

1
votes

I resolved this as follows.

  1. Visual Studio 2015 - Tools / Options / Projects and Solutions / Build and Run:
    MSBuild project build output verbosity:
    Detailed.

  2. From Output (Build), copy paste all the text into Notepad++. Find very long line with "sgen.exe". This is worthwhile in itself, as it shows all referenced dlls, with their full paths.

  3. Run Command prompt, try variations of that "sgen.exe" line, omitting various /reference ... parameters.

RESULT:
Most references could be included, without causing "mixed mode" error.
All the third-party dlls I had suspected do not cause this error.
Discovered the problem was the Microsoft.DirectX.* dlls!

FIX:
Switch to SharpDX.
Change references from Microsoft.DirectX.Direct3D to SharpDX.Direct3D11 (or SharpDX.DirectX9, etc.)
(I was going to do this later, to go to 64-bits; had not realized I needed to do this just to get to .NET 4.5+)

0
votes

I am hoping there is a more direct way to find more details from the complaining message; but if that is not possible, then one answer is to run something (e.g. Peverify.exe) against all the dlls, and examine the results:

How do I find out if a .NET assembly contains unmanaged code?

RESULT:
Was not helpful.
Most of the dlls appear to be a mix of managed and unmanaged, so this isn't narrowing down the problem. Specifically, this approach is not telling me whether all these mixed dlls are problematic, or only one or a few of them.