Question

I have a .NET 4.0 32 bit (x86) desktop application with the following files, one of which is a legacy unmanaged library called from a wrapper lib written in managed c++.

1. Application.exe (C#, .net 4)
2. Library.dll (C#, .net 4)
3. UnmanagedWrapper.dll (managed c++)
4. Unmanaged.dll (c)

The files 1 and 2 are built by a VS 2010 solution. The corflags for these look as follows:

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32
CorFlags  : 3
ILONLY    : 1
32BIT     : 1
Signed    : 0

The unmanaged wrapper library was originally built with VS 2008, like this:

Version   : v2.0.50727
CLR Header: 2.5
PE        : PE32
CorFlags  : 16
ILONLY    : 0
32BIT     : 0
Signed    : 0

In this configuration, it worked without problems. Then I migrated the unmanaged wrapper project to be built in VS 2010 which gives .NET 4 as target by default:

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32
CorFlags  : 16
ILONLY    : 0
32BIT     : 0
Signed    : 0

In a section of code inside Library.dll I use Assembly.GetExecutingAssembly().GetTypes() to find types implementing a certain interface inside the Library. Since the library references the unmanaged wrapper, it will be loaded at this point.
Running this on a number of machines (All Win 7 Pro x64 machines) I get varying results:
On a few machines it throws a ReflectionTypeLoadException complaining that UnmanagedWrapper.dll or one of its dependencies can’t be loaded.

It works perfectly on other machines. What could be the difference between the machines where it works regardless of whether the wrapper lib is 2.0 or 4.0, and those machines where it only works if the wrapper is 2.0? The only clue I have so far is that
machines with VS 2010 seem to work, whereas machines with only a .NET (4.0.30319) install will see the exception. What should that be telling me?

Answer 1

In such cases where the applications doesn’t work where Visual Studio is installed, occasionally the solution is that you need to install Visual Studio Runtime. Try installing either Microsoft Visual C++ 2008 Redistributable Package (x86) or Microsoft Visual C++ 2010 Redistributable Package (x86) and if it works make sure its part of your deployment strategy.