-3

I'm attempting to proxy an existing dll that I don't have all the source code to. I'm using a tool I found here:

https://github.com/mavenlin/Dll_Wrapper_Gen

Using it, I was able to create a Visual Studio project and build it successfully. However, when running the original executable, it throws an exception for "badimageFormatException". After getting some unhelpful comments-but-not-answers here on SO in another question, I discovered what I think to be the essential differences between the proxy dll and original.

Using the corflags.exe tool (from VS, also looks like dumpbin has the right features too, but I couldn't figure them out), I get the following output for the original:

C:\Users\jo\fml2>"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\Co
rFlags.exe" fml.dll
Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  3.5.30729.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v1.1.4322
CLR Header: 2.0
PE        : PE32
CorFlags  : 0
ILONLY    : 0
32BIT     : 0
Signed    : 0

If I use the same tool on the proxy dll, I get this:

corflags : error CF008 : The specified file does not have a valid managed header

What do I need to add to my code to make it match that?

John O
  • 4,863
  • 8
  • 45
  • 78
  • It is a mixed-mode .NET assembly, written in Managed C++. It targets .NET 1.1, you need VS2003 to build such an assembly. The part you did not take care of is the managed interface. A decent disassembler like Reflector can decompile it. – Hans Passant Nov 08 '16 at 08:01
  • It's exactly as explained already. Your DLL is unmanaged but the target expects to load a managed DLL. – David Heffernan Nov 08 '16 at 08:42
  • @HansPassant Is there anyway to get VS2005 or 2008 to build this? I have access to both, 2003 might as well be lost in an ancient tomb somewhere. – John O Nov 08 '16 at 14:22
  • 2
    Hmm, you'll have to tone down the rhetoric, David is **always** helpful at SO. We are not often blessed with decent information to produce a helpful comment or answer and it is like pulling teeth to get the OP to volunteer any. You are just not helping us help you. Like you making no mention at all about the host program in which this DLL is used. Pretty likely that it *requires* a .NET 1.1 assembly since it was built targeting 1.1 as well. Have a look-see with a decompiler. – Hans Passant Nov 08 '16 at 14:36
  • There exists a record of his comments on my questions. I don't feel "blessed" by him, and he certainly hasn't helped. He's repeated what I already had in the question myself and added nothing, but insinuated quite alot. As for the host program, it's a retail consumer product that would add nothing to the conversation... it can't be decompiled, at least not with any tools I can afford. – John O Nov 08 '16 at 15:24
  • From what I can tell, the host requires a managed assembly, and you are still supplying a unmanaged DLL. If you want to build a proxy, it stands to reason that it needs to be a managed assembly. Hard to know what else there is to say. – David Heffernan Nov 08 '16 at 15:44
  • The correct answer to my now deleted question: You should use corflags.exe or dumpbin.exe (both included in VS), and these will give you the specific differences between the two dlls. The correct answer to this question would be something like "in the solution configuration, you can select common language runtime and get it matching, but it will still be dependent on the version of the framework VS is building it with". These would be helpful answers. You're simply not being helpful, either with answers, or with comments that could help make the question better. – John O Nov 08 '16 at 15:50
  • Well, I'm not sure I agree, but it sounds like you know what you are doing now. Good luck. I'm glad you've got this sorted now. – David Heffernan Nov 08 '16 at 16:11

1 Answers1

-2

This is only a partial answer, which is frowned upon.

The proxy dll project builds it as a C++ dll, which isn't really within the same environment/framework/platform as the other dll. This causes some complications.

However, with no other changes one can right click on the project from within Visual Studio, the required configuration is on the first panel of the dialog that opens. The panel will be divided into "General" and "Project Defaults", and the sixth line down from that will be "Common Language Runtime support". This will have several options, but for it to come up with no metadata from corflags.exe, this means the "No support" option is selected. That of course needs to be changed.

Getting it to include the correct CLR runtime libraries/support is trickier, and I haven't figured that out yet.

I'm answering my own question because despite the blessings of the regulars, they've failed to do anything other than heckle. I would prefer an authoritative answer from someone who actually knows what they're doing.

John O
  • 4,863
  • 8
  • 45
  • 78