Calling .NET Rebex SFTP via C++/CLI Dll in Excel/VB6 crashes

0 votes
asked Sep 27, 2011 by IgorJ (200 points)
edited Oct 27, 2013

Hello,

we (as a large company) are evaluating the Rebex SFtp components in our project (in the mean time all needed Rebex licences are being purchased). We have created one simple dll in C++/CLI with CLR Support. This dll exports one simple function, which will be called from vb6 and from excel vba. Everything works so that we are able to use any .NET functionality in that way without having any errors. If we try to use any SFTP functionality and reference Rebex assemblies in the C++/Cli dll our excel vba crashes as well as our vb6 project. If we call the exported function from a compled vb6 exe or from .net everything also works fine. So, the main problem is our vba macro in excel.

What could be the reason of the error? Any trial checks in the rebex dlls?

I have also prepared a small application to demonstrate the error. I could upload it if it helps.

Thanks in advance.

Best regards, Igor

Applies to: Rebex SFTP
commented Sep 27, 2011 by Lukas Pokorny (100,670 points)
edited Sep 27, 2011

Hello, is there any error message? It might be the trial check - indirectly calling Rebex assemblies from Excel an VBA isn't a tested or common scenario. A sample application demonstrating the error should make it possible to tell what is going on. Also, consider using Sftp object's LogWriter to create a log (http://www.rebex.net/kb/logging.aspx) - if it is a trial check error, the log would clearly state it.

commented Sep 27, 2011 by IgorJ (200 points)
edited Sep 27, 2011

Hi, there is no error message. It crashes if I only create the Sftp object. How can I upload the sample application?

commented Sep 27, 2011 by IgorJ (200 points)
edited Sep 27, 2011

If I try to debug this crash with an external debugger I get: FileNotFoundException. The file or Assembly "Rebex.Net.Sftp, Version=2.0.4086.0, Culture=neutral, PublicKeyToken=1c4638788972655d or any dependency can not be loaded. All 4 Rebex dlls are present in the directory.

commented Sep 27, 2011 by IgorJ (200 points)
edited Sep 27, 2011

ok, it seems that is a general microsoft problem.. any statically linked .net assembly failes to be loaded in C++CLI in that case...

commented Sep 29, 2011 by Lukas Pokorny (100,670 points)
edited Sep 29, 2011

Have you tried placing Rebex DLLs into Global Assembly Cache? That might do the trick.

commented Sep 29, 2011 by IgorJ (200 points)
edited Sep 29, 2011

Thanks, it helps! :) But unfortunately this is not the way out of this problem :( We can not put 4 Rebex assemblies into the gac on 5000 client computers. The existing assemblies must be loaded from the current directory. Is there any way out? I know that this is a microsoft problem, but may be you know the solution?

1 Answer

0 votes
answered Sep 30, 2011 by IgorJ (200 points)
edited Sep 30, 2011

I've found the solution by myself. :) The problem is that the rebex assembly can not be found (?) by the .NET Loader, even if it exists in the same directory with the excel sheet (!!). It is possible to sign the rebex assembly and place it into the GAC to solve the problem (Thanks Lukas Pokorny). But the better solution would be to use the AppDomain::CurrentDomain->AssemblyResolve event to help to the .NET Loader to find the missing assembly.

commented Sep 30, 2011 by Lukas Pokorny (100,670 points)
edited Sep 30, 2011

Thanks for letting us know about this solution, we have not been aware of this event! I was about to suggest loading the assembly explicitly by calling Assembly.LoadFrom, but your solution is much better.

...