Patrice, Thank you for the clarification, i'll try just that and post back with my results.
Thanks! Amit Ben Shahar 2010/4/24 Patrice Guérin <guer...@magic.fr> > Amit, > No, I don't misunderstand you. > The (real) example I gave is in fact similar (I think so) > In a classic Win32 application, when mixing different compiler setting, > different compilers between application and the OpenSSL dll and use some > functions involving FILE* parameters, applink is used to resolve the crash. > The actions to do are : > Add the snippet applink.c or include the file ONLY ONCE in the main > project. > I guess the same can be done with .NET application... > > When running the application: > OpenSSL dll will search the application module for the OPENSSL_Applink() > function. > If it doesn't find it, OpenSLL exits with a message. > > I've never done any application in .NET, just this dll. > If you take OpenSSL as a pre-built binary, it's probably a Win32 dll (so > unmanaged), and if you add the snippet in your .NET application and OpenSSL > does not resolve OPENSSL_Applink(), maybe it's because OPENSSL_Applink() is > considered as managed code. > So, maybe, adding #pragma unmanaged at the beginning of applink.c can solve > your problem. > > You can use a tool called "dependancy walker" that show the exe/dlls entry > points and used dlls > http://www.dependencywalker.com/ > Just see if OPENSSL_Applink is present or not... > > > Patrice. > > > Amit Ben Shahar a écrit : > > Would anyone happen to know how i can eliminate the requirement of the > applink implementation? why would we actually need it? > > Take a look at the other thread I gave you (Win32 OPENSSL_USE_APPLINK > usage) for further explanations... and the FAQ about Win32 applications that > crash. > > > > Amit Ben Shahar > > On Sat, Apr 24, 2010 at 13:25, Amit Ben Shahar <amit.b...@gmail.com>wrote: > >> Patrice, >> >> I think your have misunderstood me (or i did you), >> From what you wrote i gather that you are talking about using .Net dlls in >> native applications, which is not the case here, i need it the other way >> around. >> Our server is a .Net application and so we'd either have to somehow get >> the Uplink/applink to recognize a method in the .Net assembly (i understood >> that it cannot be in an adjacent dll) OR to completely eliminate the Applink >> usage. >> >> If i misunderstood please correct me :) >> >> Amit Ben Shahar >> VP R&D >> ISQ Technologies >> (+972) 545-592-934 >> a...@isqgroup.net >> www.isqgroup.net >> >> >> 2010/4/24 Patrice Guérin <guer...@magic.fr> >> >> Hello Amit, >>> >>> Maybe you can explore the "IJW" way... >>> I use Visual C++ 6 to build my aWin32 pplications and I had to use some >>> .NET Crypto functions such as RSA to communicate with a customer. >>> I've used Visual C++ 2005 Express, in which I add the Win32 environment >>> (from a platform SDK. Express don't have Win32 environment by default...) to >>> compile >>> the .NET dll and use it from a win32 dll. >>> The trick is to use #pragma managed / #pragma unmanaged as appropriate >>> >>> cryptodotnet.h : the include file for win32/.NET >>> >>> #ifndef CRYPTDOTNET_EXPORT >>> #define CRYPTDOTNET_EXPORT __declspec( dllimport ) >>> #endif >>> >>> #define CRYPTDOTNET_VERSION "1.0.0" >>> #define CRYPTDOTNET_DATE "20100228" >>> >>> class CRYPTDOTNET_EXPORT CryptDotNet >>> { >>> public: >>> CryptDotNet() {}; >>> virtual ~CryptDotNet() {}; >>> int RSAEncrypt( const char* XmlPublicKey, const unsigned char* Data, >>> const int DataLength, char* Base64EncryptBuffer, int* >>> Base64EncryptBufferLength ); >>> ... >>> }; >>> >>> cryptodotnet.cpp : compiled with VC++2005 >>> >>> #define CRYPTDOTNET_EXPORT __declspec(dllexport) >>> #pragma unmanaged >>> #include "cryptdotnet.h" >>> #include <memory.h> >>> #include <string.h> >>> #pragma managed >>> >>> class CryptDotNetManaged >>> { >>> public: >>> CryptDotNetManaged() {}; >>> ~CryptDotNetManaged() {}; >>> int RSAEncrypt( const char* XmlPublicKey, const unsigned char* Data, >>> const int DataLength, char* Base64EncryptBuffer, int* >>> Base64EncryptBufferLength ); >>> }; >>> >>> //Unmanaged interface >>> int CryptDotNet::RSAEncrypt( const char* XmlPublicKey, const unsigned char* >>> Data, const int DataLength, char* Base64EncryptBuffer, int* >>> Base64EncryptBufferLength ) >>> // >>> { >>> CryptDotNetManaged c; >>> return c.RSAEncrypt( XmlPublicKey, Data, DataLength, >>> Base64EncryptBuffer, Base64EncryptBufferLength ); >>> } >>> // Managed part >>> #pragma managed >>> using namespace System; >>> ... >>> int CryptDotNetManaged::RSAEncrypt( .... ) >>> { ... }; >>> >>> >>> This works very well. >>> In your case, maybe the applink.c should be considered as unmanaged code. >>> >>> some references for inspiration... >>> http://ondotnet.com/pub/a/dotnet/2003/01/13/intromcpp.html >>> >>> http://www.techheadbrothers.com/Articles.aspx/integrez-code-cplusplus-natif-applications-dotnet-page-1(sorry... >>> in french...) >>> >>> and finally the thread "Win32 OPENSSL_USE_APPLINK usage" in OpenSSL-dev >>> >>> Hope this helps. >>> Patrice. >>> >>> Amit Ben Shahar a écrit : >>> >>> On Fri, Apr 23, 2010 at 21:35, James Mansion < >>> ja...@mansionfamily.plus.com> wrote: >>> >>>> Amit Ben Shahar wrote: >>>> >>>>> One of the crucial ingredients is ssl using OpenSsl. but we are >>>>> encountering a problem with the 'no OPENSSL_Applink' error. >>>>> as this is a .Net project, there is no way (i can think of) to compile >>>>> with the applink.c file. >>>>> >>>> 1) Why is that crucial? Microsoft provide crypto support on Windows, >>>> albeit with a different interface. What's wrong with >>>> System.Net.Security.SslStream? >>>> >>>> >>> The .Net.Security.SslStream is not working in asynchronous calls, meaning >>> we'd have to implement it in a thread-per-connection paradigm, which is >>> obviously not an option. >>> >>> >>>> 2) Why can't you 'compile with the applink.c file'? You need a talk to >>>> it through p/invoke - you may need to write another glue DLL to do this. >>>> If >>>> you can locate an OpenSSL implementation that has been wrapped as a >>>> free-threaded COM service, you might find things easier if you don't know >>>> how to write such glue. You could try looking in Mono's runtime, too, >>>> which >>>> I suspect delegates to OpenSsl (tho I haven't checked). >>> >>> >>> As far as i understood it, openSsl looks for the applink implementation >>> in the actual application and not in dlls, but i could have misread that, >>> anyhow i'm not sure i would know how to do that, can you maybe directly to >>> such an implmentation (free-threaded COM) ? >>> - in the meantime i'll try checking in Mono, though i've never ever >>> looked at it yet. maybe i'll get lucky ;) >>> >>> thanks >>> >>> >> >
