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
<mailto: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 <mailto:a...@isqgroup.net>
www.isqgroup.net <http://www.isqgroup.net>
2010/4/24 Patrice Guérin <guer...@magic.fr <mailto: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
<mailto: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
