LegacyWrapper has stopped working

[MiroljubA]

Hi. I am having a problem running a 32bit c++ dll in 64 .net app. This dll is itself wrapper around a small Usb management Win32_api dll however there seems to be a problem with loading my dll. I have given the WrapperClient full path to dll, tried giving the function name with a classname ("myClass::NameOfTheFunction") and without ("NameOfTheFunction"). Function is static and takes no arguments (new object[] { }). Still client.Invoke gives me this error. Any help would be usefull. Thanks!

Problem signature: Problem Event Name: CLR20r3 Problem Signature 01: Codefoundry.LegacyWrapper.exe Problem Signature 02: 1.0.1.0 Problem Signature 03: 560d9972 Problem Signature 04: mscorlib Problem Signature 05: 4.6.1055.0 Problem Signature 06: 563c0eac Problem Signature 07: 40fd Problem Signature 08: 0 Problem Signature 09: System.BadImageFormatException OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 1033 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

[zalintyre]

Hi, it seems like you have compiled the Legacy Wrapper for yourself. If so, please ensure that the LegacyWrapper project is compiled as 32bit (not AnyCPU) to match your C++ dll.

[MiroljubA]

Hello dsfranzi, thanks for the quick reply.

The problem above was with the nugget package of Legacy.Wrapper. I did try to manually build your example, with LegacyWrapper built in x86 and the others (Client and Test) in x64 however then I get the crash message below at Process.Start ("Codefoundry.LegacyWrapper.exe", token);. This was in Win7 x64

Problem Event Name: APPCRASH Application Name: Codefoundry.LegacyWrapper.exe Application Version: 1.0.1.0 Application Timestamp: 584fbbf8 Fault Module Name: KERNELBASE.dll Fault Module Version: 6.1.7601.18015 Fault Module Timestamp: 50b83c8a Exception Code: e0434352 Exception Offset: 0000c41f OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 1033 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

[MiroljubA]

In windows10 Legacy.Wrapper doesn't crash but the program just waits at _pipe.Connect();

[rjm2k]

Thanks for this project, I wonder if the issue above is the same as one I found in that the caller of your client library needs to be compiled for AnyCpu as it causes a deserialisation issue in the 32 bit exe host otherwise, my library which called the client was compiled to 64bit so failed with the badimageformat exception in the exe. Additionally, it seems the library isn't setup to return reference params to the caller, I assume there is no reason this can't be done and that DynamicInvoke can and does return ref param changes?

[zalintyre]

@MiroljubA can you post some of your code calling the dll?

[zalintyre]

@rjm2k I'll try to include support for ref params.

[zalintyre]

I improved the error handling of the wrapper exe, so that exceptions thrown should be more detailed now. @MiroljubA if there are still unrelated exceptions, feel free to post them here.

Also, ref parameters are possible now, the values in your passed parameters array will get updated.

[rjm2k]

awesome thanks, I'll try to check it out today and replace my local version with your updates.

Any idea how loading the lib each time affects internal state of any dll loaded? I was wondering it it would be better to create one WrapperClient per library to be called and passing the library name into the constructor instead of every time into invoke, that way a library can be loaded once, used and then disposed when finished.

[zalintyre]

I think loading the DLL only once is a good idea. I'll think of a solution that won't break the exising API.

[zalintyre]

@rjm2k please have a look at LegacyWrapper 2.0 ;) I think this issue is solved now, but feel free to open a new one if you have more suggestions or encounter any problems.

[rjm2k]

Yes already found it thanks, I can confirm that ref Param's and single load of the DLL work perfectly thanks. Just a comment to others that they still might have to compile the client of your library as msil but I haven't verified that after you introduced the common library.