CODEWITHSUNDEEP
c++vb.netclrtcl
jags0333
jags0333

Reputation: 43

Tcl Extension Calling a VB.NET DLL

I have a need to create a Tcl extension that calls a managed .NET DLL/Class Library. Currently, the structure of my application is Tcl > DLL Wrapper (C++ CLR) > .NET Class Library (VB.NET), where ">" represents a function call.

My VB.NET DLL just takes a value and returns it back, keeping it simple for now. In the end, this will do some more advanced stuff that makes use of some .NET functionality.

Public Class TestClass
    Public Function TestFunction(ByVal param As Integer) As Integer
        Return param
    End Function
End Class

My Tcl Extension (C++ CLR) creates an object of the type above

int TestCmd(ClientData data, Tcl_Interp *interp, int objc, Tcl_Obj *CONST objv[])
{
    // Check the number of arguments
    if (objc != 2) {
        Tcl_WrongNumArgs(interp, 0, objv, "arg");
        return TCL_ERROR;
    }

    int param, result;

    if (Tcl_GetIntFromObj(interp, objv[1], &param) != TCL_OK)
        return TCL_ERROR;

    SimpleLibrary::TestClass^ myclass = gcnew SimpleLibrary::TestClass(); //System.IO.FileNotFoundException
    result = myclass->TestFunction(param);

    Tcl_SetObjResult(interp, Tcl_NewIntObj(result));
        return TCL_OK;
}

And finally, my Tcl script loads the extension and calls the function.

load SimpleTclExtension.dll
TestCmd 2

If my VB.NET DLL is in the same directory as my extension DLL, the extension crashes when it instantiates a TestClass object. I've noticed if the VB.NET DLL is relocated to C:\Tcl\bin, the extension will find it, and TestCmd can be called just fine. The problem is that this will eventually need to be deployed across a number of PCs, and it's preferred not to mingle my application's files with another application's.

It seems like there should be some configuration settings that will fix this problem, but I'm not sure where. Any help is greatly appreciated.

Upvotes: 1

Views: 789

Answers (2)

APN
APN

Reputation: 11

To be more specific, Eagle includes Garuda which is a Tcl extension built specifically to allow calling .Net from Tcl

Upvotes: 0

patthoyts
patthoyts

Reputation: 33193

Firstly, depending on just what kind of Tcl application you are using you may want to look at Eagle which is a implementation of Tcl in CLR.

I think you are bumping into .Net's desire to only load assemblies from your application's directory or its immediate subdirectories. The application here is the tclsh/wish executable which is why moving the .Net assembly makes it load. This is something you can fix with suitable manifests or calls to the API to permit assembly loading from alternate locations. In this case I think you will need to run some initialization code in your Tcl extension when it gets loaded into the Tcl interpreter to init the CLR and add the extensions location as a suitable place to load assemblies from. It has been a while since I was looking at this so I forgot the details but I think you want to look at the AppDomain object and check the assembly loading path properties associated with that or its child objects. Try AppDomain.RelativeSearchPath

Upvotes: 1

Related Questions