I think I'm in over my head here, but wondering if anyone can point me in the right direction. I've created a C# class library (dll) in Visual Studio 2010 to interact with a MS SQL server. It works fine when I call it from another C# program. However, when I try and call it from an AHK script I get the "Error level = -4" indicating the function can't be found.
Here's my C# code:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.SqlClient;
using System.Data;
namespace AHK_Interface
{
public class AHK_Interface
{
public string TrackUsage()
{
try
{
SqlConnection ahk_connection = new SqlConnection("Data Source=SQLServer;Initial Catalog=AHK;Integrated Security=True;Connect Timeout=15;Encrypt=False;TrustServerCertificate=False");
SqlCommand cmd;
ahk_connection.Open();
cmd = new SqlCommand("INSERT INTO AHK_USAGE(username,script_version,notes) VALUES ('TEST user','1.01','TEST NOTES')",ahk_connection);
cmd.Connection = ahk_connection;
cmd.ExecuteNonQuery();
string success_ind = "success!";
ahk_connection.Close();
return success_ind;
}
catch (Exception e)
{
string success_ind = e.Message;
return success_ind;
}
}
}
}
I went into regasm.exe and registered the DLL successfully.
Here's my Autohotkey code where I'm trying to call it. All this method does is perform and insert statement and return a success/no success string so I didn't think I'd need to pass any parameters to it.
SetWorkingDir %A_ScriptDir%
DllCall("LoadLibrary", "str", "AHK_Interface.dll")
msgbox %ErrorLevel% ;good at this point
success_ind := DllCall("AHK_Interface\TrackUsage") ;trying to call my method "TrackUsage" above
MsgBox, %success_ind% %ErrorLevel% ;gives error level of -4 here
ExitApp
Use the NuGet package UnmanagedExports to mark the method as callable from a non-.Net external program. Use DllCall inside AHK to call the function.
A little bit late but I had the same problem and by using the suggested comments, it works.
This is how I did it:
1) Make the C# class static.
2) Use the 'UnmanagedExports' as already pointed out.
3) Make sure to use the DllExport name in the dll call, like this:
[DllExport("add", CallingConvention = CallingConvention.Cdecl)]
public static string TrackUsage()
{...}
4) Then call the dll by:
dataVariable := DllCall("AHK_Interface\add", "Cdecl Str")
DllCall has no concept of .NET types or methods, and only works with exported native windows functions.
You have three options:
1) Build a native assembly that hosts the .NET CLR to call your managed code.
2) Use CLR for AutoHotkey instead of building your own CLR hosting framework.
3) Alternatively, call AHK from .NET by referencing AutoHotkey.dll in your C# application and call ahktextdll.
Ah, one thing I notice is this:
public class AHK_Interface
Your class is public but not static - that means you have to create a new instance of the class in order to use it. Try adding static to your class and see if it helps.
Also, in your dll, add a messagebox popup for any error that might happen - maybe put this in your try/catch statement.
Also, you might like to take a look at this thread from Autohotkey.net - it is called .NET Framework Interop.
Make sure that if you are on 64-bit architecture, you are targeting x64 in your build configuration. If it is set to ANY it will return -4.
Related
I have an old line of c# code that looks basically like this:
foo.set_Parent(parent);
It has compiled fine for years. Now in VS2015 I get the error:
CS0571 'Foo.Parent.set': cannot explicitly call operator or accessor
So I can rewrite the line as:
foo.Parent=parent;
This builds fine in VS2015, but in VS2013 it gives the error:
'Foo.Parent' is not supported by the language; try directly calling
accessor methods 'Foo.get_Parent()' or Foo.set_Parent(Foo)'
So the simple fix is to simply ifdef these two lines based upon which version of the compiler is running. But how do you detect which version of the compiler is executing?
And for the record, no, I can't just dictate that everyone on the team simultaneously upgrades to VS2015.
Additional info -
For everyone smelling a rat, I'll go ahead and drag out the ugly truth, although I don't think it will change much of anything. The class Foo is from an ancient Borland assembly that is all bound up in Delphi (and yes, we're migrating away but not there yet). So the actual code, that compiles up to VS2013, looks like this:
using Borland.Vcl;
using RepGen;
using SnapReportsForm;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.InteropServices;
namespace MigrantCOM {
[ComVisible(true)]
[Guid("48245BA3-736B-4F98-BDC5-AD86F77E39F4")]
[ProgId("MigrantCOM.Exports")]
[ClassInterface(ClassInterfaceType.AutoDual)]
public class MigrantCLRExports { // : MarshalByRefObject
public string Test(string s) { return s+s; }
}
[ComVisible(true)]
[Guid("1154D364-B588-4C31-88B9-141072303117")]
[ProgId("MigrantCOM.SnapRepCOM")]
[ClassInterface(ClassInterfaceType.AutoDual)]
public class SnapRepCOM {
TRepGen repGen;
TStringList snapRefs=new TStringList();
TForm parent=new TForm(null);
TMemo designerMemo;
List<TReference> references=new List<TReference>();
TRunAsSnapContext runAsSnapContext=new TRunAsSnapContext();
public SnapRepCOM() {
designerMemo=new TMemo(parent); designerMemo.set_Parent(parent);
...
}
So the class being instantiated is Borland.Vcl.TMemo which is part of the old Delphi assembly.
I'm leaving this as an answer, linking an image will fit better here than in a comment.
So if you want to use VS 2015 but still use the same good ol' version of the C# language that worked for years, you can configure your project to target a specific version:
This adds <LangVersion>5</LangVersion> in the csproj.
I've been requested to create a .Net dll for an old delphi program. I'm trying to do this with a COM Callable Wrapper, but I keep getting an error when it tries to load the dll (pretty general, something like "I couldn't load the dll"). Here is what the technical documentation says:
The DLL only needs to export one function under the name 'AUTHORIZE'.
function Authorize(InXml: PChar): PChar; stdcall;
(Delphi syntax. May be different in other languages.)
Here is my code for the CCW:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices;
namespace ComCallableWrapper
{
[Guid("C3FD922A-FB44-47B1-9C0C-8F7FAF57098B")]
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
public interface IAuthorizer
{
[DispId(1)]
string Authorize(string lnpInXml);
}
[ProgId("ComCallableWrapper.Authorizer")]
[ClassInterface(ClassInterfaceType.None)]
public class Authorizer : IAuthorizer
{
public Authorizer()
{
}
public string Authorize(string lnpInXml)
{
return "Approved!";
}
}
}
I also run this command "regasm /tlb:ComCallableWrapper.tlb ComCallableWrapper.dll /codebase" on the computer where the delphi program is running.
I've been doing some research on google about how delphi invokes functions on a dll, and I found at least 2 ways:
function Authorize(lnpInXml: pchar): pchar; stdcall; external 'DLLName.dll';
and
oleObject := CreateOleObject('ComCallableWrapper.Authorizer');
ShowMessage(oleObject.Authorize('Approved?'));
It looks like COM works a little bit different. Is there a way to change my CCW to work like the first way?
Regards.
You con't need COM. And indeed using COM is a mistake because the Delphi program is not looking for a COM DLL.
What you need to do is to export an unmanaged function from your managed C# DLL. That's a little tricky and is in fact not supported. These are your most attractive options:
Use Robert Giesecke's UnmanagedExports.
Write a mixed mode C++/CLI DLL that consumes your C# code. The mixed mode C++/CLI is capable of export native functions using __declspec(dllexport), .def files etc.
If you chose to use UnmanagedExports, the function would look like this:
[DllExport]
public static IntPtr Authorize(string InXml)
{
// your code goes here, for now return the input value
return Marshal.StringToHGlobalAnsi(InXml);
}
Implementing the function is a little tricky because you need to return a Delphi PAnsiChar, that is a C++ char*. You cannot use string for the return type and have to use IntPtr. But how do you allocate the string so that it remains valid for the caller to use it. The code above leaks the string in an HGLOBAL.
I can't advise you definitively how to resolve the lifetime of the string. The interface you are coding to is not at all well designed. Only you with more knowledge of the interface are in a position to resolve that issue.
I have a console app, myapp.exe. Within the app is a function, let's call it:
public static int AddIntegers(int a, int b)
Is it possible to make this function visible externally so that a VBscript could call it? Do I have to move the function into a DLL or can I leave it in the EXE and make it visible? If so, how?
Idealistically, you should be making a DLL and set Com Visible on the functions you need to expose.
using System;
using System.Runtime.InteropServices;
namespace MyDLL
{
[ComVisible(true)]
public class Operations
{
[ComVisible(true)]
public int AddIntegers(int a, int b)
{
return a + b;
}
}
}
After you've compiled your DLL you need to register it with regasm.exe so that you can call it from VBScript:
Dim myObj
Set myObj = CreateObject("MyDLL.Operations")
Dim sum
sum = myObj.AddIntegers(3, 5)
This reply is based on the CodeProject posting How to call a .NET DLL from a VBScript by Raymund Macaalay. I recommend you read it.
Also, you should check other stackoverflow posting such as How to call C# DLL function from VBScript.
Yes, you will need to make the managed code library (DLL) visible to the VBScript (most likely through the GAC). Then in your VBScript, you can do something like:
dim yourObject = CreateObject("YourContainingObject");
yourObject.AddIntegers yourFirstInt, yourSecondInt
I'm exposing a C# class to COM using these attributes:
[ComVisible(true)]
[ClassInterface(ClassInterfaceType.AutoDual)]
[GuidAttribute("2325EBEB-DB5F-4D29-B220-64845379D9C5")]
[ComSourceInterfaces(typeof(WrapperEvents))]
in this class I have a function:
public void shutdownService()
This function is meant to be called just once from a VB6 client via COM Interop. Everything works fine. But somehow, it's being called more than once. My C# codes doesn't call this function directly. So I'm guessing the problem is in VB6 code. Unfortunately, that's not what the VB6 team thinks.
Is there a way to determine the caller of this function, ie. from my C#code or the VB6 code?
Right now I'm using a simple function to get the stacktrace:
public void LogStack()
{
var trace = new System.Diagnostics.StackTrace();
foreach (var frame in trace.GetFrames())
{
var method = frame.GetMethod();
if (method.Name.Equals("LogStack")) continue;
logger.Debug(string.Format("LogStack: {0}::{1}",
method.ReflectedType != null ? method.ReflectedType.Name : string.Empty, method.Name));
}
}
Obviously, I got somthing like this on the log:
2011-12-23 08:28:40,067 1 DEBUG (null) LogStack: Service::shutdownService
Since the only line of LogStack is the COM exposed function, I assume it's being called from vb6. But that's not enough proof for the VB6 team. Any idea how to really prove where function ?
You can try several things:
set a breakpoint in your code to trigger the debugger, then look at the call stack.
You could do an application dump here from visual studio and send it to them or screenshot the stack.
ex. Debugger.Break
http://www.netsplore.com/PublicPortal/blog.aspx?EntryID=12
Dump with "Savre Dump As"
http://msdn.microsoft.com/en-us/library/d5zhxt22.aspx
Use the com tracing
from a system level see
http://support.microsoft.com/kb/926098
I also recall a tool being installed with visual studio 6 do to this as well
I have to replace an existing dll call that is registered and called using RegFn and CallFn respectively.
I am trying to write the dll using C# in the hope that as long as the function signature match and the dll is in the right place it will work.
so
pnHndl= RegFn("CALCULATE", "I", "I", "AJons.DLL")
pnRetVal = CallFn(pnHndl, 0)
My code is as follows:
[Guid("EAB7C2CD-2471-4BDA-90E9-F70403BAA557")]
[ComVisible(true)]
public class AJons : _AJons
{
[ComVisible(true)]
public int CALCULATE(int value)
{
return value * 2;
}
}
Foxpro doesn't play ball I just get 'could not load library AJon.dll'
Does anyone have any experience here?
Cheers.
From what I can see, those really old RegFn and CallFn are for calling Win32 native Dlls - completely different from COM.
What you need to create a Win32 dll that will work with those functions is C++.
What you should do (if you HAVE to keep using FoxPro) is at least use the latest version of VFP.
written on my iPhone
Update 1
1) Just in case I wasn't clear, you cannot make this kind of DLL from .NET.
2) Have a look at this link here for a very simple example of how to write a Win32 dll.